-----Original Message----- From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth@gmail.com] Sent: Wednesday, July 03, 2013 8:52 PM To: Inki Dae Cc: 'Russell King'; devicetree-discuss@lists.ozlabs.org; 'Jean-Francois Moine'; 'Sascha Hauer'; 'Daniel Drake'; dri-devel@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@830000 { video-devices = <&lcd0>; }; };
BoardB.dts: video { dcon: display-controller@830000 { video-devices = <&lcd1>; }; };
BoardC.dts: video { dcon: display-controller@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.
Thanks, Inki Dae
Sebastian