Best practice device tree design for display subsystems/DRM

[Inki Dae]

> -----Original Message-----
> From: Russell King [mailto:rmk at 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 at lists.ozlabs.org; dri-
> devel at 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 at 820000 {
			compatible = "marvell,armada-510-lcd";
			reg = <0x820000 0x1000>;
			status = "disabled";
		};

		lcd1: lcd-controller at 810000 {
			compatible = "marvell,armada-510-lcd";
			reg = <0x810000 0x1000>;
			status = "disabled";
		};

		dcon: display-controller at 830000 {
			compatible = "marvell,armada-510-dcon";
			reg = <0x830000 0x100>;
			status = "disabled";
		};
	};
};

Board A.dts:
/include/ "dove.dtsi"

dcon: display-controller at 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 at 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 at 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