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

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Thu, May 28, 2009 at 08:11:33PM +1000, Benjamin Herrenschmidt wrote:
> Well, that example is interesting because you may not want the
> transceiver to be a child of the UART :-) The tree hierachy is mostly
> about addressing, and addressing below a UART doesn't mean much.
> 
> So if the transceiver has a bunch of MMIO registers, it might be better
> off located elsewhere, and have the UART have a "fir-transceiver"
> property with a phandle to the actual device...

IrDA transceivers do not have MMIO registers.  Transceivers are an IR
LED, an IR phototransitor and receiver circuitry.  They're typically
9 pin devices with power, ground, transmit, receive and a bunch of
control signals.

These control signals end up connected to some random GPIO pins or
FPGA or some other device which has some free IO lines in the platform.

These control signals need to be controlled with reference to the IrDA
driver, sometimes with tight timing constraints (particularly when
switching between SIR and FIR modes.)

> But yes, I definitely agree, it's flexible enough for a lot of that
> stuff. Where things get tricky is to express "methods" rather than just
> relationships. This is where x86 loses big time with ACPI, Apple lost
> with their platform functions in OF properties, and appart from having a
> real OF implementation under the hood that is kept alive along with the
> kernel to call in, the tree doesn't provide a simple solution.
> 
> However, it doesn't either invalidate existing solutions based on
> function pointers into the platform code... it might even make it nicer
> by naming those functions into some kind of directory where they can be
> registered by the platform code and "named" by a property in the node,
> though I tend to prefer the approach of having a property with a phandle
> to a node that is a pseudo-device ("power-control") or so, which has its
> own driver providing the methods.

The kind of reply I was hoping to get to my email was something more
along these lines - an informed view giving an idea how some of these
issues would be addressed with an OF device tree.

I can see how the named functions/directory would work - that seems to
be relatively simple and straight forward.

However, the pseudo-device approach I'm less clear about.  With a separate
driver for the "power control" pseudo-device, how would you communicate
the state information down to that driver?

I am equating OF devices and drivers too much with the struct device and
struct driver model, which sounds like it's not the best thing to do with
OF.