Best practice device tree design for display subsystems/DRM

Sascha Hauer s.hauer at pengutronix.de
Thu Jul 4 02:51:49 PDT 2013


On Thu, Jul 04, 2013 at 10:08:29AM +0100, Russell King wrote:
> On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> > A componentized device never completes and it doesn't have to. A
> > componentized device can start once there is a path from an input
> > (crtc, i2s unit) to an output (connector, speaker).
> 
> Sorry for the incomplete reply.
> 
> If you read all the messages in this thread, then you will realise that
> DRM does not support an incremental startup approach.  It needs to know
> everything at the point of "load".

I know that DRM does not support this incremental startup approach.

> 
> > Without supernode you can just start once you have everything between
> > the crtc and lvds nodes. If later a hdmi device joins in then you can
> > either notify the users (provided the DRM/KMS API supports it) or just
> > ignore it until the DRM device gets reopened.
> 
> It's not a case that you can ignore it until the "DRM device gets reopened"
> because the DRM device never shuts down.  You'd have to ignore it until
> you tear down what you have already registered into DRM, causing all
> the display hardware to be shutdown, and then re-"load" DRM.
> 
> To make this work, you would have to modify not only DRM to allow that,
> but also the framebuffer layer too.  Are you volunteering? :)

I tend to ignore the framebuffer layer since I still hope that it will
be removed from DRM soon.

We @pengutronix can put quite some time into this, but for sure we can't
do it alone.

A general problem with DRM on embedded at the moment is that there's
very little cooperation between the different driver authors, mainly
because DRM makes it hard to share code between the drivers. There
currently is no place in DRM to register components in a drm_device
agnostic way, so everyone currently tries to work around this in the SoC
drivers. The supernode approach seems to be in this fashion.

Coming from the embedded area componentized devices are nothing new to
us and I believe that working on this could also help the desktop people
who suddenly get componentized devices aswell (Optimus).

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


More information about the dri-devel mailing list