• Daniel Vetter's avatar
    drm: nest modeset locks within fpriv->fbs_lock · 7d331595
    Daniel Vetter authored
    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: default avatarRob Clark <rob@ti.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    7d331595
drm_crtc.c 102 KB