From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Do not trigger the pageflip stall check too early
Date: Wed, 17 Dec 2014 23:19:03 +0200 [thread overview]
Message-ID: <20141217211903.GN10649@intel.com> (raw)
In-Reply-To: <20141217205909.GJ2711@phenom.ffwll.local>
On Wed, Dec 17, 2014 at 09:59:09PM +0100, Daniel Vetter wrote:
> On Wed, Dec 17, 2014 at 06:35:04PM +0000, Chris Wilson wrote:
> > On Wed, Dec 17, 2014 at 08:19:00PM +0200, Ville Syrjälä wrote:
> > > On Wed, Dec 17, 2014 at 04:48:19PM +0000, Chris Wilson wrote:
> > > > On Wed, Dec 17, 2014 at 04:41:42PM +0000, Chris Wilson wrote:
> > > > > On gen2-4, we have a separate pageflip prepare/finish phase. The intent
> > > > > of the stall check is to detect when we have incurred a delay,
> > > > > potentially indefinite, after the pageflip is submitted and before the
> > > > > flip is processed by the hardware. However, our notion of
> > > > > INTEL_FLIP_PENDING/INTEL_FLIP_COMPLETE do not tally with how we set the
> > > > > values during prepare/finish and the current stall check erroneously
> > > > > assumes that when the pending value >= COMPLETE, the driver has seen the
> > > > > hardware completion flag. But what the driver actually means, is that it
> > > > > has seen the acknowlegement that the flip is queued and is now pending
> > > > > the completion event.
> > > >
> > > > Bah, otoh, as we don't mark the flip as pending before completion on
> > > > gen5+, we know don't detect when the flip is wedged there after applying
> > > > this patch.
> > > >
> > > > It is quite possible that the work->pending check is entirely bogus.
> > > > Back to the drawing board.
> > >
> > > We just apply my fix. And then we can even get rid of the whole
> > > prepare/finish mess.
> >
> > I concur. I was trying to see if there was any value in trusting IIR but
> > not ISR for gen2/3, but that's silly. So with the current flip interrupt
> > handling we really do not have the two phases anymore.
> >
> > https://bugs.freedesktop.org/attachment.cgi?id=110912
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> Jani can you please pick this on up directly? It doesn't seem to have ever
> reached intel-gfx unfortunately, at least google doesn't find it.
It was waiting for test results. Posted now:
http://lists.freedesktop.org/archives/intel-gfx/2014-December/057746.html
--
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-12-17 21:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 16:41 [PATCH] drm/i915: Do not trigger the pageflip stall check too early Chris Wilson
2014-12-17 16:48 ` Chris Wilson
2014-12-17 18:19 ` Ville Syrjälä
2014-12-17 18:35 ` Chris Wilson
2014-12-17 20:59 ` Daniel Vetter
2014-12-17 21:19 ` Ville Syrjälä [this message]
2014-12-18 5:30 ` shuang.he
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=20141217211903.GN10649@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.