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

[Sean Paul]

On Wed, Oct 23, 2013 at 11:27 AM, Sean Paul <seanpaul at chromium.org> wrote:
> On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie <airlied at gmail.com> wrote:
>> On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul <seanpaul at chromium.org> wrote:
>>> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie <airlied at gmail.com> wrote:
>>>>> As I mentioned earlier, display_ops is needed to have no any
>>>>> dependency of drm framework directly like below,
>>>>>
>>>>>                                           DRM Framework
>>>>>                                                        |
>>>>>                                         Exynos DRM Framework
>>>>>                                                     /   |   \
>>>>>                                          Real device drivers
>>>>>
>>>>> In particular, in case of ARM based DRM drivers with separated
>>>>> devices, I still tend to think it's better design than that device
>>>>> drivers implement the connector callbacks directly, but I will try to
>>>>> consider what is the better way.
>>>>>
>>>>
>>>> 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.
>

tl;dr: What Rob said

> Sean
>
>> Dave.