Cyril Chemparathy <[email protected]> writes:

> Support for tnetv107x gpio controller.  Note that this controller does not use
> the gpio related definitions from davinci_soc_info.
>
> Further, this patch modifies davinci's inlined gpio functions to range check
> against davinci_soc_info contents instead of DAVINCI_N_GPIO.  This way,
> tnetv107x systems can define davinci_soc_info.gpio_num to 0 and bypass the
> inline routines.
>
> Signed-off-by: Cyril Chemparathy <[email protected]>
> ---
>  arch/arm/mach-davinci/Makefile                 |    1 +
>  arch/arm/mach-davinci/gpio-tnetv107x.c         |  155 
> ++++++++++++++++++++++++
>  arch/arm/mach-davinci/include/mach/gpio.h      |    6 +-
>  arch/arm/mach-davinci/include/mach/tnetv107x.h |    4 +
>  4 files changed, 163 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/mach-davinci/gpio-tnetv107x.c

I'm not crazy about this approach.

Both the existing functions and the new functions all do basically the same 
thing:
- read base + offset
- set/clear bit(s) based on GPIO#
- write base + offset

I think a cleaner solution to this would be to clean the existing GPIO
layer of direct knowledge of register layout.  Instead, convert the
gpio_controller struct into struct that holds register offsets from a
base.  This array of offsets is what needs to be different between
davinci and tnetv107x.

Also, Re: locking.  You shouldn't need to globally disable interrupts
here.  What I'm guessing you need is a mutex.

Kevin
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

Reply via email to