Best practice device tree design for display subsystems/DRM

[Grant Likely]

On Fri, Jul 5, 2013 at 11:07 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> Again the difference between supernodes and graphs is that the supernode
> approach does not contain information about what components are needed
> to do something useful with the device. You simply have to wait until
> *all* components are present which may never happen if you don't drivers
> for all components of the device.
> With the graph instead you can start doing something once you find a
> link between a source and a sink, no matter if other links are still
> missing.

I really think you're overstating your argument here. The whole point
of a super node is that a *driver* can bind against it and a driver
can be made intelligent enough to know which links are mandatory and
which are optional (with the assumption that the data about which is
which is encoded in the supernode). Graph vs. supernode vs some
mixture of the two can all do exactly the same thing.

What really matters is which approach best describes the hardware, and
then the drivers can be designed based on that.

> Another important point is that if you have a board with multiple i2c
> encoder chips, how do you decide which one is connected to which LCDx
> when all information you have is: "I need these x components", but have
> no information how these components are connected to each other.
> Fortunately I don't have hardware here which does something like this,
> but it would also be possible to chain multiple encoder chips. This
> could be described in a graph, but when all we have is a list of
> components without connection information we would need board specific
> code to handle the layout.

It is still absolutely true that i2c devices must have a node below
the i2c bus, same for spi, same for MMIO. That doesn't change. It
really isn't an option to have the subservient devices directly under
the supernode. On that point the supernode pretty much must have
phandles to those device nodes.

*However* there is absolutely nothing that says the subservient
devices have to be bound to device drivers! It is perfectly fine for
the supernode to go looking for a registered struct i2c_device (or
whatever) and drive the device directly*. There are certainly cases
where it wouldn't make sense to split a driver for what is effectively
one device into two. But I digress.

*You'll note that I said look for i2c_device here, and not
device_node. The reason is that waiting for the i2c_device to appear
gives a guarantee that the i2c bus is initialized. Looking for the
device_node does not.

g.