Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Time to light a candle and remove the preliminary_hw_support flag.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

on SKL/BXT, the top most plane hardware is shared between the legacy
cursor registers and an actual plane. Daniel and Ville don't want to
expose 2 DRM planes and would rather expose a CURSOR plane that has all
the usual plane properties, and that's a blocker for lifting the
prelimary_hw_support flag.

Unfortunately noone has had the time to finish this yet, but lifting the
prelimary_hw_support flag is long overdue. As an intermediate solution
we can merely not expose the top most plane

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fix divide by zero if we end up updating the watermarks
with zero dotclock.

This is a stop gap measure to allow module load in cases
where our state keeping fails.

v2: WARN_ON added (Paulo)

Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-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>

Fastboot should only downgrade a modeset if we have a match, not be
used to upgrade to a full modeset. Otherwise we can only use it in a
very restricted way: Initial modeset when the request mode is the
preferred one of the panel and there's still a pfit active. And that
only works because our mode_from_pipe_config fills in the wrong mode
(it takes the adjusted mode, not the requested one).

But we want fast modesets everywhere even after boot-up (especially
for testing, but not only there). Hence we need to be able to make any
modeset a fast one, which means we need to invert the logic and
optionally downgrade a modeset.

Note that this needs ->connector_changed split out from ->mode_changed
otherwise it's not going to work (because we might loose a modeset
because connectors changed but otherwise the config matches). As soon
as that's merged we can drop the i915.fastboot check from this code.

Also make sure that we don't accidentally clear any_ms and that we add
the planes for any kind of modeset.

Finally rename fastboot to fastset (yeah it's a silly name) since this
really isn't about booting all that much.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we both set mode->private_flags to some value and also use
the pipe_config quirk. But since the pipe_config quirk isn't tied to
the lifetime of the mode object we need to check both.

Simplify this by only using mode.private_flags and stop using the
INHERITED_MODE quirk. Also for clarity add an explicit #define for
that driver priavete mode flag.

By using crtc_state->mode_changed we can also remove the recalc local
variable.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we recompute the pipe config for all CRTCs that have changed
we don't have problems with stale configuration data for the global
pfit and can remove this hack. Yay!

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This can only fail because of a bug in the code.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Squash in follow-up to also remove start_vbl_count from
intel_crtc->atomic and put it into the intel_crtc directly - it's not
precomputed state.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We needed this originally for updating pagetables in plane commit
functions. But that's extracted into prepare/cleanup now. The other
issue was running updates when the pipe was off. That's also now
fixed.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that there's only a single path for all atomic updates we can call
intel_(pre/post)_plane_update from intel_atomic_commit directly. This
makes the intention more clear.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Huzzah! \o/
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Indirect context w/a batch buffer,
+WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken

v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).

v3: explain why part of the WA is in Per ctx batch (Mika)

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Indirect context w/a batch buffer,
+WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt

v2: address static checker warning where unsigned value was checked for
less than zero which is never true (Dan Carpenter).

v3: The WA uses default value of GEN8_L3SQCREG4 during flush but that disables
some other WA; update default value to retain it and document dependency (Mika).

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Indirect and Per context w/a batch buffer,
+WaDisableCtxRestoreArbitration

v2: SKL revision id was used for BXT, copy paste error found during
internal review (Bob Beckett).

v3: use updated macro.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Cc: Robert Beckett <robert.beckett@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch only enables support for Gen9, the actual WA will be
initialized in subsequent patches.

The WARN that we use to warn user if WA batch support is not available
for a particular Gen is replaced with DRM_ERROR as warning here doesn't
really add much value.

v2: include all infrastructure bits in this patch so that subsequent
changes only correspond the WA added (Chris)

v3: use updated macro.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Patch leakage fixed
Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I was confused shortly whether the compat was needed for the int,
until I noticed the pointer in the original.

Also remove typedef.

v2: Review from Chris.
- Add comments.
- Also change the int param in the original structure.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes the breakage caused by

commit eddfcbcd
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Jun 15 12:33:53 2015 +0200

    drm/i915: Update less state during modeset.

    No need to repeatedly call update_watermarks, or update_fbc.
    Down to a single call to update_watermarks in .crtc_enable
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
    Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add missing shared dpll disable to the noatomic disable function.

This function will be replaced by its atomic counterpart soon.

Changes since v1:
- intel_crtc->active and watermarks are fixed by a patch from
  Patrik Jakobsson
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fill in driver type, hsync, vrefresh and name.
Those members are not read out but can be calculated from the mode.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Updated the HAS_CORE_RING_FREQ macro to add the broxton check,
so as to disallow the programming & read of ring frequency
table for it.

Issue: VIZ-5144
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added a new HAS_CORE_RING_FREQ macro, currently used in
gen6_update_ring_freq & i915_ring_freq_table debugfs function.
The programming & read of ring frequency table is needed for newer
GEN(>=6) platforms, except VLV/CHV.

Issue: VIZ-5144
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAkash Goel <akash.goel@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Calculate all state using a normal transition, but afterwards fudge
crtc->state->active back to its old value. This should still allow
state restore in setup_hw_state to work properly.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.

Because this is not yet done atomically, assume a full modeset is
needed and force a modeset on the crtc.

Changes since v1:
- s/reset/force modeset/
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This allows us to get rid of the set_init_power in
modeset_update_crtc_domains. The state should be sanitized enough
after setup_hw_state to not need the init power.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The previous commit converted hw readout to atomic, all the new_*
members were used for restoring the old state, but with the
conversion of suspend to atomic there's no use left for them.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of all the ad-hoc updating, duplicate the old state first
before reading out the hw state, then restore it.

intel_display_resume is a new function that duplicates the sw state,
then reads out the hw state, and commits the old state.

intel_display_setup_hw_state now only reads out the atomic state.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Readout initial hw mode, v2.

Atomic requires a mode blob when crtc_state->enable is true, or
you get a huge warn_on.

With a few tweaks the mode we read out from hardware could be used
as the real mode without a modeset, but this requires too much
testing, so for now force a modeset the first time the mode blob's
updated.

This preserves the old behavior, because previously we never set
the initial mode, which always meant that a modeset happened
when the mode was first set.

Changes since v1:
- Add a description in intel_modeset_readout_hw_state of how the
  recalculation is done.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is required to properly initialize vblanks on the active crtc.
Without it drm_calc_vbltimestamp_from_scanoutpos can fail with
crtc 0: Noop due to uninitialized mode.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic property.
If the mode_blob still exists, but enable = false then all updates are rejected with -EINVAL.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Unreference the old mode_blob by calling the crtc_destroy_state
helper before zeroing the crtc_state.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All non-primary planes get disabled during hw readout,
this reduces complexity and means not having to do some plane
visibility checks during the first commit.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This change adds the programming of the MOCS registers to the gen 9+
platforms. The set of MOCS configuration entries introduced by this
patch is intended to be minimal but sufficient to cover the needs of
current userspace - i.e. a good set of defaults. It is expected to be
extended in the future to provide further default values or to allow
userspace to redefine its private MOCS tables based on its demand for
additional caching configurations. In this setup, userspace should
only utilize the first N entries, higher entries are reserved for
future use.

It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.

v2:
-'static const' for private data structures and style changes.(Matt Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
v5:
- Changed the name of a function. (Chris Wilson)
v6:
- re-based
- Added Mesa table entry (skylake & broxton) (Francisco Jerez)
- Tidied up the readability defines (Francisco Jerez)
- NUMBER of entries defines wrong. (Jim Bish)
- Added comments to clear up the meaning of the tables (Jim Bish)
Signed-off-by: NPeter Antoine <peter.antoine@intel.com>

v7 (Francisco Jerez):
- Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
  tables.  Prefix L3-specific defines consistently with L3_ and
  e/LLC-specific defines with LE_ to avoid this kind of confusion in
  the future.
- Change L3CC WT define back to RESERVED (matches my hardware
  documentation and the original patch, probably a misunderstanding
  of my own previous comment).
- Drop Android tables, define new minimal tables more suitable for the
  open source stack.
- Add comment that the MOCS tables are part of the kernel ABI.
- Move intel_logical_ring_begin() and _advance() calls one level down
  (Chris Wilson).
- Minor formatting and style fixes.
v8 (Francisco Jerez):
- Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
  Wilson).
- Add comment about undefined entries being implicitly set to uncached
  for forwards compatibility.
v9 (Francisco Jerez):
- Minor style fixes.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Acked-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Totatlly forgotten that we have these when nuking all the UMS code.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Nothing depends on this outside initial hw readout, so keep this
struct on the stack instead.

Changes since v1:
- Remove unrelated changes.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The src and crtc rectangles were never set, resulting in the primary
plane being made invisible on first atomic update.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of doing ad-hoc checks we already have a way of checking
if the state is compatible or not. Use this to force a modeset.

Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
we should check if a full modeset is really needed.

Fastboot will allow the adjust parameter to ignore some stuff
too, and it will fix up differences in state that are ignored
by the compare function.

Changes since v1:
- Increase the value of the lowest m/n to prevent truncation.
- Dump pipe config when fastboot's used, without a modeset.
- Add adjust parameter to intel_compare_link_m_n, which is
  used to adjust m2_n2 if it's a multiple of m_n.
- Add exact parameter intel_compare_m_n.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the atomic state instead, this allows removing plane_config
from the crtc after the full hw readout is completed.

The size can be found in the fb, no need for the plane_config.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's not much point for calculating the changes for the old
state. Instead just disable all scalers when disabling. It's
probably good enough to just disable the crtc_scaler, but just in
case there's a bug disable all scalers.

This means intel_atomic_setup_scalers is only called in the crtc
check function now, so all the transitional code can be removed.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is probably hard to hit right now because in most cases all
atomic locks are taken, but after conversion to atomic this will make
it more likely to corrupt the crtc->config pointer, resulting in hard
to find bugs.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When resuming with dpms off, the following warn can happen:

[  118.334082] ------------[ cut here ]------------
[  118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]()
[  118.334106] WARN_ON(!crtc->state->enable)
[  118.334137] Modules linked in: i915
[  118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148
[  118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[  118.334144] Workqueue: events_unbound async_run_entry_fn
[  118.334147]  ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001
[  118.334149]  ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8
[  118.334151]  ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668
[  118.334151] Call Trace:
[  118.334155]  [<ffffffff817aa62a>] dump_stack+0x4f/0x7b
[  118.334157]  [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0
[  118.334158]  [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50
[  118.334173]  [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915]
[  118.334188]  [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915]
[  118.334191]  [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80
[  118.334205]  [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915]
[  118.334219]  [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915]
[  118.334232]  [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915]
[  118.334246]  [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915]
[  118.334248]  [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90
[  118.334255]  [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915]
[  118.334262]  [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915]
[  118.334263]  [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0
[  118.334266]  [<ffffffff81467550>] dpm_run_callback+0x70/0x420
[  118.334267]  [<ffffffff81467cbd>] device_resume+0x9d/0x1c0
[  118.334269]  [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60
[  118.334270]  [<ffffffff81467dfc>] async_resume+0x1c/0x50
[  118.334271]  [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0
[  118.334273]  [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0
[  118.334275]  [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0
[  118.334276]  [<ffffffff8109daf9>] worker_thread+0x49/0x450
[  118.334278]  [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0
[  118.334280]  [<ffffffff810a3cb9>] kthread+0xf9/0x110
[  118.334282]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334284]  [<ffffffff817b414f>] ret_from_fork+0x3f/0x70
[  118.334286]  [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90
[  118.334287] ---[ end trace 01f2cf6371b82d7a ]---

This warn is harmless, and can be fixed by not calling intel_crtc_disable when
the crtc is already disabled.
Reported-and-Tested-by: NJörg Otte <jrg.otte@gmail.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>