> ...
>>> 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.
Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
