On Thu, Jul 4, 2013 at 5:28 PM, Dave Airlie airlied@gmail.com 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.
I do like the supernode idea, it would have avoided the ugly global-list-of-sub-devices in tilcdc (and probably some other drivers).
As for projection of use-case, and whether it is something drm specific or not.. if there is a way to make it generic enough that it could work for fbdev, well I suppose that is nice. Not a hard requirement in my mind, or at least it is a secondary priority compared to having a better way to having drm devices composed of sub-{devices,nodes,whatever}.
I'm not following who has the requirement for exposing different output device paths as possibly one or two devices, so you could have a drm device for one or the other, or X could use a subset of devices.
I'm not really sure how best to deal with that, we have had plans for drm to actually expose sub-groups of crtc/encoders/connectors to userspace via different device nodes for a while, its just never received the final push on how to configure it.
David Herrmann is working on that as part of the GSoC render node project: http://dvdhrm.wordpress.com/2013/05/29/drm-render-and-modeset-nodes/
Alex