Re: [Intel-gfx] [PATCH] drm/i915: Disable MSI for all pre-gen5
Quoting ville.syrj...@linux.intel.com (2017-06-26 21:30:51) > From: Ville Syrjälä> > 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. An unmentioned sibling caught by this change is g33. It is very unlikely to have been fixed in g33 but broken in g4x, still deserves a mention as old gen3 used MSI and g33 tried to tame the beast. > 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: sta...@vger.kernel.org > Cc: Diego Viola > Tested-by: Diego Viola > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 > Signed-off-by: Ville Syrjälä Acked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable MSI for all pre-gen5
On Tue, Jun 27, 2017 at 11:18:33AM +0200, Daniel Vetter wrote: > On Mon, Jun 26, 2017 at 11:30:51PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä> > > > 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: sta...@vger.kernel.org > > Cc: Diego Viola > > Tested-by: Diego Viola > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 > > Signed-off-by: Ville Syrjälä > > 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 > Date: Tue Jul 29 12:10:39 2008 -0700 > > i915: Add support for MSI and interrupt mitigation. > > Reviewed-by: Daniel Vetter 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@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
Re: [Intel-gfx] [PATCH] drm/i915: Disable MSI for all pre-gen5
On Mon, Jun 26, 2017 at 11:30:51PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä> > 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: sta...@vger.kernel.org > Cc: Diego Viola > Tested-by: Diego Viola > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 > Signed-off-by: Ville Syrjälä 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 Date: Tue Jul 29 12:10:39 2008 -0700 i915: Add support for MSI and interrupt mitigation. Reviewed-by: Daniel Vetter > --- > 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Disable MSI for all pre-gen5
From: Ville Syrjälä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: sta...@vger.kernel.org Cc: Diego Viola Tested-by: Diego Viola Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261 Signed-off-by: Ville Syrjälä --- 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx