On 07/04/13 09:05, Inki Dae wrote:
-----Original Message-----
From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth@xxxxxxxxx]
Sent: Wednesday, July 03, 2013 8:52 PM
To: Inki Dae
Cc: 'Russell King'; devicetree-discuss@xxxxxxxxxxxxxxxx; 'Jean-Francois
Moine'; 'Sascha Hauer'; 'Daniel Drake'; dri-devel@xxxxxxxxxxxxxxxxxxxxx
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.
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
