On Tue, Oct 28, 2008 at 10:53 AM, Matt Sealey <[EMAIL PROTECTED]> wrote: > Is it still possible to perhaps create a node under lcd-controller which > describes the pin groupings? Maybe we should call it a gpio-group. > > That way lcd-controller looks like > > lcd-controller { > compatible = "crystalfontz,something-gpio"; > data-bus { > compatible - "gpio-group"; > gpios = <gpioc 1 gpioc 8 gpioc 42 ... > > } > rw-ctrl { > compatible = "gpio-group"; > gpios = <gpioc 2> > }
At this level, the 'compatible = "gpio-group";' is completely irrelevant. The binding for "crystalfontz,something-gpio" must specify that there are two subnodes; one named data-bus and one named rw-ctrl. The driver, which binds against compatible in the parent node, would know to go looking for those child nodes and to use the gpios property inside them. Simple. >> Does this mean "hard-coding"? > > No. If you have an array of GPIO pins (gpios property) then how do you > determine which is for data and which is some control pin? Do you > associate these numbers in the driver somehow? Maybe a matchlist or > an array? Given pins A B C D E F G H I J where does the data bus > start and the control pins live? A and B? A and J? I and J? You know because you document it in the binding. > It would be definitely frivolous to define a whole device tree binding > for the *order in which you MUST specify the gpios for this particular > device*. There is obviously an implicit ordering of the GPIOs to make > up the data bus (you'd expect an order from MSB to LSB.. or perhaps > LSB to MSB... that might be better defined than undefined) Why is it frivolous? We do this all the time for reg and irqs. 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