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?
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
