Hi Mike,
On Mon, Dec 5, 2011 at 7:55 PM, Mike Frysinger vapier@gentoo.org wrote:
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.
Good, I think that is what we are doing. But if Linux changes the GPIO numbering we may need to do something.
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.
OK, will wait to see it.
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
Not for me so far, but I don't doubt it. I have changed it to uint in the series.
Regards, Simon