[Top] [All Lists]

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

To: Manuel Lauss <>
Subject: Re: [PATCH v3 1/2] Alchemy: rewrite GPIO support.
From: Florian Fainelli <>
Date: Fri, 10 Apr 2009 10:43:13 +0200
Cc: Linux-MIPS <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:sender:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=cTc9/pYgPvSIfHhi403XRdNNDEsqDFKlxIpHbW+42/s=; b=EmzyX3tLNqd/ITcRbojrzuyOdrrUJrtIZAFmvemC2hnxLfTiw27TvvKnDsR9vR5WXH iIYWozwTsCKHhVWkcNhVutu7dF4jxpQU3OwM5sMTWwEGV0ZbKgTuY/1Qpb13uuUziRAz G5h5lGKZ+VgeqiKd7hljGB0v9Q39HHfmJGwgE=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=lYX4a5AtotUWVNAt3p5k9JM0nqAVUh3riCG96dEULSEpqxK07J4W5XjLlLBrIYeqDr XEwRat8qoIXE0vGE0SklQk/I7EGEqZtLltT7/dxCsbroE0Kw3CypraIZLri3ghfY/iBY VR5jGDP/ixFZqD5NJvKY1hVqv8oeerCkw3Gjo=
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: KMail/1.9.9
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 <>

Acked-by: <>
Best regards, Florian Fainelli
Email :

<Prev in Thread] Current Thread [Next in Thread>