On Wed, Feb 15, 2017 at 03:59:23PM +0200, Joonas Lahtinen wrote:
> On ke, 2017-02-15 at 10:59 +0000, Chris Wilson wrote:
> > We do not need to hold struct_mutex for destroying drm_i915_gem_objects
> > any longer, and with a little care taken over tracking
> > obj->framebuffer_references, we can relinquish BKL locking around the
> > destroy of intel_framebuffer.
> >
> > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
>
> <SNIP>
>
> > @@ -14266,14 +14266,14 @@ static void intel_setup_outputs(struct
> > drm_i915_private *dev_priv)
> >
> > static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > {
> > - struct drm_device *dev = fb->dev;
> > struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> >
> > drm_framebuffer_cleanup(fb);
> > - mutex_lock(&dev->struct_mutex);
> > - WARN_ON(!intel_fb->obj->framebuffer_references--);
> > +
> > + WARN_ON(atomic_read(&intel_fb->obj->framebuffer_references) == 0);
> > + atomic_dec(&intel_fb->obj->framebuffer_references);
>
> Umm isn't the point of atomicity that you do this in one step?
Sure, just wasn't actually thinking of it a as real atomic.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
