> -----Original Message----- > From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth@xxxxxxxxx] > Sent: Wednesday, July 03, 2013 8:52 PM > To: Inki Dae > Cc: 'Russell King'; devicetree-discuss@xxxxxxxxxxxxxxxx; 'Jean-Francois > Moine'; 'Sascha Hauer'; 'Daniel Drake'; dri-devel@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: Best practice device tree design for display subsystems/DRM > > 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. > As I mentioned before, fbdev don't need the super node, card0. Please see the below, BoardA.dts: video { dcon: display-controller@830000 { video-devices = <&lcd0>; }; }; BoardB.dts: video { dcon: display-controller@830000 { video-devices = <&lcd1>; }; }; BoardC.dts: video { dcon: display-controller@830000 { video-devices = <&lcd0 &lcd1>; }; }; With the above dts file, does the fbdev have any problem? I just changed the super node to real hardware node. That is why the super node is specific to DRM. Thanks, Inki Dae > Sebastian _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
