On Mon, 25 Jul 2011 10:10:29 -0700 Keith Packard keithp@keithp.com wrote:
Hotplug detection is a mode setting operation and must hold the struct_mutex or risk colliding with other mode setting operations.
In particular, the display port hotplug function attempts to re-train the link if the monitor is supposed to be running when plugged back in. If that happens while mode setting is underway, the link will get scrambled, leaving it in an inconsistent state.
Signed-off-by: Keith Packard keithp@keithp.com
drivers/gpu/drm/i915/i915_irq.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 3b03f85..5fe8f28 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -306,12 +306,15 @@ static void i915_hotplug_work_func(struct work_struct *work) struct drm_mode_config *mode_config = &dev->mode_config; struct intel_encoder *encoder;
mutex_lock(&dev_priv->dev->struct_mutex); DRM_DEBUG_KMS("running encoder hotplug functions\n");
list_for_each_entry(encoder, &mode_config->encoder_list, base.head) if (encoder->hot_plug) encoder->hot_plug(encoder);
mutex_unlock(&dev_priv->dev->struct_mutex);
/* Just fire off a uevent and let userspace tell us what to do */ drm_helper_hpd_irq_event(dev);
}
yay, sounds like this will fix Andrew's problem and probably lots of other random DP related failures.
Looks like the ->detect function is similarly protected at the call site (though one level up in ->fill_modes), so it should be safe. Looks like all the call sites in the link_status function are safe too.
Reviewed-by: Jesse Barnes jbarnes@virtuousgeek.org
Let's get this one upstream asap. Should probably be cc'd to stable@kernel.org as well.