-----Original Message----- From: Russell King [mailto:rmk@arm.linux.org.uk] Sent: Wednesday, July 03, 2013 9:05 PM To: Inki Dae Cc: 'Sebastian Hesselbarth'; 'Sascha Hauer'; 'Daniel Drake'; 'Jean- Francois Moine'; devicetree-discuss@lists.ozlabs.org; dri- devel@lists.freedesktop.org Subject: Re: Best practice device tree design for display subsystems/DRM
On Wed, Jul 03, 2013 at 08:43:20PM +0900, Inki Dae wrote:
In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or
lcd0
and lcd1 drivers which are placed in drivers/video/backlight/.
No, that's totally wrong. Framebuffer drivers are not backlights. Framebuffer drivers go in drivers/video not drivers/video/backlight.
Really not that mean. Framebuffer driver controls DCON, and lcd panel driver controls lcd0 or lcd1. Maybe there is *wrong use of sentence* . Sorry about it.
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.
I don't think so. By using menuconfig, you completely miss the point of using DT - which is to allow us to have a single kernel image which can support multiple boards with different configurations, even different SoCs.
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.
fbdev needs the supernode _OR_ some way to specify that information which you're putting into menuconfig, because what's correct for the way one board is physically wired is not correct for how another board is physically wired.
With that information in menuconfig, you get a kernel image which can support board A, or board B, or board C but not a single kernel image which can support board A and board B and board C by loading that very same kernel image onto all three boards with just a different DT image.
This is the *whole* point of ARM moving over to DT.
If we wanted to use menuconfig to sort these kinds of board specific details, we wouldn't be investing so much time and effort into moving over to DT for ARM. In fact, we used to use menuconfig to sort out some of these kinds of details, and we've firmly decided that this is the wrong approach.
Today, there is a very strong push towards having a single kernel image which runs on every (modern) ARM board with DT describing not only the board level hardware but also the internal SoC as well.
Dear Russell. I understand what you try to do and that's true. Please see the below in addition,
dove.dtsi: ... soc { internal-regs { ... lcd0: lcd-controller@820000 { compatible = "marvell,armada-510-lcd"; reg = <0x820000 0x1000>; status = "disabled"; };
lcd1: lcd-controller@810000 { compatible = "marvell,armada-510-lcd"; reg = <0x810000 0x1000>; status = "disabled"; };
dcon: display-controller@830000 { compatible = "marvell,armada-510-dcon"; reg = <0x830000 0x100>; status = "disabled"; }; }; };
Board A.dts: /include/ "dove.dtsi"
dcon: display-controller@830000 { compatible = "marvell,armada-510-video", "linux,video-card"; linux,video-memory-size = <0x100000>; linux,video-devices = <&lcd0 &dcon>; }; ...
Board B.dts: /include/ "dove.dtsi"
dcon: display-controller@830000 { compatible = "marvell,armada-510-video", "linux,video-card"; linux,video-memory-size = <0x100000>; linux,video-devices = <&lcd1 &dcon>; }; ...
Board C.dts: /include/ "dove.dtsi"
dcon: display-controller@830000 { compatible = "marvell,armada-510-video", "linux,video-card"; linux,video-memory-size = <0x100000>; linux,video-devices = <&lcd0 &lcd1 &dcon>; }; ...
Like above, board specific dts files could have their own board specific information. So I think we can do and are already doing what you try to do without the super node. The super node don't really mean real hardware.
Thanks, Inki Dae
The OLPC setup (which seems to be the more common case in terms of the on-SoC device structure):
CPU bus | +-LCD ---(RGB666+clock+sync)----> LCD panel
and I believe an HDMI tranceiver somewhere.
(for the sake of simplicity, I am assuming OLPC is Armada 510 aka Dove, which it isn't)
dove-olpc.dts: /include/ "dove.dtsi"
video { card0 { compatible = "marvell,armada-510-video", "linux,video-card"; linux,video-memory-size = <0x100000>; linux,video-devices = <&lcd0>; }; };
&lcd0 { status = "okay"; /* core clock 5 = LCD PLL */ clocks = <&core_clk 5>; clock-names = "lcdclk"; /* pin config 1 = DUMB_RGB666 */ marvell,pin-configuration = <1>;
videomodes { mode_800x600 { ... }; }; };
-- Russell King