On 5/29/2011 8:11 PM, Grant Likely wrote:
On Mon, May 30, 2011 at 11:38:27AM +0800, Mark Brown wrote:
On Sun, May 29, 2011 at 08:11:34PM -0700, Olof Johansson wrote:
On Fri, May 27, 2011 at 6:24 PM, Mark Brown
This is a step back from the usability of the existing platform data -
the platform data uses a series of individually named GPIOs while this
uses an array of GPIO numbers with magic indexes. The fact that you
need comments explaining what the functions of the array elements are
is a bit of a red flag here.
Agreed, I had similar concerns with the sdhci bindings where it used a
3-element array of gpios instead of the previous named ones. I was
told it's common practice to do it that way though? Seems like a step
backwards to me. :(
Interesting... what was the reasoning behind this? It's a definite
step backwards but it does explain my major concern with the new batch
of device tree patches.
The binding for gpios was defined a few years ago and it is in fairly
wide use within the powerpc sphere. The design followed the pattern
established for specifying irqs, and in that regard satisfied the
principle of least surprise.
That said, it isn't a very large leap to go from a single 'gpios'
property to allowing multiple named gpios properties with meaningful
names, particularly if they are fully specified by the device
binding, and they follow exactly the same binding semantics as the
existing 'gpios' proprety (phandle + gpio specifier).
Personally, I'm /cautious/ about saying okay to extending the binding,
simply because once the extension is in use it is really hard to go
back on it, but I cannot think of any reason why this particular case
wouldn't be a good idea. Anyone have thoughts on this? Ben? Mitch?
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.
g.
--
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
