On Thu, Jul 4, 2013 at 5:28 PM, Dave Airlie <airlied@xxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
