ARM topic: Is DT on ARM the solution, or is there something better?

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Nov 18, 2013 at 04:37:51PM +0100, Thierry Reding wrote:
> Very nice. This is in fact very similar to a skeleton I started to
> implement locally. The names vary to some degree, but the general
> approach is the same.
> 
> This also happens to be very similar to what Tegra DRM does, just as a
> set of helpers rather than a bus type. I like it a lot.
> 
> In particular this gives every driver a good amount of flexibility to
> implement the matching in a way that's appropriate. On hardware where
> the relationships are hierarchical, a driver can use that to its
> advantage. Whenever that's not possible it can be done using phandles
> or any other meta data that fits the particular use-case.

Indeed - I set out to solve the following problems:

- How do we deal with a componentised device such that we can find all
  of its component devices, and know when we have them all?
- How can we probe the master device when we know we have all the
  components?
- How do we tear down the master device when one of the components is
  removed?

I intentionally didn't want the code to answer the question about how
we specify how the components are organised - that's a subject best
left to the subsystem and/or device, since it's something which will
most likely vary.

> Do you have a branch somewhere that I could use to test this with?

Not yet - and there probably won't be, because the code itself is not
large - it's currently less than 500 lines.

The code has evolved over time - with imx-drm as a guinea pig.

The code which I have so far committed (and some people are using in
patch form on the carrier-1 boards) is an earlier version, which just
caters for proper init ordering and making it possible to unbind the
"master" device.  It gets that init ordering by using deferred probing
if there's no connectors, or the CRTCs which the connectors refer to
are missing - it needs no changes to the DT representation.

Since then, I've augmented it as I described and that's currently just
as an additional patch on top which adds the master device idea - which
does need those additional changes.

Logically, it can't stay as two separate patches, because it won't be
possible to "migrate" to it in stages.  So I'm fully intending to
squash that all down to one patch which adds the core code (probably
ultimately into drivers/base).

IOW, watch this space this week. :)