All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 1/5] drm/i915: Track pinned vma in intel_plane_state
Date: Thu, 19 Jan 2017 11:45:24 +0200	[thread overview]
Message-ID: <1484819124.3275.2.camel@linux.intel.com> (raw)
In-Reply-To: <20170116152131.18089-1-chris@chris-wilson.co.uk>

On ma, 2017-01-16 at 15:21 +0000, Chris Wilson wrote:
> With atomic plane states we are able to track an allocation right from
> preparation, during use and through to the final free after being
> swapped out for a new plane. We can couple the VMA we pin for the
> framebuffer (and its rotation) to this lifetime and avoid all the clumsy
> lookups in between.
> 
> v2: Remove residual vma on plane cleanup (Chris)
> v3: Add a description for the vma destruction in
>     intel_plane_destroy_state (Maarten)
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98829
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Regards, Joonas

<SNIP>

>  intel_cleanup_plane_fb(struct drm_plane *plane,
>  		       struct drm_plane_state *old_state)
>  {

<SNIP>

> -	if (old_obj && (plane->type != DRM_PLANE_TYPE_CURSOR ||
> -	    !INTEL_INFO(dev_priv)->cursor_needs_physical))
> -		intel_unpin_fb_obj(old_state->fb, old_state->rotation);
> +	/* Should only called after a successful intel_prepare_plane_fb()! */

Should only be...

> +	vma = fetch_and_zero(&to_intel_plane_state(old_state)->vma);
> +	if (vma)
> +		intel_unpin_fb_vma(vma);
>  }

Apart from that, it's good as far as the GEM changes go, so;

Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

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

  parent reply	other threads:[~2017-01-19  9:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 15:21 [PATCH v2 1/5] drm/i915: Track pinned vma in intel_plane_state Chris Wilson
2017-01-16 15:21 ` [PATCH v2 2/5] drm/i915: Rename some warts in the VMA API Chris Wilson
2017-01-16 15:21 ` [PATCH v2 3/5] drm/i915: Add a check that the VMA instance we lookup matches the request Chris Wilson
2017-01-17  7:34   ` Joonas Lahtinen
2017-01-16 15:21 ` [PATCH v2 4/5] drm/i915: Remove i915_vma_create from VMA API Chris Wilson
2017-01-16 15:21 ` [PATCH v2 5/5] drm/i915: Remove i915_gem_object_to_ggtt() Chris Wilson
2017-01-17  8:10   ` Joonas Lahtinen
2017-01-16 16:24 ` ✗ Fi.CI.BAT: warning for series starting with [v2,1/5] drm/i915: Track pinned vma in intel_plane_state Patchwork
2017-01-19  9:45 ` Joonas Lahtinen [this message]
2017-01-19 11:13   ` [PATCH v2 1/5] " Chris Wilson

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=1484819124.3275.2.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@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.