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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Thu, Jun 22, 2017 at 02:00:49PM +0100, Chris Wilson wrote:
> Quoting ville.syrjala@linux.intel.com (2017-06-22 12:55:55)
> > From: Ville Syrjälä <ville.syrjala@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@linux.intel.com>
> 
> Having a common approach that just works is definitely worth it.
> Reviewed-by: Chris Wilson <chris@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx