drm: nest modeset locks within fpriv->fbs_lock
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Mon, 10 Dec 2012 22:44:22 +0000 (23:44 +0100)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Sun, 20 Jan 2013 21:17:03 +0000 (22:17 +0100)
commit7d331595b05d6f3c38567ad7031b75075557ce2a
treef54e1bfe657a524259a2870b7688bb97b53cc8e9
parent2b677e8c08eed11e4ebe66a7c334f03e389a19a3
drm: nest modeset locks within fpriv->fbs_lock

Atm we still need to unconditionally take the modeset locks in the
rmfb paths. But eventually we only want to take them if there are
other users around as a slow-path. This way sane userspace avoids
blocking on edid reads and other stuff in rmfb if it ensures that the
fb isn't used anywhere by a crtc/plane.

We can do a quick check for such other users once framebuffers are
properly refcounting by locking at the refcount - if it's more than 1,
there are other users left. Again, rmfb racing against other ioctls
isn't a real problem, userspace is allowed to shoot its foot.

This patch just prepares this by moving the modeset locks to nest
within fpriv->fbs_lock. Now the distinction between the fbs_lock and
the device-global fb_lock is clear, since we need to hold the fbs_lock
outside of any modeset_locks in fb_release.

Reviewed-by: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/drm_crtc.c