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 12:15:34 +0200 Message-ID: <20130218101533.GH9135@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> 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 95E0EE5D4D for ; Mon, 18 Feb 2013 02:15:37 -0800 (PST) Content-Disposition: inline In-Reply-To: <20130215234752.GA18708@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 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.intel.c= om wrote: > > > > From: Ville Syrj=E4l=E4 > > > > = > > > > 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, w= hich > > > > 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) =3D=3D = 0) intel_finish_page_flip(); ... } -- = Ville Syrj=E4l=E4 Intel OTC