From patchwork Tue Jul 19 16:30:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: cpaul@redhat.com X-Patchwork-Id: 9237823 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6065B602F0 for ; Tue, 19 Jul 2016 16:31:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 50ED626B4A for ; Tue, 19 Jul 2016 16:31:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4403D26E81; Tue, 19 Jul 2016 16:31:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F071826B4A for ; Tue, 19 Jul 2016 16:31:22 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 51D1F6E6C3; Tue, 19 Jul 2016 16:31:17 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id 50AB86E6C3; Tue, 19 Jul 2016 16:31:14 +0000 (UTC) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA64B883AB; Tue, 19 Jul 2016 16:31:13 +0000 (UTC) Received: from ecstaticemu.bos.redhat.com (dhcp-25-142.bos.redhat.com [10.18.25.142]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6JGV806013249; Tue, 19 Jul 2016 12:31:12 -0400 From: Lyude To: intel-gfx@lists.freedesktop.org Date: Tue, 19 Jul 2016 12:30:56 -0400 Message-Id: <1468945856-23126-3-git-send-email-cpaul@redhat.com> In-Reply-To: <1468945856-23126-1-git-send-email-cpaul@redhat.com> References: <1468945856-23126-1-git-send-email-cpaul@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 19 Jul 2016 16:31:14 +0000 (UTC) Cc: David Airlie , "open list:INTEL DRM DRIVERS excluding Poulsbo, Moorestow..., linux-kernel@vger.kernel.org open list" , stable@vger.kernel.org, Hans de Goede , Daniel Vetter Subject: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP Now that we update the watermark values atomically, we still need to fix the case of how we update watermarks when we haven't added or removed pipes. When we haven't added or removed any pipes, we don't need to worry about the ddb allocation changing. As such there's no order of flushing pipes we have to guarantee; e.g. each pipe can be flushed at the earliest given oppurtunity. This means all we have to do is: - Calculate the new wm values - Update each plane's settings and wm values - Arm the plane's registers to update at the next vblank Right now the watermark code takes an additional few steps: - Rewrite the ddb allocations - Arm all of the planes for another update at the start of the next vblank - *Potentially underrun later if we update the wm registers before the start of the next vblank* This patch prevents us from marking pipes as dirty unless the number of pipes, and with that the ddb allocation, has actually changed. This results in us skipping the additional steps, preventing the hardware from using any intermediate values during each wm update. This also fixes cursors causing monitors to flicker on Skylake. Finally. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Radhakrishna Sripada Cc: Hans de Goede Cc: Matt Roper --- drivers/gpu/drm/i915/intel_pm.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 3a7709c..92158e3 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4086,12 +4086,18 @@ skl_compute_wm(struct drm_atomic_state *state) if (ret) return ret; - if (changed) - results->dirty_pipes |= drm_crtc_mask(crtc); + /* + * We don't need to do any additional setup for the pipes if we + * haven't changed the number of active crtcs + */ + if (intel_state->active_pipe_changes) { + if (changed) + results->dirty_pipes |= drm_crtc_mask(crtc); - if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0) - /* This pipe's WM's did not change */ - continue; + if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0) + /* This pipe's WM's did not change */ + continue; + } intel_cstate->update_wm_pre = true; skl_compute_wm_results(crtc->dev, pipe_wm, results, intel_crtc);