[Intel-gfx] [PATCH 00/17] drm/i915: Redo old gmch irq handling

Ville Syrjälä ville.syrjala at linux.intel.com
Thu Jun 22 13:12:50 UTC 2017


On Thu, Jun 22, 2017 at 02:02:39PM +0100, Chris Wilson wrote:
> Quoting ville.syrjala at linux.intel.com (2017-06-22 12:55:38)
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > Apparently we have some issues [1] on g4x which smells like irqs not getting
> > delivered after some point in time. The gen2-4 irq code is rather crusty
> > so I thought I'd bring it up to the same quality standards as the VLV/CHV
> > irq code. And to avoid any chances of missing the edges I changed all the
> > gmch platforms to use the "disable IER -> ack IIR -> enable IER" trick
> > we use on VLV and CHV. That should be robust with both level and edge
> > triggered interrupts, and single and double buffered IIR.
> > 
> > I think the only slightly scary bits are the ones touching HWSTAM
> > programming. While that's not strictly needed for this series, I really
> > wanted to remove a bunch of duplicat irq setup code, and for that
> > I wanted to make the HWSTAM programming consistent. We don't actually
> > use any of the interrupt information written into the status page,
> > but I have slight concern that the extra status page writes may have
> > had some unintended effect on seqno coherency. Fingers crossed...
> 
> Yeah, I just want to ponder HWSTAM somewhat. One issue is that we have
> never taken advantage of it to avoid the uncached mmio read. But
> changing it may indeed uncover old coherency issues...

If I decoded the bits correctly, then I think that danger would only
apply to ilk since that's the only platform where we unmask the user
interrupt in HWSTAM (and just the render user interrupt, the bsd one
remains always masked).

-- 
Ville Syrjälä
Intel OTC


More information about the Intel-gfx mailing list