Best practice device tree design for display subsystems/DRM

[Grant Likely]

On Fri, Jul 5, 2013 at 9:50 AM, Russell King <rmk at arm.linux.org.uk> wrote:
> On Fri, Jul 05, 2013 at 09:37:34AM +0100, Grant Likely wrote:
>> Alternatively, you can have the same effect with a property or set of
>> properties in the controller node that contains phandles to the
>> required devices. That would provide the driver with the same
>> information about which devices must be present.
>
> How do you go from phandle to something-that-the-driver-for-that-device-
> has-setup?
>
> From what I can see, you can go from phandle to OF node, but no further.

Correct, and that has historically been by design because it is
possible for multiple struct devices to reference a single
device_node. Any subsystem that needs to get a particular device has a
lookup mechanism that searches the list of known devices and returns a
match.

example: of_mdio_find_bus()

> I'm guessing we'd need some kind of "registry" for sub-drivers with
> these structures to register their devices OF node plus "shared" data
> so that other drivers can find it.  "shared" data might be a
> standardized operations struct or something similar to 'struct
> device_driver' but for componentised devices.

If it is per-subsystem, the effort shouldn't be too high because it
will be able to collect devices of the same type. It gets more
complicated to design a generic componentised device abstraction
(which I'm not opposed to, it's just going to be tricky and subtle).

One big concern I have is differentiating between manditory and
optional dependencies. Manditory is always easy to handle, but what
about cases where the supernode (using phandles to other nodes)
references other devices, but it is perfectly valid for the driver to
complete probing before it becomes available? I may just be borrowing
trouble here though. Supporting only mandatory dependencies in the
first cut would still be a big step forward.

One simple approach would be to add a "depends on" list to struct
device and make the driver core check that all the dependant devices
have drivers before probing. The risk is that would become a
complicated set of reference counting and housekeeping.

g.