On 07/04/13 10:33, Sascha Hauer wrote: > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: >>>> 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. >>> >>> +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. >> >> And if we listen to that argument, then this problem is basically >> impossible to solve sanely. >> >> Are we really saying that we have no acceptable way to represent >> componentized devices in DT? If that's true, then DT fails to represent >> quite a lot of ARM hardware, and frankly we shouldn't be using it. I >> can't believe that's true though. >> >> The problem is that even with an ASoC like approach, that doesn't work >> here because there's no way to know how many "components" to expect. >> That's what the "supernode" is doing - telling us what components group >> together to form a device. > > A componentized device never completes and it doesn't have to. A > componentized device can start once there is a path from an input > (crtc, i2s unit) to an output (connector, speaker). > > Consider what happens with a supernode approach. Your board provides a > devicetree which has a supernode with hdmi and lvds referenced. Now you > build a kernel with the hdmi driver disabled. You would still expect the > lvds port to be working without having the kernel wait for the supernode > being complete. > > Without supernode you can just start once you have everything between > the crtc and lvds nodes. If later a hdmi device joins in then you can > either notify the users (provided the DRM/KMS API supports it) or just > ignore it until the DRM device gets reopened.
Sascha, that is what it is all about. You assume you a priori know what devices will be required for the componentized device to successfully output a video stream. We have shown setups where you don't know what is required. Cubox _needs_ lcd0 and hdmi-transmitter, olpc just needs lcd0 and has built-in hdmi in the SoC (IIRC). The driver needs to know what to wait for, and that is given by the DT super-node. I consider kernels with missing drivers compared to what is given in the DT as broken setup. You cannot complain about missing SATA if you leave out SATA driver, or - if you implemented the driver into two parts - leave out one of the two SATA driver parts. Sebastian
