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 3/4] drm/i915: Drop the excessive vblank waits from modeset codepaths
Date: Wed, 16 Apr 2014 16:27:12 +0300	[thread overview]
Message-ID: <20140416132712.GI18465@intel.com> (raw)
In-Reply-To: <20140312092542.GI23307@nuc-i3427.alporthouse.com>

On Wed, Mar 12, 2014 at 09:25:42AM +0000, Chris Wilson wrote:
> On Wed, Mar 12, 2014 at 11:16:59AM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 12, 2014 at 08:35:39AM +0000, Chris Wilson wrote:
> > > On Tue, Mar 11, 2014 at 07:37:35PM +0200, ville.syrjala@linux.intel.com wrote:
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > Now that we've plugged the mmio vs. ring flip race, we shouldn't need
> > > > these vblank waits in the modeset codepaths anymore. So get rid of
> > > > them.
> > > 
> > > Hmm, could we not add an assert(DSPSURFLIVE ==
> > > intel_crtc->dspsurf)?
> > 
> > Where would you want the assert?
> 
> assert_plane_is_bound(new_fb) in crtc_enable() and
> assert_plane_is_bound(old_fb) in crt_disable(). i.e. add them to our set
> of plane/pipe checks through modeset.

We can't really add live base address checks to such places w/o adding
extra vblank waits. For example if we first do a set_base w/o waiting for
vblank and then disable the crtc. By the time we get to crtc_disable()
there's no guarantee that the mmio flip from set_base has completed, and
hence the live surface address may still have the old value.

For the atomic page flip stuff the live address can serve as a decent
debug tool to make sure the flip has really completed or not completed
when we expect. IIRC I had such a debug patch in my atomic branch.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-04-16 13:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11 17:37 [PATCH 0/4] drm/i915: mmio vs. CS flip race fix ville.syrjala
2014-03-11 17:37 ` [PATCH 1/4] drm/i915: Reduce the time we hold struct mutex in intel_pipe_set_base() ville.syrjala
2014-03-12  8:32   ` Chris Wilson
2014-03-12 15:16     ` Daniel Vetter
2014-03-11 17:37 ` [PATCH 2/4] drm/i915: Fix mmio vs. CS flip race on ILK+ ville.syrjala
2014-03-12  8:30   ` Chris Wilson
2014-03-12  9:11     ` Ville Syrjälä
2014-03-11 17:37 ` [PATCH 3/4] drm/i915: Drop the excessive vblank waits from modeset codepaths ville.syrjala
2014-03-12  8:35   ` Chris Wilson
2014-03-12  9:16     ` Ville Syrjälä
2014-03-12  9:25       ` Chris Wilson
2014-04-16 13:27         ` Ville Syrjälä [this message]
2014-03-11 17:37 ` [PATCH 4/4] drm/i915: Wait for vblank in hsw_enable_ips() ville.syrjala
2014-03-12  8:36   ` Chris Wilson
2014-03-12  9:14     ` Ville Syrjälä

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=20140416132712.GI18465@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.