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@xxxxxxxxxxxxxxx wrote:
> > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxxxxxxxxx>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxx>
>
> 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@xxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
