All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 1/3] drm/i915: Wake up pending_flip_queue as part of reset handling
Date: Mon, 18 Feb 2013 17:31:14 +0200	[thread overview]
Message-ID: <20130218153114.GP9135@intel.com> (raw)
In-Reply-To: <20130218124100.GO9135@intel.com>

On Mon, Feb 18, 2013 at 02:41:00PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 18, 2013 at 11:58:23AM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 15, 2013 at 11:53:14PM +0000, Chris Wilson wrote:
> > > On Fri, Feb 15, 2013 at 05:07:44PM +0200, ville.syrjala@linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Someone may be waiting for a flip that will never complete due to a GPU
> > > > reset. Wake up all such waiters after the GPU reset processing has
> > > > finished.
> > > > 
> > > > v2: Dropped the wake_up_all() from i915_handle_error() since
> > > >     we no longer wait for pending flips with struct_mutex held.
> > > 
> > > Isn't the wake_up(pending_flip_queue) superseded by performing the
> > > explicit do_intel_finish_page_flip() in patch 3?
> > 
> > Yes that's correct. But I actually forgot to remove the wake_up patch
> > from my tree when I tested this. I'll run a few more tests just to make
> > sure it still works.
> 
> I just tried it w/o the wake_up_all() and unfortunately it hung :(
> 
> Need to think about it a bit more I suppose.

Well after a bit more though I think I know what happened:

1. page flip submitted on crtc which is not the first crtc in the list
2. mode set operation on any crtc (will grab all crtc locks)
3. reset handling loops over crtcs
 3.1 first crtc doesn't have a pending flip, so pending_flip_queue is not woken up
 3.2 code tries to grab first crtc mutex to update the base address
  -> deadlock

So either I need to keep the wake_up_all() call in the reset handling,
or I need to do two loops over the crtcs, first loop would complete all
page flips, and second loop would update the base address registers.
I don't really care which way we go. Anyone else have a preference?

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2013-02-18 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 15:07 [PATCH 0/3] drm/i915: More page flip vs. reset improvements ville.syrjala
2013-02-15 15:07 ` [PATCH v2 1/3] drm/i915: Wake up pending_flip_queue as part of reset handling ville.syrjala
2013-02-15 23:53   ` Chris Wilson
2013-02-18  9:58     ` Ville Syrjälä
2013-02-18 12:41       ` Ville Syrjälä
2013-02-18 15:31         ` Ville Syrjälä [this message]
2013-02-18 16:39           ` Daniel Vetter
2013-02-15 15:07 ` [PATCH v2 2/3] drm/i915: Really wait for pending flips when panning ville.syrjala
2013-02-15 15:07 ` [PATCH 3/3] drm/i915: Update primary planes after a GPU reset ville.syrjala
2013-02-15 15:28   ` Chris Wilson
2013-02-15 16:56     ` Ville Syrjälä
2013-02-15 23:47       ` Chris Wilson
2013-02-18 10:15         ` Ville Syrjälä
2013-02-18 10:47           ` Chris Wilson
2013-02-18 11:50             ` Ville Syrjälä
2013-02-18 12:08               ` Chris Wilson

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=20130218153114.GP9135@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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.