Re: [PATCH 3/3] drm/i915: Update primary planes after a GPU reset

[Chris Wilson <chris@chris-wilson.co.uk>]

On Fri, Feb 15, 2013 at 06:56:03PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 15, 2013 at 03:28:33PM +0000, Chris Wilson wrote:
> > On Fri, Feb 15, 2013 at 05:07:46PM +0200, ville.syrjala@linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > GPU reset will drop all flips that are still in the ring. So after the
> > > reset, call update_plane() for all CRTCs to make sure the primary
> > > planes are scanning out from the correct buffer.
> > > 
> > > The base address update will also generate a FLIP_DONE interrupt, which
> > > will complete any pending flips. That means user space will get its
> > > page flip events and won't get stuck waiting for them.
> > 
> > Not for all generations.
> 
> Hmm OK those seem to be the ones with the pending flip status bit
> (Gen4 and older?).

Yes. Also notably the ones unlikely to survive the GPU reset :)

> But can someone explain why on those platforms we also check the
> vblank interrupt status bit before handling the page flip interrupt?

For those generations, we are meant to detect the transition of pending
flip status from 1 -> 0. That transition of course doesn't generate an
interrupt (rather it stops generating one), so the nearest I could come
up with was in anticipating the vblank after we saw the pending flip
status was close enough. In the case of a pending vblank raising an
interrupt just as the pending flip status is asserted, shouldn't MSI
prevent the pending flip from being asserted as we process the IIR for
the vblank. Of course not all of those chipsets even have MSI. I'm not
even sure if we can close that race.

> Also wtf is i965_irq_handler doing? Based on the code it seems to be
> expecting the pending flip interrupt to happen when the CS executes the
> instruction, and then it'll finish the page flip from the following
> vblank irq. BSpec doesn't agree, and still maintains that the page flip
> interrupt will be generated when the flip really completes. Even if the
> hardware would work the way the code suggests, the code is racy if the
> ISR is delayed a bit and ends up handling the previous vblank interrupt
> and the following flip pending interrupt at the same time. We'd really
> need to check the live flip pending status from the ISR to make it
> work right.

Just be sure that you are reading the bspec for the original gen4 that
has not been clobbered by later refinements. If it stands that we can
trust the flip done interrupt for gen4, then that simplifies that
routine greatly. And could even close the mystery pageflipping is broken
on gen4 bugs.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre