Re: [PATCH 2/2] drm/i915: shut up gen8+ SDE irq dmesg noise

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH 2/2] drm/i915: shut up gen8+ SDE irq dmesg noise
Date: Fri, 23 Oct 2015 16:47:52 +0300	[thread overview]
Message-ID: <20151023134752.GX26517@intel.com> (raw)
In-Reply-To: <20151023134031.GL2551@nuc-i3427.alporthouse.com>

On Fri, Oct 23, 2015 at 02:40:31PM +0100, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 04:33:52PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 23, 2015 at 11:23:12AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 23, 2015 at 12:21:37PM +0300, Jani Nikula wrote:
> > > > On Fri, 23 Oct 2015, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > > > On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
> > > > >> We get tons of cases where the master interrupt handler apparently set
> > > > >> a bit, with the SDEIIR agreeing. No idea what's going on there, but
> > > > >> it's consistent on gen8+, no one seems to care about it and it's
> > > > >> making CI results flaky.
> > > > >
> > > > > Just delete the message and delete them all. There isn't anything we can
> > > > > do and if anybody actually cared (which apparently they didn't in the
> > > > > first place), they could just trace the mmio.
> > > > 
> > > > Except this one is a regression, introduced by a bisected commit, and
> > > > suspiciously the errors pop up during aux transfers.
> > > 
> > > dp aux is a red herring very likely, since it's just the source of a _lot_
> > > of sde interrupts.
> > > 
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=92084
> > > 
> > > No one demonstrated any bad side-effects of this, let's shut it up (but
> > > keep the breadcrumb in debug logs in case) and move on to other bugs. We
> > > have enough.
> > 
> > I was still waiting for an answer to my latest idea how to avoid the
> > error. Would have been a very simple thing to test for anyone with the
> > hardware.
> 
> Presumably,
> 
>  --- a/drivers/gpu/drm/i915/i915_irq.c
>  +++ b/drivers/gpu/drm/i915/i915_irq.c
>  @@ -2345,6 +2345,7 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
>                  u32 pch_iir = I915_READ(SDEIIR);
>                  if (pch_iir) {
>                          I915_WRITE(SDEIIR, pch_iir);
>  +                       POSTING_READ(SDEIIR);
>                          ret = IRQ_HANDLED;
> 
> ?

No, we already tried that and it didn't help.

What I was thinking is we'd just do a nop write to the
PCH_PORT_HOTPLUG register like so:

dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
if (!hotplug_trigger)
	dig_hotplug_reg &= ~(*_HOTPLUG_STATUS_MASK);
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg
if (!hotplug_trigger)
	return;

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx