From 6ee3b5a12740eddc5a76e130b6cc7cc64468d1f7 Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Thu, 24 Mar 2011 13:26:43 +0000 Subject: drm/i915/lvds: Always return connected in the absence of better information The LVDS connector should default to connected. We tried our best to verify the claims of the BIOS that the hardware exists during init(), and then during detect() we then try to verify that the panel is open. In the event of an unsuccessful query, we should then always report that the LVDS panel is connected. This was only the case for gen2/3, later generations leaked the return value from the panel probe instead. Reported-and-tested-by: Alessandro Suardi Signed-off-by: Chris Wilson Reviewed-by: Keith Packard --- drivers/gpu/drm/i915/intel_lvds.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) (limited to 'drivers') diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 1a311ad0111..86cd30bcb61 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -473,19 +473,13 @@ static enum drm_connector_status intel_lvds_detect(struct drm_connector *connector, bool force) { struct drm_device *dev = connector->dev; - enum drm_connector_status status = connector_status_connected; + enum drm_connector_status status; status = intel_panel_detect(dev); if (status != connector_status_unknown) return status; - /* ACPI lid methods were generally unreliable in this generation, so - * don't even bother. - */ - if (IS_GEN2(dev) || IS_GEN3(dev)) - return connector_status_connected; - - return status; + return connector_status_connected; } /** -- cgit v1.2.3 From 9f01b25048ad12b5d71f4f7d3b62ef737639a08d Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Thu, 24 Mar 2011 11:37:03 +0000 Subject: drm/i915: Busy-spin wait_for condition in atomic contexts During modesetting, we need to wait for the hardware to report readiness by polling the registers. Normally, we call msleep() between reads, because some state changes may take a whole vblank or more to complete. However during a panic, we are in an atomic context and cannot sleep. Instead, busy spin polling the termination condition. References: https://bugzilla.kernel.org/show_bug.cgi?id=31772 Signed-off-by: Chris Wilson Reviewed-by: Keith Packard Reviewed-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers') diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 5daa991cb28..f5b0d8306d8 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -39,7 +39,7 @@ ret__ = -ETIMEDOUT; \ break; \ } \ - if (W && !in_dbg_master()) msleep(W); \ + if (W && !(in_atomic() || in_dbg_master())) msleep(W); \ } \ ret__; \ }) -- cgit v1.2.3 From 7f58aabc369014fda3a4a33604ba0a1b63b941ac Mon Sep 17 00:00:00 2001 From: Chris Wilson Date: Wed, 30 Mar 2011 16:20:43 +0100 Subject: drm/i915: Reset GMBUS controller after NAK Once a NAK has been asserted by the slave, we need to reset the GMBUS controller in order to continue. This is done by asserting the Software Clear Interrupt bit and then clearing it again to restore operations. If we don't clear the NAK, then all future GMBUS xfers will fail, including DDC probes and EDID retrieval. v2: Add some comments as suggested by Keith Packard. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781 Signed-off-by: Chris Wilson Reviewed-by: Keith Packard Tested-by: Jesse Barnes Tested-by: "Mengmeng Meng" --- drivers/gpu/drm/i915/intel_i2c.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-) (limited to 'drivers') diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 82d04c5899d..d3b903bce7c 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -259,7 +259,7 @@ gmbus_xfer(struct i2c_adapter *adapter, if (wait_for(I915_READ(GMBUS2 + reg_offset) & (GMBUS_SATOER | GMBUS_HW_RDY), 50)) goto timeout; if (I915_READ(GMBUS2 + reg_offset) & GMBUS_SATOER) - return 0; + goto clear_err; val = I915_READ(GMBUS3 + reg_offset); do { @@ -287,7 +287,7 @@ gmbus_xfer(struct i2c_adapter *adapter, if (wait_for(I915_READ(GMBUS2 + reg_offset) & (GMBUS_SATOER | GMBUS_HW_RDY), 50)) goto timeout; if (I915_READ(GMBUS2 + reg_offset) & GMBUS_SATOER) - return 0; + goto clear_err; val = loop = 0; do { @@ -302,14 +302,31 @@ gmbus_xfer(struct i2c_adapter *adapter, if (i + 1 < num && wait_for(I915_READ(GMBUS2 + reg_offset) & (GMBUS_SATOER | GMBUS_HW_WAIT_PHASE), 50)) goto timeout; if (I915_READ(GMBUS2 + reg_offset) & GMBUS_SATOER) - return 0; + goto clear_err; } - return num; + goto done; + +clear_err: + /* Toggle the Software Clear Interrupt bit. This has the effect + * of resetting the GMBUS controller and so clearing the + * BUS_ERROR raised by the slave's NAK. + */ + I915_WRITE(GMBUS1 + reg_offset, GMBUS_SW_CLR_INT); + I915_WRITE(GMBUS1 + reg_offset, 0); + +done: + /* Mark the GMBUS interface as disabled. We will re-enable it at the + * start of the next xfer, till then let it sleep. + */ + I915_WRITE(GMBUS0 + reg_offset, 0); + return i; timeout: DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d [%s]\n", bus->reg0 & 0xff, bus->adapter.name); + I915_WRITE(GMBUS0 + reg_offset, 0); + /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */ bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff); if (!bus->force_bit) -- cgit v1.2.3