On Mon, Oct 27, 2008 at 6:51 PM, Matt Sealey <[EMAIL PROTECTED]> 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev