• D
    drm: revamp locking around fb creation/destruction · 4b096ac1
    Daniel Vetter 提交于
    Well, at least step 1. The goal here is that framebuffer objects can
    survive outside of the mode_config lock, with just a reference held
    as protection. The first step to get there is to introduce a special
    fb_lock which protects fb lookup, creation and destruction, to make
    them appear atomic.
    
    This new fb_lock can nest within the mode_config lock. But the idea is
    (once the reference counting part is completed) that we only quickly
    take that fb_lock to lookup a framebuffer and grab a reference,
    without any other locks involved.
    
    vmwgfx is the only driver which does framebuffer lookups itself, also
    wrap those calls to drm_mode_object_find with the new lock.
    
    Also protect the fb_list walking in i915 and omapdrm with the new lock.
    
    As a slight complication there's also the list of user-created fbs
    attached to the file private. The problem now is that at fclose() time
    we need to walk that list, eventually do a modeset call to remove the
    fb from active usage (and are required to be able to take the
    mode_config lock), but in the end we need to grab the new fb_lock to
    remove the fb from the list. The easiest solution is to add another
    mutex to protect this per-file list.
    
    Currently that new fbs_lock nests within the modeset locks and so
    appears redudant. But later patches will switch around this sequence
    so that taking the modeset locks in the fb destruction path is
    optional in the fastpath. Ultimately the goal is that addfb and rmfb
    do not require the mode_config lock, since otherwise they have the
    potential to introduce stalls in the pageflip sequence of a compositor
    (if the compositor e.g. switches to a fullscreen client or if it
    enables a plane). But that requires a few more steps and hoops to jump
    through.
    
    Note that framebuffer creation/destruction is now double-protected -
    once by the fb_lock and in parts by the idr_lock. The later would be
    unnecessariy if framebuffers would have their own idr allocator. But
    that's material for another patch (series).
    
    v2: Properly initialize the fb->filp_head list in _init, otherwise the
    newly added WARN to check whether the fb isn't on a fpriv list any
    more will fail for driver-private objects.
    
    v3: Fixup two error-case unlock bugs spotted by Richard Wilbur.
    Reviewed-by: NRob Clark <rob@ti.com>
    Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    4b096ac1
i915_debugfs.c 56.9 KB