From 9dc10f37e326d5d789929e1886b5a8089ccee5a7 Mon Sep 17 00:00:00 2001
From: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed, 29 Aug 2012 22:58:07 +0200
Subject: [PATCH] drm/i915: no longer call drm_helper_resume_force_mode
Git-commit: 9dc10f37e326d5d789929e1886b5a8089ccee5a7
Patch-mainline: 3.7-rc1
References: bnc#831424,bnc#800875

Since this only calls crtc helper functions, of which a shocking
amount are NULL.

Now the curious thing is how the new modeset code worked with this
function call still present:

Thanks to the hw state readout and the suspend fixes to properly
quiescent the register state, nothing is actually enabled at resume
(if the bios doesn't set up anything). Which means resume_force_mode
doesn't actually do anything and hence nothing blows up at resume
time.

The other reason things do work is that the fbcon layer has it's own
resume notifier callback, which restores the mode. And thanks to the
force vt switch at suspend/resume, that then forces X to restore it's
own mode.

Hence everything still worked (as long as the bios doesn't enable
anything). And we can just kill the call to resume_force_mode.

The upside of both this patch and the preceeding patch to quiescent
the modeset state is that our resume path is much simpler:
- We now longer restore bogus register values (which most often would
  enable the backlight a bit and a few ports), causing flickering.
- We now longer call resume_force_mode to restore a mode that the
  fbcon layer would overwrite right away anyway.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Takashi Iwai <tiwai@suse.de>

---
 drivers/gpu/drm/i915/i915_drv.c |    5 -----
 1 file changed, 5 deletions(-)

--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -595,11 +595,6 @@ static int __i915_drm_thaw(struct drm_de
 		intel_modeset_init_hw(dev);
 		intel_modeset_setup_hw_state(dev, false);
 
-		/* Resume the modeset for every activated CRTC */
-		mutex_lock(&dev->mode_config.mutex);
-		drm_helper_resume_force_mode(dev);
-		mutex_unlock(&dev->mode_config.mutex);
-
 		/*
 		 * ... but also need to make sure that hotplug processing
 		 * doesn't cause havoc. Like in the driver load code we don't
