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

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:

quoted

quoted

quoted

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.

If you go down that path, you risk driving the LCD panel with
inappropriate timings which may damage it.

-- 
Russell King