On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
David Gibson wrote:
quoted
Um.. I can't actually follow what you're getting at there, sorry.
Imagine in your head that you have a GPIO controller that has a
32-bit register potentially controlling 32 pins on the chip.
Imagine that rather than being able to allocate 6 GPIO pins
*right next to each other* in the register and saying that
you start at "pin" 15 and use the next 6 "pins", you have to
spread it around and use pin 1, pin 8, pin 9, pin 11, pin 15,
pin 30, to make up this peripheral.
As far as I can tell there is no way at all to specify a set of
GPIO pins which are NOT consecutive because the current GPIO
spec stops after specifying a controller bank (the 32-bit
register).
Uh.. no. The gpio specifier has a format that's gpio controller
specific, but it must include the actual pin number, although exactly
how it's encoded might vary.
So, you use
gpios = <&controller pin1-specifier &controller pin8-specifier
&controller pin9-specifier &controller pin11-specifier
&controller pin15-specifier &controller pin30-specifier>;
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
David Gibson wrote:
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
Uh.. no. The gpio specifier has a format that's gpio controller
specific, but it must include the actual pin number, although exactly
how it's encoded might vary.
So, you use
gpios = <&controller pin1-specifier &controller pin8-specifier
&controller pin9-specifier &controller pin11-specifier
&controller pin15-specifier &controller pin30-specifier>;
Okay that makes some more sense to me.
So now my qualm is back to the beginning of the discussion. How do
we encode the purpose of those pins reliably and within some
standard framework, without getting *driver* specific?
Take the example of an LCD controller with an 8-bit bus and two
control pins, if you put all 10 into a gpios property, explicit
knowledge of the purpose of those pins is lost. It must then be
encoded directly into the driver..
I liked Anton's suggestion of grouping them and creating new nodes,
but you didn't like it when it was suggested before, so, I'm
wondering if there's a middle ground..
--
Matt Sealey [off-list ref]
Genesi, Manager, Developer Relations
On Mon, Oct 27, 2008 at 07:51:23PM -0500, Matt Sealey wrote:
David Gibson wrote:
quoted
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
Uh.. no. The gpio specifier has a format that's gpio controller
specific, but it must include the actual pin number, although exactly
how it's encoded might vary.
So, you use
gpios = <&controller pin1-specifier &controller pin8-specifier
&controller pin9-specifier &controller pin11-specifier
&controller pin15-specifier &controller pin30-specifier>;
Okay that makes some more sense to me.
So now my qualm is back to the beginning of the discussion. How do
we encode the purpose of those pins reliably and within some
standard framework, without getting *driver* specific?
Um.. I fail to see how the purpose of a pin can be not driver
specific.
Take the example of an LCD controller with an 8-bit bus and two
control pins, if you put all 10 into a gpios property, explicit
knowledge of the purpose of those pins is lost. It must then be
encoded directly into the driver..
Yes, this is normal. Just as the driver for a device must know the
function of each entry in 'reg' for its specific device, and what each
interrupt in 'interrupts' is used for.
I liked Anton's suggestion of grouping them and creating new nodes,
but you didn't like it when it was suggested before, so, I'm
wondering if there's a middle ground..
I have no problem with the suggestion of gpio_header nodes, if that's
what you're referring to (although I do suspect occasions on which
they are useful would be limited).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson