Best practice device tree design for display subsystems/DRM

[Sebastian Hesselbarth]

On 07/04/13 11:30, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 10:11:31AM +0100, Russell King wrote:
>> On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
>>> On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
>>>> 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.
>>>
>>> What you describe here is a forced clone mode. This could be described
>>> in the devicetree so that a driver wouldn't start before all connected
>>> displays (links) are present, but this should be limited to the affected
>>> path, not to the whole componentized device.
>>
>> Okay, to throw a recent argument back at you: so what in this scenario
>> if you have a driver for the fixed-mode device but not the other device?
>>
>> It's exactly the same problem which you were describing to Sebastian
>> just a moment ago with drivers missing from the supernode approach -
>> you can't start if one of those "forced clone" drivers is missing.
>
> Indeed, then you will see nothing on your display, but I rather make
> this setup a special case than the rather usual case that we do not
> have compiled in all drivers for all devices referenced in the
> supernode.

The super-node links SoC internal devices that do not necessarily match
with the subsystem driver. You have one single DRM driver exploiting
several device nodes for a single video card.

But you need one device node to hook the driver to.

Sebastian