On Wed, Oct 23, 2013 at 11:27 AM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: > On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie <airlied@xxxxxxxxx> wrote: >> On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul <seanpaul@xxxxxxxxxxxx> wrote: >>> On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie <airlied@xxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
