linux-kernel - [PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1450875064-19627-1-git-send-email-ykk@rock-chips.com>
Date:	Wed, 23 Dec 2015 20:51:04 +0800
From:	Yakir Yang <ykk@...k-chips.com>
To:	Inki Dae <inki.dae@...sung.com>,
	Mark Yao <mark.yao@...k-chips.com>,
	Jingoo Han <jingoohan1@...il.com>,
	Heiko Stuebner <heiko@...ech.de>
Cc:	Thierry Reding <treding@...dia.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Russell King <linux@....linux.org.uk>,
	emil.l.velikov@...il.com,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	Kishon Vijay Abraham I <kishon@...com>,
	javier@....samsung.com, Andy Yan <andy.yan@...k-chips.com>,
	Yakir Yang <ykk@...k-chips.com>,
	dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	linux-rockchip@...ts.infradead.org,
	linux-arm-kernel@...ts.infradead.org
Subject: [PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

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 <ykk@...k-chips.com>
---
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);
 	}
 
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/