Best practice device tree design for display subsystems/DRM

[Inki Dae]

> -----Original Message-----
> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
> Sent: Thursday, July 04, 2013 4:25 PM
> To: Inki Dae
> Cc: 'Jean-Francois Moine'; 'Daniel Drake'; devicetree-
> discuss at lists.ozlabs.org; dri-devel at lists.freedesktop.org; 'Sascha Hauer';
> 'Russell King'
> Subject: Re: Best practice device tree design for display subsystems/DRM
> 
> 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.
> 

Right, there was definitely my misunderstanding. I haven't ever seen such
hardware so I thought lcd controller means just lcd panel. I should really
have read previous email threads. Thanks to your comments. I will have time
to look into such hardware, and to think about that we really need the super
node for such hardware.

Thanks,
Inki Dae

> 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