From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
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 15:17:09 +0200 [thread overview]
Message-ID: <20141124131709.GI10649@intel.com> (raw)
In-Reply-To: <20141124093442.GK25711@phenom.ffwll.local>
On Mon, Nov 24, 2014 at 10:34:42AM +0100, Daniel Vetter wrote:
> 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?
Nah. But I was actually wondering why the unlocked flip complete prior to
.update_plane() was supposedly necessary at all. But yeah the missing
wake_up before that commit explains it.
I'll see about respinning the patch with the flip complete moved back
after the reset. I guess I could actually move it occur even after
.update_plane() now.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-11-24 13:17 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
2014-11-24 13:17 ` Ville Syrjälä [this message]
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=20141124131709.GI10649@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.