public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Ignore GTFIFODBG FIFO free entry fields on CHV
Date: Thu, 14 Apr 2016 14:02:42 +0300	[thread overview]
Message-ID: <20160414110242.GI4329@intel.com> (raw)
In-Reply-To: <20160414093749.GJ2510@phenom.ffwll.local>

On Thu, Apr 14, 2016 at 11:37:49AM +0200, Daniel Vetter wrote:
> On Wed, Apr 13, 2016 at 09:09:30PM +0300, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > On CHV GTFIFODBG has some read-only bits to indicate the number
> > of free FIFO entries. Ignore these when checking to see if any
> > of the sticky error bits are set.
> > 
> > This gets rid of these during device resume:
> > [drm:cherryview_enable_rps] GT fifo had a previous error 1080000
> > 
> > While at it, move the assignments out of the if().
> > 
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Not entirely sure we don't want to filter even more, but these we want to
> filter for sure.
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> Also just realized that we don't check this on in the chv_write functions.
> Should we?

CHV is very weird in this regard. Supposedly it has both the wake FIFO
and the BDW style shadow register mechanism. The FIFO sits in front of
the shadow registers. I suppose when the power is off the FIFO just
feeds the shadow registers, meaning the FIFO should never be blocked.
In the past some pople tried to tell me that the wake FIFO doesn't exist
anymore, but the registers are clearly there, and some of the gunit
docs do still show it as present. In any case, I think the
recommendation was to rely on the shadow register stuff and ignore
the wake FIFO.

That was all before WaDisableShadowRegForCpd though. I think what that
does is disable the shadow register collapsing (in some cases at least),
and so I presume that might mean that the FIFO may in fact start to
fill up. So keeping an eye on the FIFO might make sense with that
workaround in place. But of course none of this is actually documented
anywhere.

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 2 ++
> >  drivers/gpu/drm/i915/intel_pm.c | 9 ++++++---
> >  2 files changed, 8 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index cea5a390d8c9..a0eaefc77602 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6866,6 +6866,8 @@ enum skl_disp_power_wells {
> >  #define  VLV_SPAREG2H				_MMIO(0xA194)
> >  
> >  #define  GTFIFODBG				_MMIO(0x120000)
> > +#define    GT_FIFO_SBDEDICATE_FREE_ENTRY_CHV	(0x1f << 20)
> > +#define    GT_FIFO_FREE_ENTRIES_CHV		(0x7f << 13)
> >  #define    GT_FIFO_SBDROPERR			(1<<6)
> >  #define    GT_FIFO_BLOBDROPERR			(1<<5)
> >  #define    GT_FIFO_SB_READ_ABORTERR		(1<<4)
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index b8e395ad05ac..b7c218602c6e 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4997,7 +4997,8 @@ static void gen6_enable_rps(struct drm_device *dev)
> >  	I915_WRITE(GEN6_RC_STATE, 0);
> >  
> >  	/* Clear the DBG now so we don't confuse earlier errors */
> > -	if ((gtfifodbg = I915_READ(GTFIFODBG))) {
> > +	gtfifodbg = I915_READ(GTFIFODBG);
> > +	if (gtfifodbg) {
> >  		DRM_ERROR("GT fifo had a previous error %x\n", gtfifodbg);
> >  		I915_WRITE(GTFIFODBG, gtfifodbg);
> >  	}
> > @@ -5528,7 +5529,8 @@ static void cherryview_enable_rps(struct drm_device *dev)
> >  
> >  	WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
> >  
> > -	gtfifodbg = I915_READ(GTFIFODBG);
> > +	gtfifodbg = I915_READ(GTFIFODBG) & ~(GT_FIFO_SBDEDICATE_FREE_ENTRY_CHV |
> > +					     GT_FIFO_FREE_ENTRIES_CHV);
> >  	if (gtfifodbg) {
> >  		DRM_DEBUG_DRIVER("GT fifo had a previous error %x\n",
> >  				 gtfifodbg);
> > @@ -5627,7 +5629,8 @@ static void valleyview_enable_rps(struct drm_device *dev)
> >  
> >  	valleyview_check_pctx(dev_priv);
> >  
> > -	if ((gtfifodbg = I915_READ(GTFIFODBG))) {
> > +	gtfifodbg = I915_READ(GTFIFODBG);
> > +	if (gtfifodbg) {
> >  		DRM_DEBUG_DRIVER("GT fifo had a previous error %x\n",
> >  				 gtfifodbg);
> >  		I915_WRITE(GTFIFODBG, gtfifodbg);
> > -- 
> > 2.7.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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:[~2016-04-14 11:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 18:09 [PATCH] drm/i915: Ignore GTFIFODBG FIFO free entry fields on CHV ville.syrjala
2016-04-14  9:37 ` Daniel Vetter
2016-04-14 11:02   ` Ville Syrjälä [this message]
2016-04-14 12:28   ` Ville Syrjälä
2016-04-20 12:47     ` Daniel Vetter
2016-04-20 13:11       ` Ville Syrjälä

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=20160414110242.GI4329@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel@ffwll.ch \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox