On Thu, Jun 22, 2017 at 02:02:39PM +0100, Chris Wilson wrote: > Quoting ville.syrjala@xxxxxxxxxxxxxxx (2017-06-22 12:55:38) > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
