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 v6] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen
Date: Mon, 17 Dec 2018 20:13:46 +0200 [thread overview]
Message-ID: <20181217181346.GR9144@intel.com> (raw)
In-Reply-To: <154507006564.1108.16918109584153130933@skylake-alporthouse-com>
On Mon, Dec 17, 2018 at 06:07:45PM +0000, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-12-17 18:02:25)
> > On Mon, Dec 17, 2018 at 03:20:55PM +0000, Chris Wilson wrote:
> > > Having completed a test run of gem_eio across all machines in CI we also
> > > observe the phenomenon (of lost interrupts after resetting the GPU) on
> > > gen3 machines as well as the previously sighted gen6/gen7. Let's apply
> > > the same HWSTAM workaround that was effective for gen6+ for all, as
> > > although we haven't seen the same failure on gen4/5 it seems prudent to
> > > keep the code the same.
> > >
> > > As a consequence we can remove the extra setting of HWSTAM and apply the
> > > register from a single site.
> > >
> > > v2: Delazy and move the HWSTAM into its own function
> > > v3: Mask off all HWSP writes on driver unload and engine cleanup.
> > > v4: And what about the physical hwsp?
> > > v5: No, engine->init_hw() is not called from driver_init_hw(), don't be
> > > daft. Really scrub HWSTAM as early as we can in driver_init_mmio()
> > > v6: Rename set_hwsp as it was setting the mask not the hwsp register.
> > >
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=108735
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 9 --
> > > drivers/gpu/drm/i915/intel_engine_cs.c | 23 +++++
> > > drivers/gpu/drm/i915/intel_ringbuffer.c | 107 +++++++++++++++---------
> > > 3 files changed, 91 insertions(+), 48 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > > index e2dac9b5f4ce..0c7fc9890891 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -3586,9 +3586,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(dev);
> > >
> > > - if (IS_GEN(dev_priv, 5))
> > > - I915_WRITE(HWSTAM, 0xffffffff);
> > > -
> > > GEN3_IRQ_RESET(DE);
> > > if (IS_GEN(dev_priv, 7))
> > > I915_WRITE(GEN7_ERR_INT, 0xffffffff);
> > > @@ -4368,8 +4365,6 @@ static void i8xx_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE16(HWSTAM, 0xffff);
> > > -
> > > GEN2_IRQ_RESET();
> > > }
> > >
> > > @@ -4537,8 +4532,6 @@ static void i915_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE(HWSTAM, 0xffffffff);
> > > -
> > > GEN3_IRQ_RESET();
> > > }
> > >
> > > @@ -4648,8 +4641,6 @@ static void i965_irq_reset(struct drm_device *dev)
> > >
> > > i9xx_pipestat_irq_reset(dev_priv);
> > >
> > > - I915_WRITE(HWSTAM, 0xffffffff);
> > > -
> > > GEN3_IRQ_RESET();
> > > }
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > index 6f165f9ad2bf..f1a2aeb34e5e 100644
> > > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > > @@ -261,6 +261,23 @@ static void __sprint_engine_name(char *name, const struct engine_info *info)
> > > info->instance) >= INTEL_ENGINE_CS_MAX_NAME);
> > > }
> > >
> > > +static void set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask)
> > > +{
> > > + struct drm_i915_private *dev_priv = engine->i915;
> > > + i915_reg_t hwstam = RING_HWSTAM(engine->mmio_base);
> >
> > g4x/ilk don't have HWSTAM for the bsd. A quick test on my ilk shows that
> > the register at that offset stays at 0x0 even if written, so it might
> > even be safe. But maybe we shouldn't poke at things that aren't there?
>
> Swines. Did they forget where the copy function was? Or did they use the
> one mask for both status pages? Probably just don't maintain a copy of
> the iir in hwsp/bsd.
Not sure. Morbid curiosity might force me to find out one day.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-12-17 18:13 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 8:53 [PATCH] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen Chris Wilson
2018-12-13 9:26 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-12-13 9:27 ` [PATCH] " Tvrtko Ursulin
2018-12-13 11:01 ` [PATCH v2] " Chris Wilson
2018-12-13 11:59 ` Ville Syrjälä
2018-12-13 12:07 ` Chris Wilson
2018-12-13 12:17 ` Chris Wilson
2018-12-13 12:29 ` Ville Syrjälä
2018-12-13 12:34 ` Chris Wilson
2018-12-13 12:45 ` Ville Syrjälä
2018-12-13 15:06 ` Chris Wilson
2018-12-13 11:17 ` ✓ Fi.CI.IGT: success for " Patchwork
2018-12-13 11:43 ` ✗ Fi.CI.BAT: failure for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev2) Patchwork
2018-12-13 12:20 ` [PATCH v3] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen Chris Wilson
2018-12-13 12:39 ` [PATCH v4] " Chris Wilson
2018-12-13 13:05 ` [PATCH v5] " Chris Wilson
2018-12-13 13:26 ` ✓ Fi.CI.BAT: success for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev5) Patchwork
2018-12-13 14:21 ` ✓ Fi.CI.BAT: success for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev6) Patchwork
2018-12-13 18:24 ` ✓ Fi.CI.IGT: " Patchwork
2018-12-17 15:20 ` [PATCH v6] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen Chris Wilson
2018-12-17 18:02 ` Ville Syrjälä
2018-12-17 18:07 ` Chris Wilson
2018-12-17 18:13 ` Ville Syrjälä [this message]
2018-12-17 15:43 ` ✓ Fi.CI.BAT: success for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev7) Patchwork
2018-12-17 18:31 ` ✓ Fi.CI.IGT: " Patchwork
2018-12-18 10:27 ` [PATCH v7] drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen Chris Wilson
2018-12-18 14:15 ` Ville Syrjälä
2018-12-18 14:24 ` Chris Wilson
2018-12-18 10:54 ` ✓ Fi.CI.BAT: success for drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen (rev8) Patchwork
2018-12-18 12:40 ` ✓ Fi.CI.IGT: " Patchwork
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=20181217181346.GR9144@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox