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

[Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 07/04/13 10:33, 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).
>
> 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,

that is what it is all about. You assume you a priori know what devices
will be required for the componentized device to successfully output
a video stream.

We have shown setups where you don't know what is required. Cubox
_needs_ lcd0 and hdmi-transmitter, olpc just needs lcd0 and has
built-in hdmi in the SoC (IIRC). The driver needs to know what to
wait for, and that is given by the DT super-node.

I consider kernels with missing drivers compared to what is given in
the DT as broken setup. You cannot complain about missing SATA if you
leave out SATA driver, or - if you implemented the driver into two
parts - leave out one of the two SATA driver parts.

Sebastian