Shame on me for not putting the bit definitions next to the register
definition in the first place.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL
register per CPU transcoder, not per pipe. This solves "unclaimed register"
messages when booting with eDP only and using the i915.disable_power_well=1.

Also fix a comment and remove an useless empty line.

The error messages were caused by:

  commit 88adfff1
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Thu Mar 28 10:42:01 2013 +0100
      drm/i915: hw readout support for ->has_pch_encoders
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes "unclaimed register" messages when booting with eDP only
and i915.disable_power_well=1.

The error messages were caused by:

  commit 0e8ffe1b
  Author: Daniel Vetter <daniel.vetter@ffwll.ch>
  Date:   Thu Mar 28 10:42:00 2013 +0100
      drm/i915: add hw state readout/checking for pipe_config
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is bad news and shouldn't be happening.

V2: Rebase.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
  - after we receive one of these errors, we mask the interrupt, so
    we won't get an "interrupt storm" and we also won't flood dmesg;
  - at each mode set we enable the interrupts again, so we'll see each
    message at most once per mode set;
  - in the specific places where we need to ignore the errors, we
    completely mask the interrupts.

The downside of this patch is that since we're completely disabling
(masking) the interrupts instead of just not printing error messages,
we will mask more than just what we want on IVB/HSW CPU interrupts
(due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So
when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll
also be masking PCH FIFO underruns for pipe B, because both are
reported by SERR_INT, which has to be either completely enabled or
completely disabled (in othe words, there's no way to disable/enable
specific bits of GEN7_ERR_INT and SERR_INT).

V2: Rename some functions and variables, downgrade messages to
DRM_DEBUG_DRIVER and rebase.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric.  Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.

We need to make sure that the tx lane reset occurs in both the full mode
set and DPMS paths, so factor things out to allow that.

v2: use different DPIO_DIVISOR values for VGA and DisplayPort
v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values
        for all display interfaces
v4: collapse with various updates
v5: squash with crtc enable/pll enable bits
v6: split out DP code (jbarnes)
    put phyready check under IS_VALLEYVIEW (jbarnes)
    remove unneeded check in 9xx pll div update (Jani)
    wrap VLV pll update call in IS_VALLEYVIEW (Jani)
    move port enable back to end of crtc enable (jbarnes)
    put phyready check under IS_VALLEYVIEW (jbarnes)
v7: fix up conflicts against latest drm-intel-next-queued
v8: use DPIO reg names, fix pipes (Jani)
    from mPhy_registers_VLV2_ww20p5 doc
v9: update to latest info from driver enabling notes doc
    driver_vbios_notes_9
v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work
     simultaneously (Jesse)
v11: use pll/port callbacks for DPIO port activity (Daniel)
     use separate VLV CRTC enable function (Daniel)
     move around port ready checks (Jesse)
Signed-off-by: NPallavi G <pallavi.g@intel.com>
Signed-off-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NGajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop pfit changes and add a little comment explaining that
vlv has a different enable sequence and so needs it's own crtc_enable
callback. Also apply a fixup patch from Wu Fengguang to shut up some
compiler warnings.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a reset feature we don't actually need.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Make it compile.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Program few Tx buffer Swing control settings through DPIO.

v2: fix up codingstyle (Daniel)
    call from set_signal_levels (Ville, Daniel)
    use proper port numbers (Jesse)
Signed-off-by: NPallavi G <pallavi.g@intel.com>
Signed-off-by: NYogesh M <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: NGajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2 changes)
[danvet: Reorder if-ladder to avoid two IS_VLV checks.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Stolen from a patch with the below impressive sob-section.
Signed-off-by: NPallavi G <pallavi.g@intel.com>
Signed-off-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NGajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop everything but the header #defines.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Magic updates.

v2: use 64 bit types and math (Ville)

v3: Trim out all the m/n/p calculation changes since they are still
under discussion. Instead squash in a fixup for hdmi limits which
slipped into a different patch.
Signed-off-by: NPallavi G <pallavi.g@intel.com>
Signed-off-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: NYogesh M <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: NGajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Uses slightly different interfaces than other platforms.

v2: track actual set freq, not requested (Rohit)
    fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
    re-add RC6 wake limit write (Ben)
    fixup thresholds to match other platforms (Ben)
    clean up mem freq calculation (Ben)
    clean up debug prints (Ben)
v4: move defines from punit patch (Ville)
v5: remove writes to nonexistent regs (Jesse)
    put RP and RC regs together (Jesse)
    fix RC6 enable (Jesse)
v6: use correct fuse reads from NC (Jesse)
    split out min/max funcs for use in sysfs (Jesse)
    add debugfs & sysfs freq controls (Jesse)
v7: update with Ben's hw_max changes (Jesse)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6)
[danvet: Follow checkpatch sugggestion to use min_t to avoid casting
fun.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add sprite_name() macro which should be used with the kind of sprites
that are fixed to pipes (gen4.5+).

Also use dev_priv->num_plane to calculate the sprite index insted
assuming two sprites per pipe. This should make it print the right
name.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Print the alphabetical name for transcoders. The code already used the
pipe_name() macro for transcoders, so I did the same. But we do have the
(unused) transcoder_name() macro which could be used instead.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Alway use the alphabetical names in debug/error messages for planes,
pipes and ports, instead of using decimal numbers occasionally.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Get rid of the few remaining open coded copies of
pipe_name() and port_name().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When adding the pipe config computation step I've accidentally moved
this a bit away. Which momentarily confused me since the pipe config
step rejected some modesetting operations I expected and so left me
looking in vain for that debug output.

v2: Move the debug output into the right function to prevent this from
happening again.

v3: Make it compile (Ville). Also reorder the patch so that the two
bugfixes are first.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can only enable the pfit if the pipe is disabled. Ensure that this
is obeyed with a neat assert.

Also check whether the pfit is off before enabling it - if not we've
lost track of things somewhere since the pfit is only ever used by the
lvds output.

v2: Fix spell fail in the commit message pointed out by Ville&Jani.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The i9xx modeset sequence is currently pretty fishy, so tight it all
up with some good assert-sprinkling.

We already have good coverage on the disable side, but the enable side
is spotty (since until recently it was wrong).
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just blows through 50ms for naught, since the pipe is off.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is horrible lore and we should be able to get rid of it now
that the lvds/pfit handling code actually does the right thing.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Oops.

This regression has been introduced in

commit 5d2d38dd
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:45:01 2013 +0100

    drm/i915: clean up pipe bpp confusion
Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For a bunch of reason we need to more accurately track this:
- hw pipe state readout for Haswell needs the cpu transcoder.
- We need to know the right cpu transcoder in a bunch of places in
  ->disable and other modeset callbacks.

In the future we need to add hw state readout&check support, too. But
to avoid ugly merge conflicts do the rote sed job now without any
functional changes.

v2: Preserve the cpu_transcoder value when overwriting crtc->config.
Reported by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: Removed rough whitespace that Chris spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Delete the redudant #define that Imre spotted in his review.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.

This should fix some machines that were showing black screens on all
outputs.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.

v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker.
v3: Clarified loop start value,
    Removed superfluous test for Ivybridge and Haswell,
    Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)
v4: Fixed two bugs pointed out by Jani Nikula.
Signed-off-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.

v2: Fixed cleanup typo.
v3: Fixed format issues, clarified a variable name,
    changed pr_warn() to DRM_INFO() as suggested by
    Jani Nikula <jani.nikula@linux.intel.com>.
Signed-off-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.
Signed-off-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.
Signed-off-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise seems to be bad routing of the hotplug line
on the board: cross talk from other signals seems to cause erronous
hotplug interrupts. This has been documented as an erratum for the
the i945GM chipset and thus hotplug support was disabled for this
chipset model but others seem to have this problem, too.

We have seen this issue on a G35 motherboard for example:
Even different motherboards of the same model seem to behave
differently: while some only see only around 10-100 interrupts/s
others seem to see 5k or more.
We've also observed a dependency on the selected video mode.

Also on certain laptops interrupt noise seems to occur duing
battery charging when the battery is at a certain charge levels.

Thus we add a simple algorithm here that detects an 'interrupt storm'
condition.

v2: Fixed comment.
v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff.
v4: Followed by Jesse Barnes to use a time_..() macro.
v5: Fixed coding style as suggested by Jani Nikula.
Signed-off-by: NEgbert Eich <eich@suse.de>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.

Cc: stable@vger.kernel.org
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Caused by me with v2 of

commit 219f4fdb
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Fri Mar 15 11:17:54 2013 -0700

    drm/i915: Introduce GEN7_FEATURES for device info

I don't have a VLV to test it with, Jesse, Ken, can one of you test?

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.

v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add space checkpatch complained about.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

commit 647416f9
Author: Kees Cook <keescook@chromium.org>
Date:   Sun Mar 10 14:10:06 2013 -0700

    drm/i915: use simple attribute in debugfs routines

made i915_next_seqno debugfs entry to crop it's output
if returned value was large enough. Using simple_attr
will limit the output to 24 bytes.

Fix is to strip out preamples on all simple attributes
that have one.

v2: Fix all simple attributes (Daniel Vetter)

Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Acked-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The recent rework of the pfit handling didn't take into account that
the panel fitter is fixed to pipe B:

commit 24a1f16d
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Feb 8 16:35:37 2013 +0200

    drm/i915: disable shared panel fitter for pipe

Fix this up by properly computing the pipe the pfit is on. Also
extract the logic into its own function, add a debug assert to check
that the pipe is off (mostly just documentation) and add some debug
output.

If pipe A was disabled after pipe B was set up, the panel fitter will
be disabled. Now most userspace doesn't do modesets in this order,
which is why I couldn't ever reproduce this and why it took me so long
to figure out.

We really need hw state readout and check support for the pannel
fitter ...
Reported-by: NHans de Bruin <jmdebruin@xmsnet.nl>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Hans de Bruin <jmdebruin@xmsnet.nl>
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19049Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.

So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes compares the current state with where we
want to go to (which is carefully set up by intel_crtc_set_config) and
then goes through the modeset sequence for any crtc which needs
updating.

Now the issue is that the actual interface with the remaining code
still only works on one crtc, and so we only pass in one fb and one
mode. In intel_set_mode we also only compute one intel_crtc_config
(which should be the one for the crtc we're doing a modeset on).

The reason for that mismatch is twofold:
- We want to eventually do all modeset as global state changes, so
it's just infrastructure prep.
- But even the old semantics can change more than one crtc when you
e.g. move a connector from crtc A to crtc B, then both crtc A and B
need to be updated. Usually that means one pipe is disabled and the
other enabled. This is also the reason why the hack doesn't touch the
disable_pipes mask.

Now hilarity ensued in our kms config restore paths when we actually
try to do a modeset on all crtcs: If the first crtc should be off and
the second should be on, then the call on the first crtc will notice
that the 2nd one should be switched on and so tries to compute the
pipe_config. But due to a lack of passed-in fb (crtc 1 should be off
after all) it only results in tears.

This case is ridiculously easy to hit on gen2/3 where the lvds output
is restricted to pipe B. Note that before the pipe_config bpp rework
gen2/3 didn't care really about the fb->depth, so this is a regression
brought to light with

commit 4e53c2e0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:58 2013 +0100

    drm/i915: precompute pipe bpp before touching the hw

But apparently Ajax also managed to blow up pch platforms, probably
with some randomized configs, and pch platforms trip up over the lack
of an fb even in the old code. So this actually goes back to the first
introduction of the new modeset restore code in

commit 45e2b5f6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Nov 23 18:16:34 2012 +0100

    drm/i915: force restore on lid open

Fix this mess by now by justing shunting all the cool new global
modeset logic in intel_modeset_affected_pipes.

v2: Improve commit message and clean up all the comments in
intel_modeset_affected_pipes - since the introduction of the modeset
restore code they've been a bit outdated.

Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725
Cc: stable@vger.kernel.org
References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.htmlTested-by: NRichard Cochran <richardcochran@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.

A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NPeter Verthez <peter.verthez@skynet.be>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>