From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 3/3] drm/i915: Update primary planes after a GPU reset Date: Mon, 18 Feb 2013 13:50:26 +0200 Message-ID: <20130218115026.GL9135@intel.com> References: <1360940866-22435-1-git-send-email-ville.syrjala@linux.intel.com> <1360940866-22435-4-git-send-email-ville.syrjala@linux.intel.com> <20130215152833.GB4208@cantiga.alporthouse.com> <20130215165603.GE9135@intel.com> <20130215234752.GA18708@cantiga.alporthouse.com> <20130218101533.GH9135@intel.com> <20130218104737.GE16131@cantiga.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id BD210E6096 for ; Mon, 18 Feb 2013 03:50:29 -0800 (PST) Content-Disposition: inline In-Reply-To: <20130218104737.GE16131@cantiga.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Mon, Feb 18, 2013 at 10:47:37AM +0000, Chris Wilson wrote: > On Mon, Feb 18, 2013 at 12:15:34PM +0200, Ville Syrj=E4l=E4 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=E4l=E4 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.int= el.com wrote: > > > > > > From: Ville Syrj=E4l=E4 > > > > > > = > > > > > > GPU reset will drop all flips that are still in the ring. So af= ter the > > > > > > reset, call update_plane() for all CRTCs to make sure the prima= ry > > > > > > planes are scanning out from the correct buffer. > > > > > > = > > > > > > The base address update will also generate a FLIP_DONE interrup= t, 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 pendi= ng > > > flip status from 1 -> 0. That transition of course doesn't generate an > > > interrupt (rather it stops generating one), so the nearest I could co= me > > > 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. Continually? Oh that's nasty, but makes sense if it's just a level interrupt. > 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. Ok. I see we never actually enable the pending flip interrupt on gen2/3 due to this. The same race exists there as well then. I can try to make a patch for that too. And we turn off the bit in ECOSKPD on gen3 to make sure we always behave the same way. Makes sense. > Can you send that as a patch for gen4? As I have a few people hitting > pageflip system hangs, but only on gen4 afaict. I must admit that I'm confused now. Which model does Gen4 actually follow, pending flip or flip done? -- = Ville Syrj=E4l=E4 Intel OTC