All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 6/6] drm/i915: Really wait for pending flips in intel_pipe_set_base()
Date: Wed, 13 Feb 2013 19:06:23 +0200	[thread overview]
Message-ID: <20130213170623.GQ9135@intel.com> (raw)
In-Reply-To: <20130213154935.GL5813@phenom.ffwll.local>

On Wed, Feb 13, 2013 at 04:49:35PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2013 at 06:13:38PM +0200, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Since obj->pending_flips was never set, intel_pipe_set_base() never
> > actually waited for pending page flips to complete.
> > 
> > We really do want to wait for the pending flips, because otherwise the
> > mmio surface base address update could overtake the flip, and you
> > could end up with an old frame on the screen once the flip really
> > completes.
> > 
> > Just call intel_crtc_wait_pending_flips_locked() instead of
> > intel_finish_fb() from intel_pipe_set_base() to achieve the
> > desired result.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index a2e04f7..7e047c1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2330,8 +2330,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> >  		return ret;
> >  	}
> >  
> > -	if (crtc->fb)
> > -		intel_finish_fb(crtc->fb);
> > +	intel_crtc_wait_for_pending_flips_locked(crtc);
> 
> Ah, I see now why you grab dev->struct_mutex and need to kick waiters from
> the pending flip queue. I think grabbing the mutex twice isn't a major
> offense, since both the crtc disable code and set_base are slowpaths used
> rarely. So what about simply calling wait_for_pending_flips before
> grabbing the mutex in intel_pipe_set_base? We could then also inline
> finish_fb into it's only callsite ...

I didn't want to slow down intel_pipe_set_base() too much. If we wait
for pending flips before pinning the new fb, we can never achieve any
parallelism there. But if no-one cares about that, we can reorder.

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2013-02-13 17:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-29 16:13 [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset ville.syrjala
2013-01-29 16:13 ` [PATCH 1/6] drm/i915: Kill obj->pending_flip ville.syrjala
2013-02-13 10:16   ` Damien Lespiau
2013-02-13 16:13     ` Daniel Vetter
2013-01-29 16:13 ` [PATCH 2/6] drm/i915: Don't wait for page flips if there was GPU reset ville.syrjala
2013-02-13 10:23   ` Damien Lespiau
2013-02-13 10:51     ` Ville Syrjälä
2013-02-13 11:49       ` Daniel Vetter
2013-02-13 15:23   ` Daniel Vetter
2013-02-13 16:52     ` Ville Syrjälä
2013-02-13 17:09       ` Daniel Vetter
2013-01-29 16:13 ` [PATCH 3/6] drm/i915: Wake up pending_flip_queue as part of reset handling ville.syrjala
2013-02-13 10:24   ` Damien Lespiau
2013-02-13 15:31   ` Daniel Vetter
2013-01-29 16:13 ` [PATCH 4/6] drm/i915: Move intel_crtc_has_pending_flip() earlier ville.syrjala
2013-02-13 10:27   ` Damien Lespiau
2013-01-29 16:13 ` [PATCH 5/6] drm/i915: Add intel_crtc_wait_for_pending_flips_locked() ville.syrjala
2013-02-13 10:37   ` Damien Lespiau
2013-01-29 16:13 ` [PATCH 6/6] drm/i915: Really wait for pending flips in intel_pipe_set_base() ville.syrjala
2013-02-13 10:40   ` Damien Lespiau
2013-02-13 15:49   ` Daniel Vetter
2013-02-13 17:06     ` Ville Syrjälä [this message]
2013-02-13 17:11       ` Daniel Vetter
2013-02-13 17:26         ` Ville Syrjälä
2013-02-13 17:31           ` Daniel Vetter
2013-02-13 17:39         ` Chris Wilson
2013-01-29 16:39 ` [PATCH 0/6] drm/i915: Avoid stuck page flip waiters on GPU reset Daniel Vetter
2013-01-29 16:40   ` Daniel Vetter

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=20130213170623.GQ9135@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.