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

[Tim Kientzle]

On Aug 19, 2012, at 4:42 PM, Warner Losh wrote:

> 
> On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote:
> 
>> On Aug 19, 2012, at 10:02 AM, Warner Losh wrote:
>>> 
>>> 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).
>> 
>> I'm not exactly sure what you mean.  The Linux DTS file:
>> 
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/boot/dts/am335x-bone.dts
>> 
>> inherits most of the real functionality from
>> 
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/boot/dts/am33xx.dtsi
>> 
>> There are certainly separate entries there for each GPIO module.  I presume (but haven't verified) that the unit number maps directly to a "gpio#" device name.
> 
> There's similar things in the Atmel DTS files, but under the covers the gpio pins map into a uniform space number 0 to 32*N-1, where N is the number of GPIO units.

The "under the covers" part is exactly what bothers me
about this.

I've been reading documentation that says things like
"LED#0 on the board is connected to GPIO#1 pin 13".  I'd
like to be able to take that to the command line and type in:
    $ gpio 1 13 on
or
    $ gpio /dev/gpio1 13 on
and see LED#0 turn on.

Since GPIO is used by a lot of folks interfacing new
hardware, this kind of translation between hardware
interface and software API needs to be trivial.

How would the linear addressing approach
handle, for example, hot-plugging of a device that
provided a USB interface to a group of GPIO pins?
(That is, it plugs into the USB port on the board
and provides a GPIO header on the other end.
Not vice versa. ;-)

Tim