Re: [PATCH v3 1/2] Alchemy: rewrite GPIO support.

[Florian Fainelli <florian@openwrt.org>]

Le Thursday 09 April 2009 19:49:22 Manuel Lauss, vous avez écrit :
> The current approach is not sufficiently generic for my needs:
> I want to use generic functions which deal with the GPIO1 and GPIO2
> blocks, but don't want the default gpio numberspace as imposed by the
> databooks;  instead I also want the option to register gpio_chips for
> my board with a custom gpio namespace.
>
> To address this, the following changes are made to the alchemy gpio
> code:
>
> - create linux-gpio-system compatible functions which deal with
>   manipulating the GPIO1/2 blocks.  These functions are universally
>   useful.
> - gpiolib is optional
>
>   If CONFIG_GPIOLIB is not enabled, provide the equivalent functions
>   by directly inlining the GPIO1/2 functions.  Obviously this limits
>   the usable GPIOs to those present on the Alchemy chip.  GPIOs can
>   be accessed as documented in the datasheets (GPIO0-31 and 200-215).
>
>   If CONFIG_GPIOLIB is selected, by default 2 gpio_chips for GPIO1/2
>   are registered, and the inlines are no longer usable.  The number-
>   space is as is documented in the datasheets.
>
>   However this is not yet flexible enough for my uses.  My Alchemy
>   systems have a documented "external" gpio interface (fixed number-
>   space) and can support a variety of baseboards, some of which are
>   equipped with I2C gpio expanders.  I want to be able to provide
>   the default 16 GPIOs of the CPU board numbered as 0..15 and also
>   support gpio expanders, if present, starting as gpio16.
>
>   To achieve this, a new Kconfig symbol for Alchemy is introduced,
>   CONFIG_ALCHEMY_GPIO_INDIRECT, which boards can enable to signal
>   that they are not okay with the default Alchemy GPIO functions AND
>   numberspace and want to provide their own.  This also works for both
>   CONFIG_GPIOLIB=y and CONFIG_GPIOLIB=n.  When this config symbol is
>   selected, boards must provide their own gpio_* functions; either in
>   a custom gpio.h header (in board include directory) or with gpio_chips.
>
>   To make the board-specific inlined gpio functions work, the MIPS
>   Makefile must be changed so that the mach-au1x00/gpio.h header is
>   included _after_ the board headers.
>
>   see arch/mips/include/asm/mach-au1x00/gpio.h for more info.

That's fine with me, I do not see obvious breakages for boards that will use 
the standard GPIO interface. Thanks for your work !

>
> Cc: Florian Fainelli <florian@openwrt.org>

Acked-by: <florian@openwrt.org>
-- 
Best regards, Florian Fainelli
Email : florian@openwrt.org
http://openwrt.org
-------------------------------