[U-Boot] [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Mike Frysinger]

On Monday 05 December 2011 17:52:01 Simon Glass wrote:
> On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren wrote:
> > On 12/05/2011 02:56 PM, Simon Glass wrote:
> > * A system-wide GPIO ID, in which case the numbering is "virtual" (e.g.
> > a concatenation of the GPIOs on all the present controllers), and you
> > can choose to start the first controller's GPIOs at 0, 1, 1000 etc.,
> > thus leaving -1, 0, -n..999 etc. as invalid GPIOs. This is what the
> > Linux kernel's gpiolib uses (and some say this global numbering scheme
> > was a mistake).
> 
> Well maybe it was a mistake, but it seems painful for the user to
> translate GPIO numbers in this way. U-Boot's GPIO command takes a GPIO
> number, which starts at zero.

u-boot should simply follow what linux is doing as it keeps things a hell of a 
lot simpler for us: the code is done, people moving between the worlds don't 
get surprised and screw something up, and we don't accidentally forget "oh, in 
u-boot we do XXX instead of YYY" and screw things up ourselves.

> >> I currently use the max value available to the u8. We can change it at
> >> will when we update the u8 type to u16 which is why I made it a
> >> constant.
> > 
> > include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd
> > suggest these APIs do the same, rather than use a u8.
> 
> Do you mean the fdt_gpio_state structure? I have not used u8 for any
> function calls and would not.

the asm-generic/gpio.h using "int" as a gpio is wrong.  it should be 
"unsigned".  there's a patch somewhere to fix this.

> This adds 3 bytes for every entry. What is the benefit? People get
> upset when we waste memory!

some systems have more than 256 GPIOs.  it's actually not that hard to hit the 
limit.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20111205/fa62d320/attachment.pgp>