On Mon, Feb 18, 2013 at 12:15:34PM +0200, Ville Syrj?l? wrote: > 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 at linux.intel.com wrote: > > > > > From: Ville Syrj?l? <ville.syrjala at 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 Ah, no. The IIR mirrors the ISR and it really does continually generate the PendingFlip interrupt on gen2/3. It wasn't until midway through the gen3 cycle, that they introduced the behaviour you describe (which is what the "pending flip is actually flip done" bit in ECOSKPD is about). But since we already have to try and handle gen2/3, I didn't think it was worth a second gen3 code path with the revised behaviour. Can you send that as a patch for gen4? As I have a few people hitting pageflip system hangs, but only on gen4 afaict. -Chris -- Chris Wilson, Intel Open Source Technology Centre
