Attachment 61885 Details for Bug 49518 – improved patch after review

[patch] improved patch after review

0001-drm-i915-be-more-careful-when-returning-ENXIO-in-gmb.patch (text/plain), 2.98 KB, created by Daniel Vetter on 2012-05-20 11:25:34 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Daniel Vetter

Created: 2012-05-20 11:25:34 UTC

Size: 2.98 KB

patch

obsolete

>From 9a0e3e3c75a06a34c7afe761e6aafc9f19ba39dd Mon Sep 17 00:00:00 2001
>From: Daniel Vetter <daniel.vetter@ffwll.ch>
>Date: Thu, 10 May 2012 13:21:57 +0200
>Subject: [PATCH] drm/i915: be more careful when returning -ENXIO in gmbus
> transfer
>
>... flaky ddc hardware can cause a spurious NAK, resulting in the i2c
>core and drm edid functions not trying to retry the edid transfer.
>
>Luckily the gmbus quiescenting also times out for these cases, so we
>can get out of this mess by returning -ETIMEDOUT for this specific
>case. This way we keep the fast-fail of returning -ENXIO if there is
>no device present, speeding up the boot process.
>
>This regression has been introduced in
>
>commit e646d5773572bf52017983d758bdf05777dc5600
>Author: Daniel Kurtz <djkurtz@chromium.org>
>Date:   Fri Mar 30 19:46:38 2012 +0800
>
>    drm/i915/intel_i2c: always wait for IDLE before clearing NAK
>
>v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs,
>suggested by Daniel Kurtz.
>
>Cc: Daniel Kurtz <djkurtz@chromium.org>
>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518
>Reported-and-not-yet-Tested-by: Julian Simioni <julian.simioni@gmail.com>
>Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>---
> drivers/gpu/drm/i915/intel_i2c.c |   21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
>index e04255e..892477b 100644
>--- a/drivers/gpu/drm/i915/intel_i2c.c
>+++ b/drivers/gpu/drm/i915/intel_i2c.c
>@@ -396,11 +396,22 @@ clear_err:
> 	 * Wait for bus to IDLE before clearing NAK.
> 	 * If we clear the NAK while bus is still active, then it will stay
> 	 * active and the next transaction may fail.
>+	 *
>+	 * If no ACK is received during the address phase of a transaction, the
>+	 * adapter must report -ENXIO. It is not clear what to return if no ACK
>+	 * is received at other times. But we have to be careful to not return
>+	 * spurious -ENXIO because that will prevent i2c and drm edid functions
>+	 * from retrying. So return -ENXIO only when gmbus properly quiescents -
>+	 * timing out seems to happen when there _is_ a ddc chip present, but
>+	 * it's slow responding and only answers on the 2nd retry.
> 	 */
>+	ret = -ENXIO;
> 	if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
>-		     10))
>+		     10)) {
> 		DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
> 			      adapter->name);
>+		ret = -ETIMEDOUT;
>+	}
> 
> 	/* Toggle the Software Clear Interrupt bit. This has the effect
> 	 * of resetting the GMBUS controller and so clearing the
>@@ -414,14 +425,6 @@ clear_err:
> 			 adapter->name, msgs[i].addr,
> 			 (msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
> 
>-	/*
>-	 * If no ACK is received during the address phase of a transaction,
>-	 * the adapter must report -ENXIO.
>-	 * It is not clear what to return if no ACK is received at other times.
>-	 * So, we always return -ENXIO in all NAK cases, to ensure we send
>-	 * it at least during the one case that is specified.
>-	 */
>-	ret = -ENXIO;
> 	goto out;
> 
> timeout:
>-- 
>1.7.10
>

Actions: View | Splinter Review

Attachments on bug 49518: 61064 | 61065 | 61088 | 61089 | 61090 | 61203 | 61204 | 61350 | 61885

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.