[Intel-gfx] [PATCH 17/17] drm/i915: Rewrite GMCH irq handlers to follow the VLV/CHV pattern

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


On Thu, Jun 22, 2017 at 02:00:49PM +0100, Chris Wilson wrote:
> Quoting ville.syrjala at linux.intel.com (2017-06-22 12:55:55)
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > Eliminate the loops from the gen2-3 irq handlers by following the same
> > trick used for VLV/CHV, ie. clear IER around acking the interrupts.
> > That way if some IIR bits still remain set we'll get another edge (and
> > thus another CPU interrupt) when the IER gets restored.
> > 
> > This shouldn't really be necessary when level triggered PCI interrupts
> > are used (gen2, some gen3), but let's follow the same pattern in
> > all the handlers so that we don't have to worry about MSI being enabled
> > or not. And consistency should help avoid confusing the reader as well.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> Having a common approach that just works is definitely worth it.
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> 
> Interrupts aren't so much of a concern for me for pre-snb, but every
> mmio read prior to waking up a waiter should be justified :) Before
> ilk, we have to run the entire interrupt handler before userspace can
> proceed. Just something to bear in mind, and prune as much as possible.

I guess we could nuke the IER read at least by storing the value
somewhere. I believe you actually suggested that when I redid the
VLV/CHV code. And I guess ripping out all POSTING_READs could be
a sane thing to do as well.

As for the underrun checks, I guess we could limit those to just happen
when some other pipe interrupt happens. While we're flipping or
reconfiguring planes we should have vblanks enabled anyway, so
we should still be able to catch the most glaring watermark failures
at least. But catching more subtle underruns caused by something like
memory self refresh or perhaps starvation due to heavy GPU memory
access etc. might go unnoticed then.

-- 
Ville Syrjälä
Intel OTC


More information about the Intel-gfx mailing list