All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 4/4] drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced
Date: Tue, 20 Feb 2018 15:59:53 +0200	[thread overview]
Message-ID: <20180220135953.GE5453@intel.com> (raw)
In-Reply-To: <20180220134208.24988-4-chris@chris-wilson.co.uk>

On Tue, Feb 20, 2018 at 01:42:08PM +0000, Chris Wilson wrote:
> Rather than trusting the cached value of plane_state->vma->fence to
> imply whether the plane_state itself holds a reference on the
> framebuffer's fence, use the information provided in the
> plane_state->flags (PLANE_HAS_FENCE). Note that we still assume that FBC
> is entirely bounded by the plane_state active life span; it's not clear
> if that is a safe assumption.
> 
> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_fbc.c | 13 +++++++++----
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20575b3ee406..848dc8f68b47 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -667,6 +667,7 @@ struct intel_fbc {
>  	 */
>  	struct intel_fbc_state_cache {
>  		struct i915_vma *vma;
> +		unsigned long flags;
>  
>  		struct {
>  			unsigned int mode_flags;
> @@ -705,6 +706,7 @@ struct intel_fbc {
>  	 */
>  	struct intel_fbc_reg_params {
>  		struct i915_vma *vma;
> +		unsigned long flags;
>  
>  		struct {
>  			enum pipe pipe;
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
> index d7d1ac79c38a..f66f6fb5743d 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -183,7 +183,7 @@ static void g4x_fbc_activate(struct drm_i915_private *dev_priv)
>  	else
>  		dpfc_ctl |= DPFC_CTL_LIMIT_1X;
>  
> -	if (params->vma->fence) {
> +	if (params->flags & PLANE_HAS_FENCE) {

These checks seem redundant now that we shouldn't even try to enable fbc
without the fence. But they're not harming anyone (well, apart from making
the code a bit inconsistent by not having the check in the fbc1 codepath).

But the patch is 
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
regardless

>  		dpfc_ctl |= DPFC_CTL_FENCE_EN | params->vma->fence->id;
>  		I915_WRITE(DPFC_FENCE_YOFF, params->crtc.fence_y_offset);
>  	} else {
> @@ -241,7 +241,7 @@ static void ilk_fbc_activate(struct drm_i915_private *dev_priv)
>  		break;
>  	}
>  
> -	if (params->vma->fence) {
> +	if (params->flags & PLANE_HAS_FENCE) {
>  		dpfc_ctl |= DPFC_CTL_FENCE_EN;
>  		if (IS_GEN5(dev_priv))
>  			dpfc_ctl |= params->vma->fence->id;
> @@ -324,7 +324,7 @@ static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
>  		break;
>  	}
>  
> -	if (params->vma->fence) {
> +	if (params->flags & PLANE_HAS_FENCE) {
>  		dpfc_ctl |= IVB_DPFC_CTL_FENCE_EN;
>  		I915_WRITE(SNB_DPFC_CTL_SA,
>  			   SNB_CPU_FENCE_ENABLE |
> @@ -753,6 +753,7 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
>  	struct drm_framebuffer *fb = plane_state->base.fb;
>  
>  	cache->vma = NULL;
> +	cache->flags = 0;
>  
>  	cache->crtc.mode_flags = crtc_state->base.adjusted_mode.flags;
>  	if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> @@ -778,6 +779,9 @@ static void intel_fbc_update_state_cache(struct intel_crtc *crtc,
>  	cache->fb.stride = fb->pitches[0];
>  
>  	cache->vma = plane_state->vma;
> +	cache->flags = plane_state->flags;
> +	if (WARN_ON(cache->flags & PLANE_HAS_FENCE && !cache->vma->fence))
> +		cache->flags &= ~PLANE_HAS_FENCE;
>  }
>  
>  static bool intel_fbc_can_activate(struct intel_crtc *crtc)
> @@ -816,7 +820,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>  	 * so have no fence associated with it) due to aperture constaints
>  	 * at the time of pinning.
>  	 */
> -	if (!cache->vma->fence) {
> +	if (!(cache->flags & PLANE_HAS_FENCE)) {
>  		fbc->no_fbc_reason = "framebuffer not tiled or fenced";
>  		return false;
>  	}
> @@ -897,6 +901,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc *crtc,
>  	memset(params, 0, sizeof(*params));
>  
>  	params->vma = cache->vma;
> +	params->flags = cache->flags;
>  
>  	params->crtc.pipe = crtc->pipe;
>  	params->crtc.i9xx_plane = to_intel_plane(crtc->base.primary)->i9xx_plane;
> -- 
> 2.16.1

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-02-20 13:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 13:42 [PATCH v2 1/4] drm/i915: Also check view->type for a normal GGTT view Chris Wilson
2018-02-20 13:42 ` [PATCH v2 2/4] drm/i915: Move the policy for placement of the GGTT vma into the caller Chris Wilson
2018-02-20 13:42 ` [PATCH v2 3/4] drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning Chris Wilson
2018-02-20 13:56   ` Ville Syrjälä
2018-02-20 13:42 ` [PATCH v2 4/4] drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced Chris Wilson
2018-02-20 13:59   ` Ville Syrjälä [this message]
2018-02-20 14:02     ` Chris Wilson
2018-02-20 14:49 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915: Also check view->type for a normal GGTT view Patchwork
2018-02-20 15:04 ` ✓ Fi.CI.BAT: success " Patchwork
2018-02-20 20:36 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-02-20 20:39   ` 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=20180220135953.GE5453@intel.com \
    --to=ville.syrjala@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.