From: Matt Roper <matthew.d.roper@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Thierry Reding <treding@nvidia.com>,
DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm: Simplify fb refcounting rules around ->update_plane
Date: Wed, 23 Apr 2014 07:45:19 -0700 [thread overview]
Message-ID: <20140423144519.GU1063@intel.com> (raw)
In-Reply-To: <1398241805-24564-1-git-send-email-daniel.vetter@ffwll.ch>
On Wed, Apr 23, 2014 at 10:30:04AM +0200, Daniel Vetter wrote:
> 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.
>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_crtc.c | 13 +++++++------
> drivers/gpu/drm/drm_plane_helper.c | 16 ----------------
> 2 files changed, 7 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d8b7099abece..f6633cb927bc 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1145,16 +1145,17 @@ EXPORT_SYMBOL(drm_plane_cleanup);
> */
> void drm_plane_force_disable(struct drm_plane *plane)
> {
> + struct drm_framebuffer *old_fb = plane->fb;
> int ret;
>
> - if (!plane->fb)
> + if (!old_fb)
> return;
>
> ret = plane->funcs->disable_plane(plane);
> if (ret)
> DRM_ERROR("failed to disable plane with busy fb\n");
> /* disconnect the plane from the fb and crtc: */
> - __drm_framebuffer_unreference(plane->fb);
> + __drm_framebuffer_unreference(old_fb);
> plane->fb = NULL;
> plane->crtc = NULL;
> }
So if disable_plane() fails here, we'd still be scanning out of old_fb,
yet we deref it...that doesn't seem quite right.
As you mention, the changes here are just for paranoia since we can't
hit failure here as far as I know; force_disable() is only called in
drm_framebuffer_remove() (where a CRTC loop has already taken care of
removing the framebuffer from the primary plane) and
drm_fb_helper_restore_fbdev_mode() (where we explicitly skip primary
planes). Since only primary planes can fail to be disabled, I'd be
inclined to just add a BUG_ON(plane->type == DRM_PLANE_TYPE_PRIMARY) at
the start of this function with a comment update explaining that it
can't be called on primary planes, and a BUG_ON(ret) since
non-primary planes should never fail to be disabled.
...
> @@ -177,22 +176,7 @@ int drm_primary_helper_update(struct drm_plane *plane, struct drm_crtc *crtc,
> set.connectors = connector_list;
> set.num_connectors = num_connectors;
>
> - /*
> - * set_config() adjusts crtc->primary->fb; however the DRM setplane
> - * code that called us expects to handle the framebuffer update and
> - * reference counting; save and restore the current fb before
> - * calling it.
> - *
> - * N.B., we call set_config() directly here rather than using
> - * drm_mode_set_config_internal. We're reprogramming the same
> - * connectors that were already in use, so we shouldn't need the extra
> - * cross-CRTC fb refcounting to accomodate stealing connectors.
> - * drm_mode_setplane() already handles the basic refcounting for the
> - * framebuffers involved in this operation.
> - */
I think the second half of this comment (explaining why we call
set_config() directly rather than calling
drm_mode_set_config_internal()) still has some value.
Matt
> - tmpfb = plane->fb;
> ret = crtc->funcs->set_config(&set);
> - plane->fb = tmpfb;
>
> kfree(connector_list);
> return ret;
> --
> 1.9.2
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
next prev parent reply other threads:[~2014-04-23 14:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 9:07 [PATCH] drm: Simplify fb refcounting rules around ->update_plane Daniel Vetter
2014-04-22 9:16 ` Thierry Reding
2014-04-22 10:06 ` Ville Syrjälä
2014-04-22 14:09 ` Daniel Vetter
2014-04-22 14:28 ` Ville Syrjälä
2014-04-22 14:37 ` Daniel Vetter
2014-04-22 14:19 ` Daniel Vetter
2014-04-23 1:08 ` Matt Roper
2014-04-23 6:36 ` Daniel Vetter
2014-04-23 6:41 ` Daniel Vetter
2014-04-23 8:30 ` [PATCH 1/2] " Daniel Vetter
2014-04-23 8:30 ` [PATCH 2/2] drm: Handle ->disable_plane failures correctly Daniel Vetter
2014-04-23 14:47 ` Matt Roper
2014-04-23 14:45 ` Matt Roper [this message]
2014-04-23 15:25 ` [PATCH 1/2] drm: Simplify fb refcounting rules around ->update_plane Daniel Vetter
2014-04-23 15:37 ` [PATCH] " Daniel Vetter
2014-04-23 15:59 ` Matt Roper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140423144519.GU1063@intel.com \
--to=matthew.d.roper@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=treding@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.