On Thu, Jul 04, 2013 at 10:33:07AM +0200, 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).
Wrong. Please read the example with the diagrams I gave. Consider what happens if you have two display devices connected to a single output, one which fixes the allowable mode and one which _can_ reformat the selected mode.
If you go down that path, you risk driving the LCD panel with inappropriate timings which may damage it.