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

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

On 07/04/13 11:23, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
>> 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?
>
> Sorry, I should have explained this. The basic idea the v4l2 guys are
> following is that they describe their hardware pipelines in the devicetree.
>
> Each device can have ports which are connected via links. In the
> devicetree a link basically becomes a phandle (a remote device will have
> a phandle pointing back to the original device). For an overview have a
> look at
>
> Documentation/devicetree/bindings/media/video-interfaces.txt
>
> With this you can describe the whole graph of devices you have in the
> devicetree. The examples in this file have a path from a camera sensor
> via a MIPI converter to a capture interface.
>
> The difference to a supernode is that this approach describes the data
> flow in the devicetree so that we can iterate over it to find links
> between source and sink rather than relying on a list of subdevices to
> be completed.

Agree. But that is not that different from linux,video-external-encoder
property I made up, except that the name is different.

And, I still see no way with that source/sink linking _alone_ how to
tell that either lcd0 and lcd1 act as a _single_ video card or lcd0 and
lcd1 are used in a _two_ video card setup.

There is no single device node on Dove that would sufficiently act as
the top node for a working video card on all boards. And there is no
framebuffer node to link each of the lcd0/1 nodes to.

That is what the super-node is for, form a virtual device called
video card to act as a container for all those SoC devices that are
not sufficient for a working video setup on their own.

If lcd0 needs that hdmi-transmitter you link it to the lcd0 node -
not the super-node. If lcd0 needs some pll clock you link it to the
lcd0 node - again not the super-node.

The super-node(s) just connects all SoC devices that shall be part of
your board-specific video card(s) - for Dove that is any combination of
lcd0, lcd0, dcon and video memory allocation.

Sebastian

Sebastian