gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch

[Warner Losh]

On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote:

> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote:
> 
>> 
>> In general, I like this code in the context of the current GPIO framework.  I've been growing dissatisfied with the current GPIO framework, however, and some of my comments reflect that more than any comments about this specific code.
> 
> I noticed that Linux on BeagleBone does not
> simply number all pins as we do.  Pins are identified by
> two numbers:  a unit number and a pin number.

Is this in the code, or just in the FTD?  On Atmel, there's a single number from 0 to max-1 with all negative numbers being invalid.  But Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good start, and 3.6 will add the missing pinmux/pinctl stuff).

> The AM3358 SoC has a couple of GPIO modules,
> so this makes it pretty natural to map hardware
> diagrams (which refer to "pin 13 of GPIO module 1") to
> software. 
> 
> I agree with Warner that masks are probably a bad
> idea at the framework level.
> 
> But this all may have to wait for "gpioNG".

As does all the pinctl/pinmux stuff...  Linux is a fair bit ahead of us in being able to configure individual pins, groups of pins, in/out status, termination, etc. Pinctl/mux is the biggest part of the board/SoC support code for Atmel at the moment, so one of my plans is to transition those ports over as soon as the FTD stuff jells on the Linux side.

Plus Linux has more GPIOish things than we do.  Support for buttons that translate to a keyboard event, support for LEDs that's better than we have, the ability to control pin drives, interrupt control for GPIOs, etc.  Makes for a lot less code and a richer experience.

Warner