2013/10/23 Sean Paul <seanpaul@xxxxxxxxxxxx>: > 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. > Before that, I think we need to decide that drm driver should reuse lcd class based drivers, or just should copy the lcd class based drivers into drm framework. 1. in case that drm driver reuses the existing lcd class based drivers, - we would need a common layer across between Linux framebuffer and drm framework. In other words, the lcd class based drivers and drm driver should be able to include a header file to the common layer, and the header should provide some callbacks such as drm_panel structure, and also some functions to create a connector and a encoder. Actually, that is why Exynos drm framework has a wrapper to drm connector and encoder, and display_ops also. 2. in case that drm driver uses duplicated lcd driver, - we wouldn't need the common layer because a connector and a encoder can be created directly in the lcd driver so in this case, I think the wrapper to drm connector and display_ops wouldn't be needed anymore. And shouldn't the device tree related works be discussed after we select one of the above two cases? or should we consider all of the above two cases? > 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. >> >> Dave. > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
