All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: prevent gt fifo count underflow
Date: Wed, 14 May 2014 16:35:42 +0300	[thread overview]
Message-ID: <20140514133542.GL18465@intel.com> (raw)
In-Reply-To: <1400073482-15056-1-git-send-email-mika.kuoppala@intel.com>

On Wed, May 14, 2014 at 04:18:02PM +0300, Mika Kuoppala wrote:
> If we get the final value of zero as a count of free
> entries available, we will underflow our own fifo_count
> and then it will take a long time before we check things again.
> Admittedly we are in trouble already if we get into this situation,
> but prevent the underflow by returning early.
> 
> v2: Less convoluted control flow (Daniel Vetter)
> 
> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_uncore.c |   20 +++++++++-----------
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 76dc185..bf1b661 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -154,10 +154,8 @@ static void __gen7_gt_force_wake_mt_put(struct drm_i915_private *dev_priv,
>  		gen6_gt_check_fifodbg(dev_priv);
>  }
>  
> -static int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
> +static bool __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
>  {
> -	int ret = 0;
> -
>  	/* On VLV, FIFO will be shared by both SW and HW.
>  	 * So, we need to read the FREE_ENTRIES everytime */
>  	if (IS_VALLEYVIEW(dev_priv->dev))
> @@ -173,12 +171,12 @@ static int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
>  			fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) & GT_FIFO_FREE_ENTRIES_MASK;
>  		}
>  		if (WARN_ON(loop < 0 && fifo <= GT_FIFO_NUM_RESERVED_ENTRIES))

Maybe kill the 'loop<0' check while at it. It's redundant and IMO just
makes things less obvious.

Also I don't get why we first check for
'fifo_count < GT_FIFO_NUM_RESERVED_ENTRIES', but then the while
loop checks for 'fifo <= GT_FIFO_NUM_RESERVED_ENTRIES'.

> -			++ret;
> +			return true;
>  		dev_priv->uncore.fifo_count = fifo;

We no longer update fifo_count on failure. Not really a problem, but
since we've already done all the work maybe we should still update it.

>  	}
>  	dev_priv->uncore.fifo_count--;
>  
> -	return ret;
> +	return false;
>  }
>  
>  static void vlv_force_wake_reset(struct drm_i915_private *dev_priv)
> @@ -642,13 +640,13 @@ gen5_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool trace
>  #define __gen6_write(x) \
>  static void \
>  gen6_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool trace) { \
> -	u32 __fifo_ret = 0; \
> +	bool __fifo_failed = false; \
>  	REG_WRITE_HEADER; \
>  	if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> -		__fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
> +		__fifo_failed = __gen6_gt_wait_for_fifo(dev_priv); \
>  	} \
>  	__raw_i915_write##x(dev_priv, reg, val); \
> -	if (unlikely(__fifo_ret)) { \
> +	if (unlikely(__fifo_failed)) { \
>  		gen6_gt_check_fifodbg(dev_priv); \
>  	} \
>  	REG_WRITE_FOOTER; \
> @@ -657,14 +655,14 @@ gen6_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool trace
>  #define __hsw_write(x) \
>  static void \
>  hsw_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool trace) { \
> -	u32 __fifo_ret = 0; \
> +	bool __fifo_failed = false; \
>  	REG_WRITE_HEADER; \
>  	if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> -		__fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
> +		__fifo_failed = __gen6_gt_wait_for_fifo(dev_priv); \
>  	} \
>  	hsw_unclaimed_reg_clear(dev_priv, reg); \
>  	__raw_i915_write##x(dev_priv, reg, val); \
> -	if (unlikely(__fifo_ret)) { \
> +	if (unlikely(__fifo_failed)) { \
>  		gen6_gt_check_fifodbg(dev_priv); \
>  	} \
>  	hsw_unclaimed_reg_check(dev_priv, reg); \
> -- 
> 1.7.9.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-05-14 13:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14 12:10 [PATCH] drm/i915: prevent gt fifo count underflow Mika Kuoppala
2014-05-14 13:18 ` Mika Kuoppala
2014-05-14 13:35   ` Ville Syrjälä [this message]
2014-05-14 13:48     ` Chris Wilson
2014-05-14 14:22     ` [PATCH v3] " Mika Kuoppala

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=20140514133542.GL18465@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mika.kuoppala@linux.intel.com \
    /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.