From patchwork Thu Apr 26 02:10:09 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tarun Vyas X-Patchwork-Id: 10364579 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 F061D602DC for ; Thu, 26 Apr 2018 02:10:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E1D8C290EC for ; Thu, 26 Apr 2018 02:10:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D6D1C290F3; Thu, 26 Apr 2018 02:10:17 +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=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 53940290F7 for ; Thu, 26 Apr 2018 02:10:17 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6BE506E28F; Thu, 26 Apr 2018 02:10:15 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 60A476E08F for ; Thu, 26 Apr 2018 02:10:14 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2018 19:10:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,328,1520924400"; d="scan'208";a="223417180" Received: from otc-chromeosbuild-5.jf.intel.com ([10.54.30.37]) by fmsmga005.fm.intel.com with ESMTP; 25 Apr 2018 19:10:11 -0700 From: tarun.vyas@intel.com To: tarun.vyas@intel.com, intel-gfx@lists.freedesktop.org Date: Wed, 25 Apr 2018 19:10:09 -0700 Message-Id: <20180426021009.178880-1-tarun.vyas@intel.com> X-Mailer: git-send-email 2.13.5 Subject: [Intel-gfx] [RFC] drm/i915: Rework "Potential atomic update error" to handle PSR exit X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP From: Tarun The Display scanline counter freezes on PSR entry. Inside intel_pipe_update_start, once Vblank interrupts are enabled, we start exiting PSR, but by the time the scanline counter is read, we may not have completely exited PSR which leads us to schedule out and check back later. On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but lags w.r.t core kernel code, hot plugging an external display triggers tons of "potential atomic update errors" in the dmesg, on *pipe A*. A closer analysis reveals that we try to read the scanline 3 times and eventually timeout, b/c PSR hasn't exited fully leading to a PIPEDSL stuck @ 1599. This issue is not seen on upstream kernels, b/c for *some* reason we loop inside intel_pipe_update start for ~2+ msec which in this case is more than enough to exit PSR fully, hence an *unstuck* PIPEDSL counter, hence no error. On the other hand, the ChromeOS kernel spends ~1.1 msec looping inside intel_pipe_update_start and hence errors out b/c the source is still in PSR. If PSR is enabled, then we should *wait* for the PSR state to move to IDLE before re-reading the PIPEDSL so as to avoid bogus and annoying "potential atomic update error" messages. P.S: This scenario applies to a configuration with an additional pipe, as of now. Signed-off-by: Tarun --- drivers/gpu/drm/i915/intel_sprite.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index aa1dfaa692b9..77dd3b936131 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -92,11 +92,13 @@ void intel_pipe_update_start(const struct intel_crtc_state *new_crtc_state) struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); const struct drm_display_mode *adjusted_mode = &new_crtc_state->base.adjusted_mode; long timeout = msecs_to_jiffies_timeout(1); - int scanline, min, max, vblank_start; + int scanline, min, max, vblank_start, old_scanline, new_scanline; + bool retried = false; wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(&crtc->base); bool need_vlv_dsi_wa = (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) && intel_crtc_has_type(new_crtc_state, INTEL_OUTPUT_DSI); DEFINE_WAIT(wait); + old_scanline = new_scanline = -1; vblank_start = adjusted_mode->crtc_vblank_start; if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) @@ -126,15 +128,24 @@ void intel_pipe_update_start(const struct intel_crtc_state *new_crtc_state) * read the scanline. */ prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE); - +retry: scanline = intel_get_crtc_scanline(crtc); + old_scanline = new_scanline, new_scanline = scanline; + if (scanline < min || scanline > max) break; if (timeout <= 0) { - DRM_ERROR("Potential atomic update failure on pipe %c\n", + if(!i915.enable_psr || retried) { + DRM_ERROR("Potential atomic update failure on pipe %c\n", pipe_name(crtc->pipe)); - break; + break; + } + else if(old_scanline == new_scanline && !retried) { + retried = true; + intel_wait_for_register(dev_priv, EDP_PSR_STATUS_CTL, EDP_PSR_STATUS_STATE_MASK, EDP_PSR_STATUS_STATE_IDLE, 10); + goto retry; + } } local_irq_enable();