GPIO - marking individual pins (not) available in device tree

[Grant Likely]

On Mon, Oct 27, 2008 at 6:51 PM, Matt Sealey <matt at genesi-usa.com> wrote:
>
>
> David Gibson wrote:
>>
>> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>>
>> 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 disagree.  With the approach we've been following the meaning of
those 10 gpio pins is not lost because we make a point of documenting
it (granted in the Linux kernel tree at the moment which is far from
ideal).  The knowledge of what those GPIOs are for is all bound up
with the documented binding attached to the compatible value.

> 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've got no problem with this myself, but I don't think it really adds
much in terms of additional information because users still need to
refer to binding documentation to figure out what it actually means.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.