drm: refcnt drm_framebuffer (v4.1)

This simplifies drm fb lifetime, and if the crtc/plane needs to hold
a ref to the fb when disabling a pipe until the next vblank, this
avoids the need to make disabling an overlay synchronous.  This is a
problem that shows up when userspace is using a drm plane to
implement a hw cursor.. making overlay disable synchronous causes
a performance problem when x11 is rapidly enabling/disabling the
hw cursor.  But not making it synchronous opens up a race condition
for crashing if userspace turns around and immediately deletes the
fb.  Refcnt'ing the fb makes it possible to solve this problem.

v1: original
v2: add drm_framebuffer_remove() which is called in all paths where
    fb->funcs->destroy() was directly called before.  This cleans
    up the CRTCs/planes that the fb was attached to.  You should
    only directly use drm_framebuffer_unreference() if you are also
    using drm_framebuffer_reference() to keep a ref to the fb.
v3: add comment explaining the fb refcount
v4: remove duplicate 'list_del(&fb->filp_head)'

[airlied: v4.1: fix local rejection]

Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

1 files changed, 14 insertions, 0 deletions

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index eb91d520ce0b..68fdb299e39f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -218,6 +218,7 @@ struct drm_display_info {
 };
 
 struct drm_framebuffer_funcs {
+        /* note: use drm_framebuffer_remove() */
         void (*destroy)(struct drm_framebuffer *framebuffer);
         int (*create_handle)(struct drm_framebuffer *fb,
                              struct drm_file *file_priv,
@@ -242,6 +243,16 @@ struct drm_framebuffer_funcs {
 
 struct drm_framebuffer {
         struct drm_device *dev;
+        /*
+         * Note that the fb is refcounted for the benefit of driver internals,
+         * for example some hw, disabling a CRTC/plane is asynchronous, and
+         * scanout does not actually complete until the next vblank.  So some
+         * cleanup (like releasing the reference(s) on the backing GEM bo(s))
+         * should be deferred.  In cases like this, the driver would like to
+         * hold a ref to the fb even though it has already been removed from
+         * userspace perspective.
+         */
+        struct kref refcount;
         struct list_head head;
         struct drm_mode_object base;
         const struct drm_framebuffer_funcs *funcs;
@@ -919,6 +930,9 @@ extern void drm_framebuffer_set_object(struct drm_device *dev,
 extern int drm_framebuffer_init(struct drm_device *dev,
                                 struct drm_framebuffer *fb,
                                 const struct drm_framebuffer_funcs *funcs);
+extern void drm_framebuffer_unreference(struct drm_framebuffer *fb);
+extern void drm_framebuffer_reference(struct drm_framebuffer *fb);
+extern void drm_framebuffer_remove(struct drm_framebuffer *fb);
 extern void drm_framebuffer_cleanup(struct drm_framebuffer *fb);
 extern int drmfb_probe(struct drm_device *dev, struct drm_crtc *crtc);
 extern int drmfb_remove(struct drm_device *dev, struct drm_framebuffer *fb);