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

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

On 07/05/13 10:43, Grant Likely wrote:
> On Wed, Jul 3, 2013 at 10:02 AM, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
>>>> video {
>>>>      /* Single video card w/ multiple lcd controllers */
>>>>      card0 {
>>>>              compatible = "marvell,armada-510-display";
>>>>              reg = <0 0x3f000000 0x1000000>; /* video-mem hole */
>>>>              /* later: linux,video-memory-size = <0x1000000>; */
>>>>              marvell,video-devices = <&lcd0 &lcd1 &dcon>;
>>>>      };
>>>>
>>>>      /* OR: Multiple video card w/ single lcd controllers */
>>>>      card0 {
>>>>              compatible = "marvell,armada-510-display";
>>>>              ...
>>>>              marvell,video-devices = <&lcd0>;
>>>>      };
>>>>
>>>>      card1 {
>>>>              compatible = "marvell,armada-510-display";
>>>>              ...
>>>>              marvell,video-devices = <&lcd1>;
>>>>      };
>>>> };
>>>
>>> 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.
>
> It is however relevant to encode information about how devices are
> related to each other. That could be an orthogonal binding though to
> describe how displays are oriented relative to each other.

Grant,

from what I can see from either super-node approach or v4l2 links with
respect to what we discuss about Marvell SoCs, both are more or less
equivalent.

The only issue left for how to describe that in DT in a sane way is:

Are we using a super-node or node properties for the virtual graphics
card to tell if there is one card with two lcd-controllers (lcd0/lcd1
above) or two cards with one lcd-controller.

You see the super-node solution above, but even with orthogonal
properties we can achieve the same. If we hook up the DRM (or fbdev or
whatever) driver to the lcd-controller nodes, we will have two driver
instances trying to register a DRM card.

For the two card scenario, everything is fine. The driver knows about
a possible DCON (output mux/mirror) and looks for a compatible
available node. Both driver instances may need to access DCON registers
but that is a driver issue and not DT related.

For the one card with two lcd-controllers scenario the only difference
between super-node and node-to-node linking alone is that you get two
driver instances in the first place. With a property equivalent to v4l2
"slave-mode" that you put on e.g. lcd1, the driver loaded for lcd1 node
bails out silently. The driver loaded for lcd0 also looks for
lcd-controller nodes with "slave-mode" property and picks up lcd1.

This possibly leads to races, but IMHO as long as the driver looks for
its "slave-mode" property early, everything should be fine.

All other links required, e.g. lcd0 -> hdmi-transmitter, belong to the
respective nodes in both approaches. DCON existence and requirement is
implicitly put in the driver and not required in DT.

Of course, this is independent of how to handle and register sub-drivers
for DRM. But this is subsystem dependent and also not related to DT.

So for the discussion, I can see that there have been some voting for
super-node, some for node-to-node linking. Although I initially proposed
super-nodes, I can also happily live with node-to-node linking alone.

Either someone can give an example where one of the approaches will not
work (i.MX, exynos?), Grant or one of the DRM maintainers has a
preference, or we are stuck at the decision.

Sebastian