diff options
author | Ville Syrjälä <ville.syrjala@linux.intel.com> | 2014-08-11 12:15:36 +0200 |
---|---|---|
committer | Jani Nikula <jani.nikula@intel.com> | 2014-08-18 09:42:41 +0200 |
commit | a459249c73eaec1daf4e4657ea3564cc3550e66c (patch) | |
tree | 95404eca86e7deaa5a0a3664aa3fb31306715aa5 /fs/open.c | |
parent | drm/i915: Fix locking for intel_enable_pipe_a() (diff) | |
download | linux-a459249c73eaec1daf4e4657ea3564cc3550e66c.tar.xz linux-a459249c73eaec1daf4e4657ea3564cc3550e66c.zip |
drm/i915: Skip load detect when intel_crtc->new_enable==true
During suspend we turn off the crtcs, but leave the staged config in
place so that we can restore the display(s) to their previous state on
resume.
During resume when we attempt to apply the force pipe A quirk we use the
load detect mechanism. That doesn't check whether there was an already
staged configuration for the crtc since that's not even possible during
normal runtime load detection. But during resume it is possible, and if
we just blindly go and overwrite the staged crtc configuration for the
load detection we can no longer restore the display to the correct
state.
Even worse, we don't even clear all the staged connector->encoder->crtc
links so we may end up using a cloned setup for the load detection, and
after we're done we just clear the links related to the VGA output
leaving the links for the other outputs in place. This will eventually
result in calling intel_set_mode() with mode==NULL but with valid
connector->encoder->crtc links which will result in dereferencing the
NULL mode since the code thinks it will have to a modeset.
To avoid these problems don't use any crtc with new_enabled==true for
load detection.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (for 3.16)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Diffstat (limited to 'fs/open.c')
0 files changed, 0 insertions, 0 deletions