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

On Thu, Oct 24, 2013 at 09:28:11AM +0200, Sascha Hauer wrote:

On Wed, Oct 23, 2013 at 09:14:17PM -0400, Rob Clark wrote:

quoted

On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer [off-list ref] wrote:

quoted

quoted

If a subsystem doesn't work well with DT, then the choices are either:

(a) don't use DT with the subsystem

The underlying problem has nothing to do with DT. Multi component
hardware does exist and won't vanish when we stop using DT.

quoted

(b) fix the subsystem

I'd love to do that. Step one to this seems to be to increase the
awareness that there's something wrong with DRM.

Note that I suspect your idea of "fixing drm" is going to break some
userspace assumptions about the hw (ie. userspace isn't expecting
crtcs/encoders/connectors to suddenly appear/disappear.  And the funny
thing is, on all of this hw, that isn't going to happen anyways.

I was talking about all SoC DRM drivers implementing variants of the
same glue between drm and the multidevice nature of the components.

To make that sure: I never had the intention to implement hotplug for
drm. Also what the imx-drm driver does is not for hotplug, but only for
binding different components together.

I think we should be able to solve that problem generically. Essentially
we need some sort of composite device that subdevices can register with.
The composite device can keep track of what devices are needed (this
works well by walking the device tree, looking for nodes that match by
compatible and see if their status property is set to"okay") and once
all of those have been registered do whatever the specific subsystem
requires.

I'm not familiar with what exactly the requirements are for other SoCs,
so I'd be interested in hearing if there's anything beyond the above.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131024/20e0cd6a/attachment.sig>