On Tue, May 31, 2011 at 09:27:12AM +1000, Benjamin Herrenschmidt wrote:

On Mon, 2011-05-30 at 15:01 +0800, Mark Brown wrote:

quoted

On Sun, May 29, 2011 at 08:18:09PM -1000, Mitch Bradley wrote:

quoted

I'm currently dealing with an SoC that has over a hundred GPIOs.
Whatever we choose, I think it should be able to handle an insane
number of GPIOs without getting any more cumbersome that is
necessary.

This is *consumer* side GPIOs, not bindings for the device providing the
GPIOs.  If a single device needs to use hundreds of GPIOs I'd expect
many of them will be block functions so you'd have a binding with an
array for things like "databus" and "addrbus".

Yes. Agreed. The producer remains identified by phandle/gpio#, so it's
just a naming thing on the consumer side.

So what are the options ?

 - gpio-xxxx = < ... > properties

 - existing binding, along with an optional gpio-names string list

 - anything else ?

The producer side works fine as-is, agreed.

What I was not sure about was the use of having an array of unnamed
gpios as part of the consumer-side binding, where there's no logical
ordering between these entries.

In the sdhci case, there are three gpios; one to supply power to the slot;
one for card detect and one for write protect sense.

In that case, it would make a whole lot more sense to have three separate
properties, say "power-gpio", "cd-gpio" and "wp-gpio", than an opaque array of
entries without description besides what comments are used in the dts file.

That these in turn point just to gpio number <x> at controller <y> is OK with
me. Also, I can see cases where it makes sense to have more than one gpio
references in a property (i.e. busses), but only where there's either internal
ordering to them, or where ordering doesn't matter at all.


-Olof