From: Lyude <cpaul@redhat.com>
To: intel-gfx@lists.freedesktop.org
Cc: Lyude <cpaul@redhat.com>,
stable@vger.kernel.org,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Daniel Vetter" <daniel.vetter@intel.com>,
"Radhakrishna Sripada" <radhakrishna.sripada@intel.com>,
"Matt Roper" <matthew.d.roper@intel.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"David Airlie" <airlied@linux.ie>,
dri-devel@lists.freedesktop.org (open list:INTEL DRM DRIVERS
(excluding Poulsbo, Moorestow...),
linux-kernel@vger.kernel.org (open list))
Subject: [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush
Date: Wed, 20 Jul 2016 17:00:00 -0400 [thread overview]
Message-ID: <1469048403-32016-5-git-send-email-cpaul@redhat.com> (raw)
In-Reply-To: <1469048403-32016-1-git-send-email-cpaul@redhat.com>
As we've learned, all watermark updates on Skylake have to be strictly
atomic or things fail. While the bspec doesn't mandate that we need to
wait for pipes to finish after the third iteration of flushes, not doing
so gives us the opportunity to break this atomicity later. This example
assumes that we're lucky enough not to be interrupted by the scheduler
at any point during this:
- Start with pipe A and pipe B enabled
- Enable pipe C
- Flush pipe A in pass 1, wait until update finishes
- Flush pipe B in pass 3, continue without waiting for next vblank
- Start another wm update
- We enter the next vblank for pipe B before we finish writing all the
vm values
- *Underrun*
As such, we always need to wait for each pipe we flush to update so as
to never break this atomicity.
Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com> <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
---
drivers/gpu/drm/i915/intel_pm.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 788db86..2e31df4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3859,8 +3859,11 @@ static void skl_flush_wm_values(struct drm_i915_private *dev_priv,
/*
* Third pass: flush the pipes that got more space allocated.
*
- * We don't need to actively wait for the update here, next vblank
- * will just get more DDB space with the correct WM values.
+ * While the hardware doesn't require to wait for the next vblank here,
+ * continuing before the pipe finishes updating could result in us
+ * trying to update the wm values again before the pipe finishes
+ * updating, which results in the hardware using intermediate wm values
+ * and subsequently underrunning pipes.
*/
for_each_intel_crtc(dev, crtc) {
if (!crtc->active)
@@ -3876,6 +3879,16 @@ static void skl_flush_wm_values(struct drm_i915_private *dev_priv,
continue;
skl_wm_flush_pipe(dev_priv, pipe, 3);
+
+ /*
+ * The only time we can get away with not waiting for an update
+ * is when we just enabled the pipe, e.g. when it doesn't have
+ * vblanks enabled anyway.
+ */
+ if (drm_crtc_vblank_get(&crtc->base) == 0) {
+ intel_wait_for_vblank(dev, pipe);
+ drm_crtc_vblank_put(&crtc->base);
+ }
}
}
--
2.7.4
next prev parent reply other threads:[~2016-07-20 21:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 20:59 [PATCH 0/6] drm/i915/skl: Finally fix watermarks Lyude
2016-07-20 20:59 ` [PATCH 1/6] drm/i915/skl: Update plane watermarks atomically during plane updates Lyude
2016-07-20 23:12 ` Matt Roper
2016-07-20 20:59 ` [PATCH 3/6] drm/i915/skl: Actually reuse wm values when pipes don't change Lyude
2016-07-20 23:26 ` Matt Roper
2016-07-20 21:00 ` Lyude [this message]
2016-07-21 0:27 ` [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush Matt Roper
2016-07-21 17:01 ` Lyude Paul
2016-07-20 21:00 ` [PATCH 5/6] drm/i915/skl: Only flush pipes when we change the ddb allocation Lyude
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=1469048403-32016-5-git-send-email-cpaul@redhat.com \
--to=cpaul@redhat.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=matthew.d.roper@intel.com \
--cc=radhakrishna.sripada@intel.com \
--cc=stable@vger.kernel.org \
--cc=ville.syrjala@linux.intel.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;
as well as URLs for NNTP newsgroup(s).