Best practice device tree design for display subsystems/DRM

[Sebastian Hesselbarth]

On 07/04/13 09:05, Inki Dae wrote:
>> -----Original Message-----
>> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
>> Sent: Wednesday, July 03, 2013 8:52 PM
>> To: Inki Dae
>> Cc: 'Russell King'; devicetree-discuss at lists.ozlabs.org; 'Jean-Francois
>> Moine'; 'Sascha Hauer'; 'Daniel Drake'; dri-devel at lists.freedesktop.org
>> Subject: Re: Best practice device tree design for display subsystems/DRM
>>
>> On 07/03/13 13:43, Inki Dae wrote:
>>>> I do not understand why you keep referring to the SoC dtsi. Im my
>>>> example, I said that it is made up and joined from both SoC dtsi and
>>>> board dts.
>>>>
>>>> So, of course, lcd controller nodes and dcon are part of dove.dtsi
>>>> because they are physically available on every Dove SoC.
>>>>
>>>> Also, the connection from lcd0 to the external HDMI encoder node
>>>> is in the board dts because you can happily build a Dove SoC board
>>>> with a different HDMI encoder or with no encoder at all.
>>>>
>>>> The video-card super node is not in any way specific to DRM and
>>>
>>> In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or
>> lcd0
>>> and lcd1 drivers which are placed in drivers/video/backlight/.
>>>
>>> And let's assume the following:
>>>
>>> On board A
>>>        Display controller ------------- lcd 0
>>> On board B
>>>        Display controller ------------- lcd 1
>>> On board C
>>>        Display controller ------------- lcd 0 and lcd 1
>>>
>>> Without the super node, user could configure Linux kernel through
>> menuconfig
>>> like below;
>>> 	board A:  enabling lcd 0, and disabling lcd 1,
>>> 	board B: disabling lcd 0, and enabling lcd 1,
>>> 	board C: enabling lcd 0 and lcd 1.
>>>
>>> All we have to do is to configure menuconfig to enable only drivers for
>>> certain board. Why does fbdev need the super node? Please give me
>> comments
>>> if there is my missing point.
>>
>> I assume when you say "configure menuconfig" you mean
>> "create a CONFIG_DISPLAY_CONTROLLER_AS_USED_ON_BOARD_A,
>> CONFIG_DISPLAY_CONTROLLER_AS_USED_ON_BOARD_B, ..." ?
>>
>> This finally will require you to have
>> (a) #ifdef mess for every single board _and_ driver above
>> (b) new CONFIG_.._BOARD_D plus new #ifdefs in fbdev driver for every
>>       new board
>> (c) A new set of the above CONFIG_/#ifdef for DRM driver
>>
>> This can also be done with device_tree and supernode approach,
>> so for your example above:
>>
>> BoardA.dts:
>> video { card0 { video-devices = <&lcd0>; }; };
>>
>> BoardB.dts:
>> video { card0 { video-devices = <&lcd1>; }; };
>>
>> BoardC.dts:
>> video { card0 { video-devices = <&lcd0 &lcd1>; }; };
>>
>> and in the driver your are prepared for looping over the video-devices
>> property and parsing the compatible string of the nodes passed.
>>
>
> As I mentioned before, fbdev don't need the super node, card0. Please see
> the below,
>
> BoardA.dts:
> video { dcon: display-controller at 830000 { video-devices = <&lcd0>; }; };
>
> BoardB.dts:
> video { dcon: display-controller at 830000 { video-devices = <&lcd1>; }; };
>
> BoardC.dts:
> video { dcon: display-controller at 830000 { video-devices = <&lcd0 &lcd1>; };
> };
>
> With the above dts file, does the fbdev have any problem? I just changed the
> super node to real hardware node. That is why the super node is specific to
> DRM.

Inki,

I guess there is a misunderstanding of what lcd-controller and display-
controller are for on Dove. lcd-controller reads framebuffer from
memory, optionally does some conversions/scaling, and drives the SoCs
pins with pixel data and sync. display-controller (dcon) on Dove is for
mirroring lcd0 framebuffer to lcd1 framebuffer and some other things.

And, as stated several times, you cannot move internal-registers out of
the corresponding node on Dove. You _need_ that parent node for address
mapping.

IMHO also fbdev needs the super-node because lcd0/1, dcon,
hdmi-transmitter, programmable-pll is what make up what you would call
a graphics card on x86. There is no such "graphics card" on most SoCs
but it is built up by using separate devices and SoC internal devices.

Moreover, it is highly board dependent because you will easily find
another board manufacturer chosing a different hdmi-transmitter or
programmable-pll, using two lcd-controllers or just one. And there is
no way of probing the boards configuration.

So even fvdev needs the super-node, there is no difference what video
subsystem you use - just because DT describes HW (even virtual one) not
subsystem.

Sebastian