From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm: Simplify fb refcounting rules around ->update_plane
Date: Tue, 22 Apr 2014 13:06:22 +0300 [thread overview]
Message-ID: <20140422100622.GU18465@intel.com> (raw)
In-Reply-To: <1398157633-31043-1-git-send-email-daniel.vetter@ffwll.ch>
On Tue, Apr 22, 2014 at 11:07:13AM +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 their
> 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.
>
> - The core will update fb refcounts for the plane->fb pointer,
> presuming the drivers hold up their end of the bargain.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_crtc.c | 12 +++++-------
> drivers/gpu/drm/drm_plane_helper.c | 15 ---------------
> 2 files changed, 5 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d8b7099abece..966b480ed543 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2187,24 +2187,24 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
> }
>
> drm_modeset_lock_all(dev);
> + old_fb = plane->fb;
> ret = plane->funcs->update_plane(plane, crtc, fb,
> plane_req->crtc_x, plane_req->crtc_y,
> plane_req->crtc_w, plane_req->crtc_h,
> plane_req->src_x, plane_req->src_y,
> plane_req->src_w, plane_req->src_h);
> if (!ret) {
> - old_fb = plane->fb;
> plane->crtc = crtc;
> plane->fb = fb;
> - fb = NULL;
> }
> drm_modeset_unlock_all(dev);
>
> out:
> - if (fb)
> - drm_framebuffer_unreference(fb);
> + if (plane->fb)
> + drm_framebuffer_reference(old_fb);
^^^^^^
That doesn't look right.
Also you're now dereferencing plane->fb after you drop the locks.
Also i915 fb destruction seems buggy as we do
intel_fb->obj->framebuffer_references-- w/o holding struct_mutex.
> if (old_fb)
> drm_framebuffer_unreference(old_fb);
> + drm_framebuffer_unreference(fb);
>
> return ret;
> }
> @@ -2239,9 +2239,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
> ret = crtc->funcs->set_config(set);
> if (ret == 0) {
> crtc->primary->crtc = crtc;
> -
> - /* crtc->fb must be updated by ->set_config, enforces this. */
> - WARN_ON(fb != crtc->primary->fb);
> + crtc->primary->fb = fb;
> }
>
> list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head) {
> diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c
> index e768d35ff22e..8db129c44fea 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -175,22 +175,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.
> - */
> - tmpfb = plane->fb;
> ret = crtc->funcs->set_config(&set);
> - plane->fb = tmpfb;
>
> kfree(connector_list);
> return ret;
> --
> 1.9.2
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2014-04-22 10:06 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ä [this message]
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 ` [PATCH 1/2] drm: Simplify fb refcounting rules around ->update_plane Matt Roper
2014-04-23 15:25 ` 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=20140422100622.GU18465@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
/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.