On 07/03/13 11:02, Sascha Hauer wrote:
On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:video { /* Single video card w/ multiple lcd controllers */ card0 { compatible = "marvell,armada-510-display"; reg = <0 0x3f000000 0x1000000>; /* video-mem hole */ /* later: linux,video-memory-size = <0x1000000>; */ marvell,video-devices = <&lcd0 &lcd1 &dcon>; }; /* OR: Multiple video card w/ single lcd controllers */ card0 { compatible = "marvell,armada-510-display"; ... marvell,video-devices = <&lcd0>; }; card1 { compatible = "marvell,armada-510-display"; ... marvell,video-devices = <&lcd1>; }; };Sorry but I'd like to say that this cannot be used commonly. Shouldn't you really consider Linux framebuffer or other subsystems? The above dtsi file is specific to DRM subsystem. And I think the dtsi file has no any dependency on certain subsystem so board dtsi file should be considered for all device drivers based on other subsystems: i.e., Linux framebuffer, DRM, and so no. So I *strongly* object to it. All we have to do is to keep the dtsi file as is, and to find other better way that can be used commonly in DRM.
Sascha, Inki, can you clarify how the above will _not_ allow you to write a fb driver exploiting the cardX nodes? While lcd controller and dcon are physically available, the video card is just a virtual combination of those.
+1 for not encoding the projected usecase of the graphics subsystem into the devicetree. Whether the two LCD controllers shall be used together or separately should not affect the devicetree. devicetree is about hardware description, not configuration.
Have you had a look at gpio-leds? It _is_ actually a configuration of GPIO to be used as LED triggers. IMHO DT is just fine for describing even "virtual" hardware you make up out of existing devices. Without it there is no way for the subsystems to determine the configuration. Regarding gpio-leds, how should the driver know the single gpio line out of tens of available lines, if you do not use a virtual gpio led node to describe it? Sebastian _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
