Best practice device tree design for display subsystems/DRM

[Sascha Hauer]

On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
> On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> > > > > Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
> > > > > really consider Linux framebuffer or other subsystems? The above dtsi file
> > > > > is specific to DRM subsystem. And I think the dtsi file has no any
> > > > > dependency on certain subsystem so board dtsi file should be considered for
> > > > > all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
> > > > > and so no. So I *strongly* object to it. All we have to do is to keep the
> > > > > dtsi file as is, and to find other better way that can be used commonly in
> > > > > DRM.
> > > > 
> > > > +1 for not encoding the projected usecase of the graphics subsystem into
> > > > the devicetree. Whether the two LCD controllers shall be used together
> > > > or separately should not affect the devicetree. devicetree is about
> > > > hardware description, not configuration.
> > > 
> > > And if we listen to that argument, then this problem is basically
> > > impossible to solve sanely.
> > > 
> > > Are we really saying that we have no acceptable way to represent
> > > componentized devices in DT?  If that's true, then DT fails to represent
> > > quite a lot of ARM hardware, and frankly we shouldn't be using it.  I
> > > can't believe that's true though.
> > > 
> > > The problem is that even with an ASoC like approach, that doesn't work
> > > here because there's no way to know how many "components" to expect.
> > > That's what the "supernode" is doing - telling us what components group
> > > together to form a device.
> > 
> > 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).
> 
> Wrong.  Please read the example with the diagrams I gave.  Consider
> what happens if you have two display devices connected to a single
> output, one which fixes the allowable mode and one which _can_
> reformat the selected mode.

What you describe here is a forced clone mode. This could be described
in the devicetree so that a driver wouldn't start before all connected
displays (links) are present, but this should be limited to the affected
path, not to the whole componentized device.

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 |