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

[Warner Losh]

On Aug 19, 2012, at 6:45 PM, Tim Kientzle wrote:

> 
> 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.

This makes a number of interfaces a simple int, rather than having some kind of struct.

> 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.

Yet other documentation says "The LED is connected to PC23" which has no simple mapping to this stuff.  Sure that's gpio2, since that's what would most likely get PIOC from the chip, but it could just as easily be 3 since C is the 3rd letter of the alphabet.

> 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.

Correct.  The current mapping we have is insane.  We have to have a base-address of the GPIO hardware, coupled with a mask and pass that complex thing around, when we could more easily pass around a simple int.  Linux did it this way to make their board files easier to cope with.  I'm not sure how it is exposed outside the kernel, honestly.  Given the trend to FDT, tuples aren't too bad to carry around since you don't have to contrive them to be in free code as much.

> 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. ;-)

Each platform would have a fixed set of pins, followed by a dynamically allocated range for the odd-ball situations like this.

For most things, gpio does single bit, and for single bit on one of many GPIOs units, masks are a pain.

But until I have gpioNG going, along with the pinctl and pinmux support with DTS tie ins, I guess I'm just flapping my yapper, eh?

Warner