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

[Warner Losh]

On Aug 19, 2012, at 6:02 PM, Ian Lepore wrote:

> On Sun, 2012-08-19 at 17:42 -0600, 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 possibility exists that there can be sets of gpios managed by
> different hardware that's completely unrelated.  For example, you can
> have some number of gpio pins on an SoC, then have an iicbus device that
> provides a bunch more gpio pins.  I'm not sure whether or not that
> confounds the idea of having a big zero-N address space for naming pins.

Not really.  Like interrupts, they can come from many different sources.  Yet, IRQs are well ordered.  Each platform defines how they are numbered differently, and I wasn't suggesting that the Atmel mapping would be universal.  The mapping is just a by the way this is one way it is done, not this is the only, or best, way to do it everywhere.

> Another annoying complexity is IRQs associated with pins.  Some pins can
> directly generate IRQn on the SoC.  Other pins are grouped together by
> device or bank or whatever, such that any change on pins M-N generates
> IRQn.  Sharing the IRQ for the latter type between multiple drivers
> (each using one or more pins in the shared bank) can be tricky, because
> on some hardware, reading the status register that says which pins
> changed clears that register.

It is no trickier than sharing it back in the at-pic days.

> I have no solutions to offer here, just throwing out a couple things
> I've run into in the past couple years.

Understood.