From patchwork Wed Dec 23 12:51:04 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yakir Yang X-Patchwork-Id: 7912021 Return-Path: X-Original-To: patchwork-linux-rockchip@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 5F98F9F318 for ; Wed, 23 Dec 2015 12:54:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5FDFB204A9 for ; Wed, 23 Dec 2015 12:54:05 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8885B20444 for ; Wed, 23 Dec 2015 12:54:04 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aBivb-0005dS-VY; Wed, 23 Dec 2015 12:54:03 +0000 Received: from lucky1.263xmail.com ([211.157.147.132]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aBivA-0005JL-Be; Wed, 23 Dec 2015 12:53:38 +0000 Received: from ykk?rock-chips.com (unknown [192.168.167.131]) by lucky1.263xmail.com (Postfix) with SMTP id 7ABE65D200; Wed, 23 Dec 2015 20:53:12 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 6E1B340C; Wed, 23 Dec 2015 20:53:07 +0800 (CST) X-RL-SENDER: ykk@rock-chips.com X-FST-TO: inki.dae@samsung.com X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: ykk@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-SENDER: ykk@rock-chips.com X-DNS-TYPE: 0 Received: from localhost.localdomain (unknown [58.22.7.114]) by smtp.263.net (Postfix) whith ESMTP id 23871P3IXP2; Wed, 23 Dec 2015 20:53:09 +0800 (CST) From: Yakir Yang To: Inki Dae , Mark Yao , Jingoo Han , Heiko Stuebner Subject: [PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag Date: Wed, 23 Dec 2015 20:51:04 +0800 Message-Id: <1450875064-19627-1-git-send-email-ykk@rock-chips.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1450873538-18304-1-git-send-email-ykk@rock-chips.com> References: <1450873538-18304-1-git-send-email-ykk@rock-chips.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20151223_045336_987092_C99E4C9F X-CRM114-Status: GOOD ( 10.62 ) X-Spam-Score: -1.9 (-) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Krzysztof Kozlowski , linux-samsung-soc@vger.kernel.org, Russell King , linux-rockchip@lists.infradead.org, emil.l.velikov@gmail.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Kishon Vijay Abraham I , javier@osg.samsung.com, Rob Herring , Yakir Yang , Andy Yan , Thierry Reding , Gustavo Padovan , linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Rockchip platform, sometimes driver would failed at reading EDID message, and it's caused by the AUX reply flag wouldn't received under the 100*10us wait time. But after expand the wait time a little, the AUX reply flag would be set, so maybe the wait time is a little critical. Besides the analogix dp book haven't reminded the standard wait for looking AUX reply flag, so I thought it's okay to expand the wait time. And the external wait time won't hurt Exynos DP too much, cause they wouldn't meet this problem, then driver would received the reply command very soon, so no more additional wait time would bring to Exynos platform. Signed-off-by: Yakir Yang --- Changes in v12: - Using another way to expand the AUX reply wait time (Jingoo) Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c index cba3ffd..8687eea 100644 --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c @@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp) { int reg; int retval = 0; - int timeout_loop = 0; + unsigned long timeout; /* Enable AUX CH operation */ reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2); @@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct analogix_dp_device *dp) writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2); /* Is AUX CH command reply received? */ - reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA); - while (!(reg & RPLY_RECEIV)) { - timeout_loop++; - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) { + timeout = jiffies + msecs_to_jiffies(5); + while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) { + if (time_after(jiffies, timeout)) { dev_err(dp->dev, "AUX CH command reply failed!\n"); return -ETIMEDOUT; } - reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA); usleep_range(10, 11); }