Messages in this thread | | | Date | Thu, 28 May 2009 11:34:21 +0100 | From | Russell King - ARM Linux <> | Subject | Re: [RFC] [PATCH] Device Tree on ARM platform |
| |
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.
| |