On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie <airlied@xxxxxxxxx> wrote:
>>>>>>
>>>>>
>>>>> I think we need to start considering a framework where subdrivers just
>>>>> add drm objects themselves, then the toplevel node is responsible for
>>>>> knowing that everything for the current configuration is loaded.
>>>>>
>>>>
>>>> It would be nice to specify the various pieces in dt, then have some
>>>> type of drm notifier to the toplevel node when everything has been
>>>> probed. Doing it in the dt would allow standalone drm_bridge/drm_panel
>>>> drivers to be transparent as far as the device's drm driver is
>>>> concerned.
>>>>
>>>> Sean
>>>>
>>>>
>>>>> I realise we may need to make changes to the core drm to allow this
>>>>> but we should probably start to create a strategy for fixing the API
>>>>> issues that this throws up.
>>>>>
>>>>> Note I'm not yet advocating for dynamic addition of nodes once the
>>>>> device is in use, or removing them.
>>>>>
>>>
>>> I do wonder if we had some sort of tag in the device tree for any nodes
>>> involved in the display, and the core drm layer would read that list,
>>> and when every driver registers tick things off, and when the last one
>>> joins we get a callback and init the drm layer, we'd of course have the
>>> basic drm layer setup prior to that so we can add the objects as the
>>> drivers load. It might make development a bit trickier as you'd need
>>> to make sure someone claimed ownership of all the bits for init to proceed.
>>>
>>
>> Yeah, that's basically what the strawman looked like in my head.
>>
>> Instead of a property in each node, I was thinking of having a
>> separate gfx pipe nodes that would have dt pointers to the various
>> pieces involved in that pipe. This would allow us to associate
>> standalone entities like bridges and panels with encoders in dt w/o
>> doing it in the drm code. I *think* this should be Ok with the dt guys
>> since it is still describing the hardware, but I think we'd have to
>> make sure it wasn't drm-specific.
>>
>
> I suppose the question is how much dynamic pipeline construction there is,
>
> even on things like radeon and i915 we have dynamic clock generator to
> crtc to encoder setups, so I worry about static lists per-pipe, so I still
> think just stating all these devices are needed for display and a list of valid
> interconnections between them, then we can have the generic code model
> drm crtc/encoders/connectors on that list, and construct the possible_crtcs
> /possible_clones etc at that stage.
>
I'm, without excuse, hopeless at devicetree, so there are probably
some violations, but something like:
display-pipelines {
required-elements = <&bridge-a &panel-a &encoder-x &encoder-y
&crtc-x &crtc-y>;
pipe1 {
bridge = <&bridge-a>;
encoder = <&encoder-x>;
crtc = <&crtc-y>;
};
pipe2 {
encoder = <&encoder-x>;
crtc = <&crtc-x>;
};
pipe3 {
panel = <&panel-a>;
encoder = <&encoder-y>;
crtc = <&crtc-y>;
};
};
I'm tempted to add connector to the pipe nodes as well, so it's
obvious which connector should be used in cases where multiple
entities in the pipe implement drm_connector. However, I'm not sure if
that would be NACKed by dt people.
I'm also not sure if there are too many combinations for i915 and
radeon to make this unreasonable. I suppose those devices could just
use required-elements and leave the pipe nodes out.
Sean
> Dave.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
