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