Best practice device tree design for display subsystems/DRM

[Russell King]

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.

> 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.

-- 
Russell King