From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Hesselbarth Subject: Re: Best practice device tree design for display subsystems/DRM Date: Wed, 03 Jul 2013 13:51:56 +0200 Message-ID: <51D4105C.3070503@gmail.com> References: <20130702204255.2044c01b@armhf> <20130702191923.GD13924@flint.arm.linux.org.uk> <51D330AC.5060903@gmail.com> <51D348F5.2080205@gmail.com> <00ae01ce77cb$524d57f0$f6e807d0$%dae@samsung.com> <20130703090242.GM516@pengutronix.de> <51D3EA0E.2090008@gmail.com> <00ba01ce77d2$80285f10$80791d30$%dae@samsung.com> <20130703095338.GH13924@flint.arm.linux.org.uk> <51D40275.4020806@gmail.com> <00cc01ce77e2$844b3a80$8ce1af80$%dae@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <00cc01ce77e2$844b3a80$8ce1af80$%dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Inki Dae Cc: 'Jean-Francois Moine' , 'Daniel Drake' , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, 'Sascha Hauer' , 'Russell King' List-Id: devicetree@vger.kernel.org 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. Sebastian