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

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

On Fri, Feb 15, 2013 at 11:47:52PM +0000, Chris Wilson wrote:
> 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.

This is what I *think* gen2-gen4 Bspec are telling me:

1. CS executes MI_DISPLAY_FLIP
   -> ISR:flip bit 0 -> 1
2. Flip completes
   -> ISR:flip bit 1 -> 0
   -> IIR:flip bit 0 -> 1
   -> interrupt generated

But unfortuntely I have no hardware to test that.


But if I'm reading the BSpec incorrectly (or if it's inaccurate), then
I think we can close the race with this code:

i965_irq_handler()
{
...
	if (iir & I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT)
		intel_prepare_page_flip();

	if (iir & PIPE_START_VBLANK_INTERRUPT_STATUS &&
	    (I915_READ(ISR) & I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT) == 0)
		intel_finish_page_flip();
...
}

-- 
Ville Syrjälä
Intel OTC