Re: [RFC] [PATCH] Device Tree on ARM platform

David Gibson
2009-05-28T12:58:48Z

On Thu, May 28, 2009 at 10:48:17PM +1000, David Gibson wrote:
> On Thu, May 28, 2009 at 12:17:32PM +0000, Dmitry Eremin-Solenikov wrote:
> > David Miller wrote:
> >
> > > From: Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> Date: Thu, 28 May 2009
> > > 10:15:13 +0100
> > >
> > >> For example, how would an IrDA transceiver be expressed in OF?
> > >
> > > As a child device node of the IRDA device, with associated properties.
> > >
> > > You can express _ANYTHING_ using the OF device tree. It is not even
> > > something to discuss, it's flexible enough.
> >
> > Hmmm. How to express the following situation:
> > On one of my platforms (sharp tosa) the backlight controller
> > is separated into two parts: one sitting on SPI, one on the I2C.
> > The tricky part is that the I2C part is only available when some
> > of registers of SPI part are programmed in a specific way.
>
> Put nodes under both the SPI and I2C busses, they have properties with
> phandles to refer to each other (could be one way or both depending on
> needs). Sprinkle with any additional information properties as
> necessary. Your driver (in the broad sense, rather than the "struct
> device_driver" sense) binds both devices and does what it needs to do.
>
> The I2C part should possibly have a status property with value
> "disabled" to indicate that it's not usable, until something activates
> it (in this case the other part of the driver frobbing the SPI side).

I should add, that's only one way, though it is the most obvious to me
from the information you've given. Depending on the details of the
device other possibilities might be appropriate.

--
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_!