On Thu, Jan 23, 2014 at 10:42:02AM +0100, David Herrmann wrote:
Hi
On Thu, Jan 23, 2014 at 9:52 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
Driver modules really don't have much business frobbing around with this: Splitting up modeset resources (if we ever get around to enable this for real) should be something purely controlled and managed by the drm core in a driver-agnostic fashion. As usual imx disagrees, but that's due to the convoluted setup sequence. Russell King is working on a proper fix for that, so this patch needs to wait for those to land to avoid breaking imx.
I tried working on "modeset-object splitting" as part of the DRM-Master rework, but that's all really racy and we'd break current user-space. For instance the object-indices (compared to object-IDs) need to be constant, but with our current object-lists, removing an object will change indices (thus breaking possible_crtcs/encoders).
There are ways to make that work, but it'd require huge drm_crtc.c changes. And I also think our locking doesn't provide for that. Furthermore, resource-retrieval is not atomic (we need multiple ioctls: GetResources, GetCrtc, ...) so if we change the objects in between, we may break running apps in a subtle way.
So I'm all for making object-lists immutable after drm_dev_register() was called. Imo, hardware should wait for all sub-devices to be present and then call drm_dev_register(). Once the first sub-device is removed, you call drm_dev_unregister(). And I think that's what Russel's compound-device infrastructure does by hiding the sub-devices in a compound device.
If there's ever hardware that truly supports sub-device hotplugging, we can support that by adding a DRM-ClientCap like 3D modes. But as I understand, the current hardware is still a single piece of hardware which just might get probed via different buses and thus is not an atomic entity. So the device is still hotplugged as a whole, we just don't get the events through a single path.
Yeah, if we ever want to allow hotplugging after driver setup that's massive work to do it right. Which is why I want to plug this hole here before someone sneaks in for real ;-) -Daniel