This piece of neat lore has been ported painstakingly and bug-for-bug
compatible from the old crtc helper code.
Imo it's utter nonsense.
If you have disconnect a cable and before you reconnect it, userspace
(or the kernel) does an set_crtc call, this will result in that
connector getting disable. Which will result in a nice black screen
when plugging in the cable again.
There's absolutely no reason the kernel does such policy changes - if
userspace tries to set up a mode on something disconnected we might
fail loudly (since the dp link training fails), but silently adjusting
the output configuration behind userspace's back is a recipe for
disaster. Specifically I think that this could explain some of our
MI_WAIT hangs around suspend, where userspace issues a scanline wait
on a disable pipe. This mechanisims here could explain how that pipe
got disabled without userspace noticing.
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
drivers/gpu/drm/i915/intel_display.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f84fb2e..d469b42 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7319,10 +7319,6 @@ intel_modeset_stage_output_state(struct drm_device *dev,
DRM_DEBUG_KMS("encoder changed, full mode switch\n");
config->mode_changed = true;
}
-
- /* Disable all disconnected encoders. */
- if (connector->base.status == connector_status_disconnected)
- connector->new_encoder = NULL;
}
/* connector->new_encoder is now updated for all connectors. */
--
1.7.11.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
