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: > > On Mon, Oct 21, 2013 at 5:27 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote: > > >> 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. > > > > > >> (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
Attachment:
pgpuNO6_Dd1iT.pgp
Description: PGP signature