aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2012-05-21 14:19:48 -0400
committerDaniel Vetter <daniel.vetter@ffwll.ch>2012-05-21 15:04:21 -0400
commit65e818660275ecda3702a4245f308923e3813a85 (patch)
tree35884f20a18fc66a4adf2eb1d229dff095c3ad98 /drivers/gpu
parentf15b4ca2ccbc0a4661c35a744d254e1e32dd1e15 (diff)
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-Tested-by: Julian Simioni <julian.simioni@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Kurtz <djkurtz@chromium.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu')
-rw-r--r--drivers/gpu/drm/i915/intel_i2c.c21
1 files changed, 12 insertions, 9 deletions
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 4a9707dd0f9..1991a4408cf 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -396,11 +396,22 @@ clear_err:
396 * Wait for bus to IDLE before clearing NAK. 396 * Wait for bus to IDLE before clearing NAK.
397 * If we clear the NAK while bus is still active, then it will stay 397 * If we clear the NAK while bus is still active, then it will stay
398 * active and the next transaction may fail. 398 * active and the next transaction may fail.
399 *
400 * If no ACK is received during the address phase of a transaction, the
401 * adapter must report -ENXIO. It is not clear what to return if no ACK
402 * is received at other times. But we have to be careful to not return
403 * spurious -ENXIO because that will prevent i2c and drm edid functions
404 * from retrying. So return -ENXIO only when gmbus properly quiescents -
405 * timing out seems to happen when there _is_ a ddc chip present, but
406 * it's slow responding and only answers on the 2nd retry.
399 */ 407 */
408 ret = -ENXIO;
400 if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 409 if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
401 10)) 410 10)) {
402 DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n", 411 DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
403 adapter->name); 412 adapter->name);
413 ret = -ETIMEDOUT;
414 }
404 415
405 /* Toggle the Software Clear Interrupt bit. This has the effect 416 /* Toggle the Software Clear Interrupt bit. This has the effect
406 * of resetting the GMBUS controller and so clearing the 417 * of resetting the GMBUS controller and so clearing the
@@ -414,14 +425,6 @@ clear_err:
414 adapter->name, msgs[i].addr, 425 adapter->name, msgs[i].addr,
415 (msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len); 426 (msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
416 427
417 /*
418 * If no ACK is received during the address phase of a transaction,
419 * the adapter must report -ENXIO.
420 * It is not clear what to return if no ACK is received at other times.
421 * So, we always return -ENXIO in all NAK cases, to ensure we send
422 * it at least during the one case that is specified.
423 */
424 ret = -ENXIO;
425 goto out; 428 goto out;
426 429
427timeout: 430timeout: