> -----Original Message----- > From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth@xxxxxxxxx] > Sent: Thursday, July 04, 2013 4:25 PM > To: Inki Dae > Cc: 'Jean-Francois Moine'; 'Daniel Drake'; devicetree- > discuss@xxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; 'Sascha Hauer'; > 'Russell King' > Subject: Re: Best practice device tree design for display subsystems/DRM > > On 07/04/13 09:05, Inki Dae wrote: > >> -----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. > > Inki, > > I guess there is a misunderstanding of what lcd-controller and display- > controller are for on Dove. lcd-controller reads framebuffer from > memory, optionally does some conversions/scaling, and drives the SoCs > pins with pixel data and sync. display-controller (dcon) on Dove is for > mirroring lcd0 framebuffer to lcd1 framebuffer and some other things. > Right, there was definitely my misunderstanding. I haven't ever seen such hardware so I thought lcd controller means just lcd panel. I should really have read previous email threads. Thanks to your comments. I will have time to look into such hardware, and to think about that we really need the super node for such hardware. Thanks, Inki Dae > And, as stated several times, you cannot move internal-registers out of > the corresponding node on Dove. You _need_ that parent node for address > mapping. > > IMHO also fbdev needs the super-node because lcd0/1, dcon, > hdmi-transmitter, programmable-pll is what make up what you would call > a graphics card on x86. There is no such "graphics card" on most SoCs > but it is built up by using separate devices and SoC internal devices. > > Moreover, it is highly board dependent because you will easily find > another board manufacturer chosing a different hdmi-transmitter or > programmable-pll, using two lcd-controllers or just one. And there is > no way of probing the boards configuration. > > So even fvdev needs the super-node, there is no difference what video > subsystem you use - just because DT describes HW (even virtual one) not > subsystem. > > Sebastian _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
