• Daniel Vetter's avatar
    drm: revamp framebuffer cleanup interfaces · 36206361
    Daniel Vetter authored
    We have two classes of framebuffer
    - Created by the driver (atm only for fbdev), and the driver holds
      onto the last reference count until destruction.
    - Created by userspace and associated with a given fd. These
      framebuffers will be reaped when their assoiciated fb is closed.
    
    Now these two cases are set up differently, the framebuffers are on
    different lists and hence destruction needs to clean up different
    things. Also, for userspace framebuffers we remove them from any
    current usage, whereas for internal framebuffers it is assumed that
    the driver has done this already.
    
    Long story short, we need two different ways to cleanup such drivers.
    Three functions are involved in total:
    - drm_framebuffer_remove: Convenience function which removes the fb
      from all active usage and then drops the passed-in reference.
    - drm_framebuffer_unregister_private: Will remove driver-private
      framebuffers from relevant lists and drop the corresponding
      references. Should be called for driver-private framebuffers before
      dropping the last reference (or like for a lot of the drivers where
      the fbdev is embedded someplace else, before doing the cleanup
      manually).
    - drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
      should be called by the driver's ->destroy callback once the last
      reference is gone.
    
    This patch just rolls out the new interfaces and updates all drivers
    (by adding calls to drm_framebuffer_unregister_private at all the
    right places)- no functional changes yet. Follow-on patches will move
    drm core code around and update the lifetime management for
    framebuffers, so that we are no longer required to keep framebuffers
    alive by locking mode_config.mutex.
    
    I've also updated the kerneldoc already.
    
    vmwgfx seems to again be a bit special, at least I haven't figured out
    how the fbdev support in that driver works. It smells like it's
    external though.
    
    v2: The i915 driver creates another private framebuffer in the
    load-detect code. Adjust its cleanup code, too.
    Reviewed-by: default avatarRob Clark <rob@ti.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    36206361
drm_crtc.c 101 KB