[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Dave Airlie]

>>>>>
>>>>
>>>> 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.

Dave.