• Daniel Vetter's avatar
    drm: Simplify fb refcounting rules around ->update_plane · 0fe27f06
    Daniel Vetter authored
    The introduction of primary planes has apparently caused a bit of fb
    refcounting fun for people. That makes it a good time to clean up the
    arcane rules and slight differences between ->update_plane and
    ->set_config. The new rules are:
    
    - The core holds a reference for both the new and the old fb (if
      they're non-NULL of course) while calling into the driver through
      either ->update_plane or ->set_config.
    
    - Drivers may not clobber plane->fb if their callback fails. If they
      do that, they need to store a pointer to the old fb in it again.
      When calling into the driver plane->fb still points at the current
      (old) framebuffer.
    
    - The core will update the plane->fb pointer on success. Drivers can
      do that themselves too, but aren't required to any more for the
      primary plane.
    
    - The core will update fb refcounts for the plane->fb pointer,
      presuming the drivers hold up their end of the bargain.
    
    v2: Remove now unused tmpfb (Thierry)
    
    v3: Drop broken changes from drm_mode_setplane (Ville). Also polish
    the commit message a bit.
    
    v4: Also fix up the handling of ->disable_plane in
    drm_plane_force_disable. The issue was that we didn't save plane->fb
    over the ->disable_plane call. Just paranoia, nothing relies on this.
    
    v5: Keep still useful comments about directly calling ->set_config,
    which I should have done for v4 already. Requested by Matt.
    
    Cc: Thierry Reding <treding@nvidia.com>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Matt Roper <matthew.d.roper@intel.com>
    Reviewed-by: default avatarMatt Roper <matthew.d.roper@intel.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    0fe27f06
drm_crtc.c 124 KB