Re: Best practice device tree design for display subsystems/DRM

[Sascha Hauer <s.hauer@pengutronix.de>]

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).

Consider what happens with a supernode approach. Your board provides a
devicetree which has a supernode with hdmi and lvds referenced. Now you
build a kernel with the hdmi driver disabled. You would still expect the
lvds port to be working without having the kernel wait for the supernode
being complete.

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.

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 |