From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lyude Subject: [PATCH v3 6/6] drm/i915/skl: Always wait for pipes to update after a flush Date: Tue, 26 Jul 2016 10:50:17 -0400 Message-ID: <1469544617-20003-7-git-send-email-cpaul@redhat.com> References: <1469544617-20003-1-git-send-email-cpaul@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <1469544617-20003-1-git-send-email-cpaul@redhat.com> Sender: linux-kernel-owner@vger.kernel.org To: intel-gfx@lists.freedesktop.org, Maarten Lankhorst Cc: Lyude , stable@vger.kernel.org, =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Daniel Vetter , Radhakrishna Sripada , Hans de Goede , Matt Roper , Jani Nikula , David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org Unfortunately right now we don't really update watermarks on Skylake properly, since ideally we'd be updating both the ddb allocations, plan= e properties, and watermarks all in a single go. Until this is fixed however, we can improve things somewhat by adding a vblank wait after the third iteration of pipe flushes, since this forces us to always wai= t for new ddb allocations to take affect before trying to change them again. Signed-off-by: Lyude Cc: stable@vger.kernel.org Cc: Ville Syrj=C3=A4l=C3=A4 Cc: Daniel Vetter Cc: Radhakrishna Sripada Cc: Hans de Goede Cc: Matt Roper --- 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/int= el_pm.c index 3d48a80..778f760 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3978,8 +3978,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 her= e, + * 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 valu= es + * and subsequently underrunning pipes. */ for_each_intel_crtc(dev, crtc) { if (!crtc->active) @@ -3995,6 +3998,16 @@ static void skl_flush_wm_values(struct drm_i915_= private *dev_priv, continue; =20 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) =3D=3D 0) { + intel_wait_for_vblank(dev, pipe); + drm_crtc_vblank_put(&crtc->base); + } } } =20 --=20 2.7.4