Re: [PATCH 1/2] drm/i915: fix race when clearing RPS IIR bits

From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Imre Deak <imre.deak@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/i915: fix race when clearing RPS IIR bits
Date: Tue, 24 Mar 2015 10:14:03 +0100	[thread overview]
Message-ID: <20150324091403.GC1349@phenom.ffwll.local> (raw)
In-Reply-To: <20150323211015.GA4586@nuc-i3427.alporthouse.com>

On Mon, Mar 23, 2015 at 09:10:15PM +0000, Chris Wilson wrote:
> On Mon, Mar 23, 2015 at 07:11:34PM +0200, Imre Deak wrote:
> > When disabling RPS interrupts there is a race where we disable RPS
> > inerrupts while the interrupt handler is running and the handler has
> > already latched the pending RPS interrupt from the master IIR register.
> > Afterwards the disabling path clears the PM IIR bits, making the state
> > of pending interrupts inconsistent from the interrupt handler's point of
> > view. This triggers the following warning: "The master control interrupt
> > lied (PM)!".
> > 
> > To fix this make sure that any running interrupt handler (which may
> > have already latched the master IIR) finishes before clearing the IIR
> > bits.
> > 
> 
> Isn't this overkill for what is just a bogus WARN? If the WARN is a
> logical consequence of the code, let's just remove the WARN.
> 
> Or iow can you not find a cheaper way to fix this?

We only run this on suspend/resume afaik, overhead should be acceptable.
And we've had that much overhead before we've done all the runtime pm
unification, it's still less synchronization than disabling interrupts
completely.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx