[Intel-gfx] [PATCH] drm/i915: Disable MSI for all pre-gen5

[Ville Syrjälä]

On Tue, Jun 27, 2017 at 11:18:33AM +0200, Daniel Vetter wrote:
> On Mon, Jun 26, 2017 at 11:30:51PM +0300, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > We have pretty clear evidence that MSIs are getting lost on g4x and
> > somehow the interrupt logic doesn't seem to recover from that state
> > even if we try hard to clear the IIR.
> > 
> > Disabling IER around the normal IIR clearing in the irq handler isn't
> > sufficient to avoid this, so the problem really seems to be further
> > up the interrupt chain. This should guarantee that there's always
> > an edge if any IIR bits are set after the interrupt handler is done,
> > which should normally guarantee that the CPU interrupt is generated.
> > That approach seems to work perfectly on VLV/CHV, but apparently
> > not on g4x.
> > 
> > MSI is documented to be broken on 965gm at least. The chipset spec
> > says MSI is defeatured because interrupts can be delayed or lost,
> > which fits well with what we're seeing on g4x. Previously we've
> > already disabled GMBUS interrupts on g4x because somehow GMBUS
> > manages to raise legacy interrupts even when MSI is enabled.
> > 
> > Since there's such widespread MSI breakahge all over in the pre-gen5
> > land let's just give up on MSI on these platforms.
> > 
> > Seqno reporting might be negatively affected by this since the legcy
> > interrupts aren't guaranteed to be ordered with the seqno writes,
> > whereas MSI interrupts may be? But an occasioanlly missed seqno
> > seems like a small price to pay for generally working interrupts.
> > 
> > Cc: stable at vger.kernel.org
> > Cc: Diego Viola <diego.viola at gmail.com>
> > Tested-by: Diego Viola <diego.viola at gmail.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> One caveat was that iirc we've also seen lost irq without msi, which was
> originally the reason to enable this. But that was misremembering on my
> side, apparently msi was done purely to get our own irq and avoid cpu
> overhead with shared irq. See:
> 
> commit ed4cb4142b242d8090d3811d5eb4abf6aa985bc8
> Author: Eric Anholt <eric at anholt.net>
> Date:   Tue Jul 29 12:10:39 2008 -0700
> 
>     i915: Add support for MSI and interrupt mitigation.
> 
> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

Thanks for double checking the old lore.

Pushed to dinq.

> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 8 +++++---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index e9d8e9ee51b2..9167a73f3c69 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1141,10 +1141,12 @@ static int i915_driver_init_hw(struct drm_i915_private *dev_priv)
> >  	 * and the registers being closely associated.
> >  	 *
> >  	 * According to chipset errata, on the 965GM, MSI interrupts may
> > -	 * be lost or delayed, but we use them anyways to avoid
> > -	 * stuck interrupts on some machines.
> > +	 * be lost or delayed, and was defeatured. MSI interrupts seem to
> > +	 * get lost on g4x as well, and interrupt delivery seems to stay
> > +	 * properly dead afterwards. So we'll just disable them for all
> > +	 * pre-gen5 chipsets.
> >  	 */
> > -	if (!IS_I945G(dev_priv) && !IS_I945GM(dev_priv)) {
> > +	if (INTEL_GEN(dev_priv) >= 5) {
> >  		if (pci_enable_msi(pdev) < 0)
> >  			DRM_DEBUG_DRIVER("can't enable MSI");
> >  	}
> > -- 
> > 2.13.0
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx at 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