On Wed, Oct 23, 2013 at 11:22 AM, Dave Airlie airlied@gmail.com wrote:
On Wed, Oct 23, 2013 at 3:45 PM, Sean Paul seanpaul@chromium.org wrote:
On Wed, Oct 23, 2013 at 10:29 AM, Dave Airlie airlied@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 driversIn 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.
I think we do definitely need a way to group nodes so we know what needs to be assembled into a drm driver. I know folks seem to believe that DT should be software agnostic, but maybe we just need some grouper nodes that sit on the side and know how to map device DT nodes to software.
(The real funny thing about needing that is.. well I've yet to see someone be able to hot-unplug a block on a piece of silicon.)
BR, -R
Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel