Re: [PATCH 19/19] drm/kms: don't export drm_mode_group_init_legacy_group

[Daniel Vetter <daniel@ffwll.ch>]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch