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

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

On 07/04/13 10:53, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
>> On 07/04/13 10:33, 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).
>>>
>>> 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,
>
> Then your Cubox devicetree has a link (that's how they call it in v4l2,
> a link doesn't necessarily is a direct connection but can have multiple
> devices in it) between lcd0 and hdmi.

I haven't looked up v4l2 "link" yet. But (a) if it is a separate node
how is that different from the "super-node" we are talking about or (b)
if it is a property, where do you put it?

>>   olpc just needs lcd0 and has built-in hdmi in the SoC (IIRC).
>
> And olpc has a link with lcd0 as the source and the builtin hdmi.

Sure, as my DT proposal that Inki shamelessly copied, has a "link"
property for lcd0 on Cubox, while OPLC's lcd0 hasn't.

>> The driver needs to know what to wait for, and that is given by the DT super-node.
>
> You need a source (described in the devicetree), a sink (also described
> in the devicetree) and a link between them, nothing more.

What if you need source-to-multi-sink or source-to-transceiver-to-sink?
The DT proposal I have given, is source-to-sink on a per device node
basis. If you don't like OPLC's lcd0 having no "link" while Cubox' lcd0
has, put a fake node for the possibly connected HDMI monitor in there.
ASoC does that for SPDIF jack by also having a "codecs" driver although
there is nothing to control.

>> I consider kernels with missing drivers compared to what is given in
>> the DT as broken setup.
>
> What if your devicetree describes components not yet in mainline. Would
> you consider mainline kernels broken then?

No. But I do not 1:1 match device tree nodes with subsystem drivers.
The devices are there, there is no driver.

Currently, for CuBox DT, video _is_ broken because there is no way to
represent the way lcd0, hdmi-transmitter, and pll are connected to form
a single video card. All separate drivers exist, you may be lucky to get
video out of the CuBox because of some reset values that allow you to
get it by coincidence. But as soon as you try the very same kernel on a
different board, your experience will change quickly.

Sebastian