Re: [PATCH v2] gpio: Device tree support for LPC32xx

[jonsmirl@xxxxxxxxx]

On Sat, Apr 7, 2012 at 1:45 PM, Roland Stigge <stigge@xxxxxxxxx> wrote:
> On 07/04/12 19:17, jonsmirl@xxxxxxxxx wrote:
>>> Please consider how the groups are specified in
>>> drivers/gpio/gpio-lpc32xx.c. They each have different numbers of lines
>>> and GPIO / GPI / GPO functionality. So they also have different callback
>>> sets, and we need to do separate gpiochip_add()s which leads to the
>>> separate gpio-bank specifications in the dtsi file. Separate enabling of
>>> those banks via OF are a nice by-product.
>>
>> When you have six banks of 32b registers with sparse, active GPIOs in
>> the banks, is there any advantage to saying bank one has 8 gpios, bank
>> 2 has 14, bank 3 has 2, etc in the gpiochip?  Or just just register
>> them as six banks of 32 GPIOs without indicating which are
>> valid/invalid?
>
> I think it is a good idea to only register GPIOs that are real when we
> already have many (~100) instead of registering hundreds of invalid
> extra ones (that will _always_ be invalid for this very driver).

I only want to apply this to identical controller banks. For example
the lpc31xx has 12 identical banks of 32 bits.  You can program all
384 of these locations identically, but only about 100 locations are
actually hooked to real hardware.

We could add something like this to the device tree for gpio-controller:
gpios-valid = <0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 0x1234 ...>
12 groups of bits indicating which gpios are valid.

Or we could just ignore the invalid bits. On the lpc31xx they all
work, just just don't do anything.

>
> Also corresponds nicely to the hardware specs when there are banks of
> odd sizes which can be found registered accordingly in the kernel.

I agree that if the structure of the GPIO banks is irregular they
should be different gpiochips.

>
> Roland



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/