public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 5/6] drm/i915: Grab modeset locks for GPU rest on pre-ctg
Date: Mon, 24 Nov 2014 10:34:42 +0100	[thread overview]
Message-ID: <20141124093442.GK25711@phenom.ffwll.local> (raw)
In-Reply-To: <20141121211031.GG10649@intel.com>

On Fri, Nov 21, 2014 at 11:10:31PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 21, 2014 at 09:49:21PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 21, 2014 at 09:54:29PM +0200, ville.syrjala@linux.intel.com wrote:
> > > +
> > > +	/*
> > > +	 * Flips in the rings will be nuked by the reset,
> > > +	 * so complete all pending flips so that user space
> > > +	 * will get its events and not get stuck.
> > > +	 *
> > > +	 * Old platforms will also reset the display, so we
> > > +	 * need to grab the modeset locks around the reset.
> > > +	 * But in order to do that we must let any pending
> > > +	 * page flip wait complete since the waiters may be
> > > +	 * holding some modeset locks.
> > > +	 */
> > > +	intel_complete_page_flips(dev);
> > 
> > Is this really required? We complete them afterwards, and all the pageflip
> > waiters I've found do check for gpu hangs and abort the pageflip wait.
> > That's already required since the mmio flip might go missing, and thus far
> > we've only completed the flip _after_ having reset the gpu and gem state
> > (and grabbed dev->struct_mutex).
> 
> Hmm. Yeah, just waking them up ought to be sufficient to dislodge
> things. And we already do that before scheduling the error work, but
> after setting the reset_in_progress flag, which is very much critical
> here. So I guess I could just move the complete pending flips bit to
> intel_finish_reset().
> 
> But then I do wonder a bit why I originally needed to add the unlocked
> page flip complete before the locked .update_plane() call. Did we miss
> a wakeup somewhere or did we not abort pending flip waits on reset?

gpu hang vs. pending flip deadlocks should have been fixed with

commit 17e1df07df0fbc77696a1e1b6ccf9f2e5af70e40
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Sep 8 21:57:13 2013 +0200

    drm/i915: fix wait_for_pending_flips vs gpu hang deadlock

Maybe it's been broken meanwhile but it should have worked since quite a
while. Or are these gen3/4 reset patches really this old?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-11-24  9:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-21 19:54 [PATCH 0/6] drm/i915: Implement gen3/4 GPU reset ville.syrjala
2014-11-21 19:54 ` [PATCH 1/6] drm/i915: Fix gen4 " ville.syrjala
2014-11-22 11:05   ` Chris Wilson
2014-11-24 12:57     ` Ville Syrjälä
2014-11-21 19:54 ` [PATCH 2/6] drm/i915: Restore the display config after a GPU reset on gen4 ville.syrjala
2014-11-21 19:54 ` [PATCH 3/6] drm/i915: Implement GPU reset for 915/945 ville.syrjala
2014-11-25 12:54   ` Daniel Vetter
2014-11-21 19:54 ` [PATCH 4/6] drm/i915: Implement GPU reset for g33 ville.syrjala
2014-11-21 19:54 ` [PATCH 5/6] drm/i915: Grab modeset locks for GPU rest on pre-ctg ville.syrjala
2014-11-21 20:49   ` Daniel Vetter
2014-11-21 21:10     ` Ville Syrjälä
2014-11-24  9:34       ` Daniel Vetter [this message]
2014-11-24 13:17         ` Ville Syrjälä
2014-11-24 16:28   ` [PATCH v2 " ville.syrjala
2014-11-21 19:54 ` [PATCH 6/6] drm/i915: Disable crtcs gracefully before GPU reset on gen3/4 ville.syrjala
2014-11-24 10:02   ` [PATCH 6/6] drm/i915: Disable crtcs gracefully before shuang.he
2014-11-24 16:28 ` [PATCH 7/6] drm/i915: Deal with video overlay on GPU reset ville.syrjala
2014-11-25 12:35   ` Daniel Vetter
2014-11-26 15:07   ` [PATCH v2 " ville.syrjala
2014-11-26 18:10     ` Daniel Vetter
2014-11-27 12:04       ` Dave Gordon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141124093442.GK25711@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox