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