Thread (1 message) 1 message, 1 author, 2012-04-07

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

flat view

From: jonsmirl@gmail.com <hidden>
Date: 2012-04-07 18:54:09
Also in: linux-arm-kernel, lkml

On Sat, Apr 7, 2012 at 1:45 PM, Roland Stigge [off-list ref] wrote:
On 07/04/12 19:17, jonsmirl@gmail.com wrote:
quoted
quoted
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@gmail.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help