public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH] drm/i915: Move vblank wait determination to 'check' phase
Date: Thu, 19 Mar 2015 21:36:28 +0200	[thread overview]
Message-ID: <20150319193628.GV17419@intel.com> (raw)
In-Reply-To: <CA+gsUGRBJD6ofh1X5w9ZCVHituX4THBZjYKLzSFKUokC2moi7A@mail.gmail.com>

On Thu, Mar 19, 2015 at 04:16:41PM -0300, Paulo Zanoni wrote:
> 2015-03-18 19:04 GMT-03:00 Matt Roper <matthew.d.roper@intel.com>:
> > Determining whether we'll need to wait for vblanks is something we
> > should determine during the atomic 'check' phase, not the 'commit'
> > phase.  Note that we only set these bits in the branch of 'check' where
> > intel_crtc->active is true so that we don't try to wait on a disabled
> > CRTC.
> >
> > The whole 'wait for vblank after update' flag should go away in the
> > future, once we start handling watermarks in a proper atomic manner.
> 
> Add this to the commit message:
> 
> Regression introduced by:
> 
> commit 2fdd7def16dd7580f297827930126c16b152ec11
> Author: Matt Roper <matthew.d.roper@intel.com>
> Date:   Wed Mar 4 10:49:04 2015 -0800
>     drm/i915: Don't clobber plane state on internal disables
> 
> (at least according to QA's bisect)
> 
> >
> > Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Root-cause-analysis-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89550
> > Testcase: igt/pm_rpm/legacy-planes
> > Testcase: igt/pm_rpm/legacy-planes-dpms
> > Testcase: igt/pm_rpm/universal-planes
> > Testcase: igt/pm_rpm/universal-planes-dpms
> > Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> > ---
> > Paulo, can you test this patch and see if it solves the problem?  The only
> > platform I have access to (IVB) doesn't have runtime power management, so I
> > can't actually run the relevant testcases myself.
> 
> Yes, this patch makes the WARN go away on my BDW machine :)
> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> One of the possible problems with this patch is that, before it, the
> wait_vblank was only set for ILK-BDW, but now we set it for all
> platforms. Do we really want this? Otherwise, it looks good, although
> I haven't been closely following the atomic rework to be able to
> assert this is really according to the grand plans. Daniel/Ville could
> comment here :)

Somethins seems a bit off to me if we end up calling .disable_plane()
with a disabled pipe. So fixing things so that won't happen
might be a better approach.

> 
> >
> >  drivers/gpu/drm/i915/intel_sprite.c | 24 ++++++++++--------------
> >  1 file changed, 10 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > index a828736..fad1d9f 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -747,13 +747,6 @@ ivb_disable_plane(struct drm_plane *plane, struct drm_crtc *crtc)
> >         I915_WRITE(SPRSURF(pipe), 0);
> >
> >         intel_flush_primary_plane(dev_priv, intel_crtc->plane);
> > -
> > -       /*
> > -        * Avoid underruns when disabling the sprite.
> > -        * FIXME remove once watermark updates are done properly.
> > -        */
> > -       intel_crtc->atomic.wait_vblank = true;
> > -       intel_crtc->atomic.update_sprite_watermarks |= (1 << drm_plane_index(plane));
> >  }
> >
> >  static int
> > @@ -937,13 +930,6 @@ ilk_disable_plane(struct drm_plane *plane, struct drm_crtc *crtc)
> >         I915_WRITE(DVSSURF(pipe), 0);
> >
> >         intel_flush_primary_plane(dev_priv, intel_crtc->plane);
> > -
> > -       /*
> > -        * Avoid underruns when disabling the sprite.
> > -        * FIXME remove once watermark updates are done properly.
> > -        */
> > -       intel_crtc->atomic.wait_vblank = true;
> > -       intel_crtc->atomic.update_sprite_watermarks |= (1 << drm_plane_index(plane));
> >  }
> >
> >  /**
> > @@ -1262,6 +1248,16 @@ finish:
> >                     plane->state->fb->modifier[0] !=
> >                     state->base.fb->modifier[0])
> >                         intel_crtc->atomic.update_wm = true;
> > +
> > +               if (!state->visible) {
> > +                       /*
> > +                        * Avoid underruns when disabling the sprite.
> > +                        * FIXME remove once watermark updates are done properly.
> > +                        */
> > +                       intel_crtc->atomic.wait_vblank = true;
> > +                       intel_crtc->atomic.update_sprite_watermarks |=
> > +                               (1 << drm_plane_index(plane));
> > +               }
> >         }
> >
> >         return 0;
> > --
> > 1.8.5.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 
> -- 
> Paulo Zanoni
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-03-19 19:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-18 19:15 [RFC] drm/i915: don't wait_for_vblank if the CRTC is disabled Paulo Zanoni
2015-03-18 22:01 ` Matt Roper
2015-03-18 22:04   ` [PATCH] drm/i915: Move vblank wait determination to 'check' phase Matt Roper
2015-03-19 11:43     ` shuang.he
2015-03-19 19:16     ` Paulo Zanoni
2015-03-19 19:36       ` Ville Syrjälä [this message]
2015-03-20 10:22         ` Daniel Vetter
2015-03-19 16:31   ` [RFC] drm/i915: don't wait_for_vblank if the CRTC is disabled 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=20150319193628.GV17419@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    --cc=przanoni@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox