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: > > On Sun, May 29, 2011 at 08:18:09PM -1000, Mitch Bradley wrote: > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
