On Mon, Oct 27, 2008 at 07:51:23PM -0500, Matt Sealey wrote:
>
>
> 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?
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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
