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@xxxxxxxxxxxxxxx wrote: > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > 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@xxxxxxxxxxxxxxx > > Cc: Diego Viola <diego.viola@xxxxxxxxx> > > Tested-by: Diego Viola <diego.viola@xxxxxxxxx> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > 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@xxxxxxxxxx> > Date: Tue Jul 29 12:10:39 2008 -0700 > > i915: Add support for MSI and interrupt mitigation. > > Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> 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@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
