From patchwork Tue Jul 18 21:34:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: jim.bride@linux.intel.com X-Patchwork-Id: 9849569 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 78E74600CC for ; Tue, 18 Jul 2017 21:36:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 670CC285DE for ; Tue, 18 Jul 2017 21:36:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5BD60285F7; Tue, 18 Jul 2017 21:36:48 +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]) (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 140EA285DE for ; Tue, 18 Jul 2017 21:36:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 253496E3CD; Tue, 18 Jul 2017 21:36:45 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id A42366E11D for ; Tue, 18 Jul 2017 21:36:43 +0000 (UTC) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2017 14:36:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,378,1496127600"; d="scan'208";a="288527409" Received: from shiv.jf.intel.com ([10.54.75.141]) by fmsmga004.fm.intel.com with ESMTP; 18 Jul 2017 14:36:42 -0700 From: Jim Bride To: intel-gfx@lists.freedesktop.org Date: Tue, 18 Jul 2017 14:34:06 -0700 Message-Id: <1500413648-4765-2-git-send-email-jim.bride@linux.intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1500413648-4765-1-git-send-email-jim.bride@linux.intel.com> References: <1500413648-4765-1-git-send-email-jim.bride@linux.intel.com> In-Reply-To: <1499811596-14634-1-git-send-email-jim.bride@linux.intel.com> References: <1499811596-14634-1-git-send-email-jim.bride@linux.intel.com> Cc: Jani Nikula , Paulo Zanoni , Rodrigo Vivi Subject: [Intel-gfx] [PATCH v4 2/4] drm/i915/psr: Account for sink CRC raciness on some panels 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: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP According to the eDP spec, when the count field in TEST_SINK_MISC increments then the six bytes of sink CRC information in the DPCD should be valid. Unfortunately, this doesn't seem to be the case on some panels, and as a result we get some incorrect and inconsistent values from the sink CRC DPCD locations at times. This problem exhibits itself more on faster processors (relative failure rates HSW < SKL < KBL.) In order to try and account for this, we try a lot harder to read the sink CRC until we get consistent values twice in a row before returning what we read and delay for a time before trying to read. We still see some occasional failures, but reading the sink CRC is much more reliable, particularly on SKL and KBL, with these changes than without. v2: * Reduce number of retries when reading the sink CRC (Jani) * Refactor to minimize changes to the code (Jani) * Rebase v3: * Rebase v4: * Switch from do-while to for loop when reading CRC values (Jani) * Rebase Cc: Rodrigo Vivi Cc: Paulo Zanoni Cc: Jani Nikula Signed-off-by: Jim Bride --- drivers/gpu/drm/i915/intel_dp.c | 33 ++++++++++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 2d42d09..c90ca1c 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3906,6 +3906,11 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc) u8 buf; int count, ret; int attempts = 6; + u8 old_crc[6]; + + if (crc == NULL) { + return -ENOMEM; + } ret = intel_dp_sink_crc_start(intel_dp); if (ret) @@ -3929,11 +3934,33 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc) goto stop; } - if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) { - ret = -EIO; - goto stop; + /* + * Sometimes it takes a while for the "real" CRC values to land in + * the DPCD, so try several times until we get two reads in a row + * that are the same. If we're an eDP panel, delay between reads + * for a while since the values take a bit longer to propagate. + */ + for (attempts = 0; attempts < 6; attempts++) { + intel_wait_for_vblank(dev_priv, intel_crtc->pipe); + + if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, + crc, 6) < 0) { + ret = -EIO; + break; + } + + if (attempts && memcmp(old_crc, crc, 6) == 0) + break; + memcpy(old_crc, crc, 6); + + if (is_edp(intel_dp)) + usleep_range(20000, 25000); } + if (attempts == 6) { + DRM_DEBUG_KMS("Failed to get CRC after 6 attempts.\n"); + ret = -ETIMEDOUT; + } stop: intel_dp_sink_crc_stop(intel_dp); return ret;