Including state readout and cross-checking. This allows us to get rid
of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy
if the BIOS hasn't set up the audio routing like we want it too.

Wrt fastboot and external screens I see a few options:
- Don't.
- Try to fix up eld, infoframes and audio settings after the fact. But
  that means some pretty extensive reworking of our code which
  currently does all this while the pipe/port is still off.

I won't bother with converting SDVO over to this because the audio
support for SDVO is very lacking:
- We don't update the eld.
- We don't update the audio state on the sdvo encoder.
- We don't check whether the platform can even feed audio to the sdvo
  encoder.

I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi
and dp converted and so doing it step-by-step would have required a
few intermediate hacks.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

At least on those platforms which have a simple bit and don't rely
on the fully programmable CSC unit to do this.

Note that with the current code this includes CHV, but I guess that
platform will match BYT.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also add state readout and cross-check support. The only invasive change
is wiring up the new flag to the ->set_infoframes callbacks.
Reviewed-by: NNaresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Patch done using the following semantic patch (thanks Daniel for the
help!)

  @@
  iterator name list_for_each_entry;
  iterator name for_each_crtc;
  struct drm_crtc * crtc;
  struct drm_device * dev;
  @@
  -list_for_each_entry(crtc,&dev->mode_config.crtc_list, head) {
  +for_each_crtc(dev,crtc) {
  	...
  }

Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Generated using the semantic patch:

  @@
  iterator name list_for_each_entry;
  iterator name for_each_intel_crtc;
  struct intel_crtc * crtc;
  struct drm_device * dev;
  @@
  -list_for_each_entry(crtc,&dev->mode_config.crtc_list,...) {
  +for_each_intel_crtc(dev,crtc) {
	...
  }

Followed by a couple of fixups by hand (that spatch doesn't match the
cases where list_for_each_entry() is not followed by a set of '{', '}',
but I couldn't figure out a way to leave the '{' out of the iterator
match).
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pipe might not start to actually run until the port has been enabled
(depends on the platform and port type). So don't try to wait for vblank
after we enabled the pipe but haven't yet enabled the port.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=77297Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already moved the plane disable/enable to happen as the first/last
thing on every other platforms. Follow suit with gmch platforms.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Frob drm_vblank_on conflict, as usual.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No CRT output on CHV, so don't call intel_crt_init().

v2: Don't disable CRT on HAS.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add chv_crtc_clock_get() to read out the DPLL settings.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Fix compile due to bikeshedded headers in an earlier patch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With additional of pipe C, current 1 bit registers for pipe select
for HDMI and DP are no longer able to gather for 3 pipes. As a result,
new bits location in the same registers are added.

For HDMI, VLV uses bit 30, CHV uses bit 24-25.

For DP, VLV uses bit 30, CHV uses bit 16-17.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Added programming PLL for CHV based on "Application note for 1273 CHV
Display phy".

v2:  -Break the common lane reset into another patch.
     -Break the clock calculation into another patch.

    -The changes are based on Ville review.
    -Rework based on DPIO register define naming convention change.
    -Break the dpio write into few lines to improve readability.
    -Correct the udelay during chv_enable_pll.
    -clean up some magic numbers with some new define.
    -program the afc recal bit which was missed.

v3: Based on Ville review
	-  minor correction of the bit defination
    - add deassert/propagate data lane reset

v4: Corrected the udelay between dclkp enable and pll enable.
	Minor comment and better way to clear the TX lane reset.

v5: Squash in fixup from Rafael Barbalho.

[vsyrjala: v6: Polish the defines (Imre)]
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Based on the chv clock limit, find the best divisor.

The divisor data has been verified with this spreadsheet.
P1273_DPLL_Programming Spreadsheet.

v2: Rebase the code and change the chv_find_best_dpll based on new
standard way to use intel_PLL_is_valid.  Besides, clean up some extra
variables.

v3: Ville suggest better fixed point for m2 calculation.

v4: -Add comment for the limit is compute using fast clock. (Ville)
	-Don't pass the request clock to chv_clock, as the same function will
	 be use clock readout, which doens't have request clock. (Ville)
	-Add and use DIV_ROUND_CLOSEST_ULL to consistent with other clock
	calculation. (Ville)
	-Fix the dp m2 after m2 has stored fixed point. (Ville)
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
[vsyrjala: Avoid div-by-zero in chv_clock()]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

During cold boot, the display controller needs to deassert the common
lane reset.  Only do it once during intel_init_dpio for both PHYx2 and
PHYx1.

Besides, assert the common lane reset when disable pll.  This still
to be determined whether need to do it by driver.
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
[vsyrjala: Don't disable DPIO PLL when using DSI]
[vsyrjala: Don't call vlv_disable_pll() by accident on CHV]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Move part of a moved comment back as suggested by Imre since
it's valid for both byt and chv.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The additional DPLL registers added to support Port D.  Besides, add
some new PHY control and status registers based on B-spec.

v2: Based on Ville review
	- Corrected DPIO_PHY_STATUS offset and name.
    - Rebase based on upstream change after introduce enum dpio_phy and
      enum dpio_channel.

v3: Rebased on top of Antti's 3-pipe prep patch. Note that the new offsets for
the DPLL registers aren't in place yet, so this introduces a slight regression.
But since 3 pipe support isn't fully enabled yet anyaway in -internal this
shouldn't matter too much.
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

CHV has 2 display phys.  First phy (IOSF offset 0x1A) has two channels,
and second phy (IOSF offset 0x12) has single channel.  The first phy is
used for port B and port C, while second phy is only for port D.

v2: Move the pipe to determine which phy to select for
vlv_dpio_read/vlv_dpio_write to another patch. (Daniel)
v3: Rebase the code based on rework on how to calculate DPIO offset.
Signed-off-by: NChon Ming Lee <chon.ming.lee@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the same code for enabling/disabling planes on all platforms. Rename
the functions to reflect that they're no longer specific to any
platform.

For now we leave the plane enable/disable to ccur at the same old
position in the modeset sequence.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Frob drm_vblank_on conflict.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We won't be calling intel_enable_primary_plane() or
intel_disable_primary_plane() with the primary plane in the
wrong state. So remove the useless DISPLAY_PLANE_ENABLE checks.

v2: Convert the checks to WARNs instead (Daniel,Paulo)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a mechanism by which we can evade the leading edge of vblank. This
guarantees that no two sprite register writes will straddle on either
side of the vblank start, and that means all the writes will be latched
together in one atomic operation.

We do the vblank evade by checking the scanline counter, and if it's too
close to the start of vblank (too close has been hardcoded to 100usec
for now), we will wait for the vblank start to pass. In order to
eliminate random delayes from the rest of the system, we operate with
interrupts disabled, except when waiting for the vblank obviously.

Note that we now go digging through pipe_to_crtc_mapping[] in the
vblank interrupt handler, which is a bit dangerous since we set up
interrupts before the crtcs. However in this case since it's the vblank
interrupt, we don't actually unmask it until some piece of code
requests it.

v2: preempt_check_resched() calls after local_irq_enable() (Jesse)
    Hook up the vblank irq stuff on BDW as well
v3: Pass intel_crtc instead of drm_crtc (Daniel)
    Warn if crtc.mutex isn't locked (Daniel)
    Add an explicit compiler barrier and document the barriers (Daniel)
    Note the irq vs. modeset setup madness in the commit message (Daniel)
v4: Use prepare_to_wait() & co. directly and eliminate vbl_received
v5: Refactor intel_pipe_handle_vblank() vs. drm_handle_vblank() (Chris)
    Check for min/max scanline <= 0 (Chris)
    Don't call intel_pipe_update_end() if start failed totally (Chris)
    Check that the vblank counters match on both sides of the critical
    section (Chris)
v6: Fix atomic update for interlaced modes
v7: Reorder code for better readability (Chris)
v8: Drop preempt_check_resched(). It's not available to modules
    anymore and isn't even needed unless we ourselves cause
    a wakeup needing reschedule while interrupts are off
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NSourab Gupta <sourabgupta@gmail.com>
Reviewed-by: NAkash Goel <akash.goels@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For a bunch of reasons we want to move away from the ->mode_set
callbacks: All hw state setup needs to move into ->enable hooks (so
that DOMS can do runtime pm) and all the configuration setup needs to
move into the compute_config functions.

To start with this make the enocer->mode_set callback optional.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The BIOS can enable a pipe but leave the primary plane disabled. This
coflicts with out current idea of primary_enabled. Read the actual
hardware plane state and set primary_enabled appropriately.

We currently assume that primary_enabled is always true when we're about
to disable a crtc. That needs to change now as the plane may not be
enabled. So replace the relevant WARNs with early returns in
intel_{enable,disable}_primary_hw_plane().

Fixes the following warning
[    3.831602] WARNING: CPU: 0 PID: 1112 at linux/drivers/gpu/drm/i915/intel_display.c:1918 intel_disable_primary_hw_plane+0xe4/0xf0 [i915]()

which got introduced here by me:
 commit e9e39655c0c30cddc3f8c09a757678a24dd36737
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Mon Apr 28 15:53:25 2014 +0300

    drm/i915: Remove useless checks from primary enable/disable
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

assert_plane_enabled() is now triggering during FDI link train because
we no longer enable planes that early.

This problem got introduced in:
 commit a5c4d7bc
 Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
 Date:   Fri Mar 7 18:32:13 2014 +0200

    drm/i915: Disable/enable planes as the first/last thing during modeset on ILK+

Just drop the assert since we shouldn't need planes for link training.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Squash in fixup for now unused plane local variable, reported
by 0-day tester.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have a struct_mutex deadlock during driver init on ILK

[   54.320273] =============================================
[   54.320371] [ INFO: possible recursive locking detected ]
[   54.320471] 3.15.0-rc2-flip_race+ #2 Not tainted
[   54.320567] ---------------------------------------------
[   54.320665] modprobe/2178 is trying to acquire lock:
[   54.320762]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0568b05>] intel_enable_gt_powersave+0xa5/0x9d0 [i915]
[   54.321111]
[   54.321111] but task is already holding lock:
[   54.321250]  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915]
[   54.321583]
[   54.321583] other info that might help us debug this:
[   54.321724]  Possible unsafe locking scenario:
[   54.321724]
[   54.321863]        CPU0
[   54.321954]        ----
[   54.322046]   lock(&dev->struct_mutex);
[   54.322221]   lock(&dev->struct_mutex);
[   54.322397]
[   54.322397]  *** DEADLOCK ***
[   54.322397]
[   54.322638]  May be due to missing lock nesting notation
[   54.322638]
[   54.322781] 4 locks held by modprobe/2178:
[   54.322875]  #0:  (&dev->mutex){......}, at: [<ffffffff813592eb>] __driver_attach+0x5b/0xb0
[   54.323230]  #1:  (&dev->mutex){......}, at: [<ffffffff813592f9>] __driver_attach+0x69/0xb0
[   54.323582]  #2:  (drm_global_mutex){+.+.+.}, at: [<ffffffffa04e1e0d>] drm_dev_register+0x2d/0x120 [drm]
[   54.323945]  #3:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa05b4c2e>] intel_modeset_init_hw+0x3e/0x60 [i915]

This regression got introduced in:
 commit 586d5270b60dc1f35cc3ca982d403765bad77965
 Author: Imre Deak <imre.deak@intel.com>
 Date:   Mon Apr 14 20:24:28 2014 +0300

    drm/i915: move getting struct_mutex lower in the callstack during GPU reset

Fix the problem by not taking struct_mutex around intel_enable_gt_powersave()
in intel_modeset_init_hw() since intel_enable_gt_powersave() now grabs the
mutex itself.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to re-init sizzling on all platforms so move it to the
platform independent runtime resume callback. The ring frequency reinit
is also needed everywhere except on VLV, but gen6_update_ring_freq()
will be a noop on VLV, so we can move this function too to platform
independent code.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.

No functional change.

v2:
- patch introduce in v2 of the patchset
v3:
- simplify platform check condition (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to disable the interrupts for all platforms, so make the helpers
for this platform independent and call them from them platform
independent runtime suspend/resume callbacks.

On HSW/BDW this will move interrupt disabling/re-enabling at the
beginning/end of runtime suspend/resume respectively, but I don't see
any reason why this would cause a problem there. In any case this seems
to be the correct thing to do even on those platforms.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.

The move also revealed that we actually don't include this register in
the error report, so fix that too.

v2:
- patch introduced in v2 of the patchset
v3:
- add back !HAS_PCH_SPLIT check (Ville)
[ Ignore my previous comment about the gen<=5 || vlv check, I realized
  that it's the same as !HAS_PCH_SPLIT. ]
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... our current modeset code isn't good enough yet to handle this. The
scenario is:

1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.

2. We read out that state for pipe B and assign the gmch_pfit state to
it.

3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.

-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081Tested-by: Nmax <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The pipe is off at that point in time, so a vblank wait is simply a
50ms wait. Caught by Jesse's verbose "make vblank wait timeouts WARN"
patch. We've probably had a few versions of this float around already.

To document assumptions put a pipe assert into the same place. And
also add a posting read.

If we ever decide to update the eld and infoframes while the pipe is
already on (e.g. for fastboot) then there's lots of work to do. So
better properly document all the hidden assumptions.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already do this for HSW, but doing it makes sense for everything else
as well. Extend it for ILK/SNB/IVB since that's where the new watermark
code is used.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297
[danvet: Resolve conflict since I've plucked this out of the middle of
Ville's series.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Like on hsw/bdw the pipe isn't actually running yet at this point.
This holds for both pch ports and the cpu edp port according to my
testing on ilk, snb and ivb.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a requirement added to the spec. This patch will prevent
persistent corruption on the display.

v2: Make the wait before the vblank wait. (Art)
Try to finish early by polling the register
s/present/prevent (Chris)

Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Upgrade debug output to ERROR.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

haswell_write_eld() is also used on broadwell, so let's not explicitely
mention Haswell. The rest of the function has plenty of debug output
which will print the function name, so we know where we are anyway.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Comment from Ben: It's a bit unclear whether we need this dance still
on bdw.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This always indicates a bug somewhere.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's no point in hiding the DP M/N setup in the update_pll functions.
Just move it to the mode_set function.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because if we keep the current code, we'll get tons of WARNs on
Broadwell, since the code is Haswell-specific.

We could have also added a Broadwell-specific code there, but it's not
really needed since we never disable LCPLL with the hotplug interrupts
still enabled. So keep the easy-and-simple-to-maintain solution until
we actually need something else.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that CRTC's have a primary plane, there's no need to track the
framebuffer in the CRTC.  Replace all references to the CRTC fb with the
primary plane's fb.

This patch was generated by the Coccinelle semantic patching tool using
the following rules:

        @@ struct drm_crtc C; @@
        -   (C).fb
        +   C.primary->fb

        @@ struct drm_crtc *C; @@
        -   (C)->fb
        +   C->primary->fb

v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
    moved to a subsequent patch.

v2: Fixup several lingering crtc->fb instances that were missed in the
    first patch iteration.  [Rob Clark]
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Ensure that existing driver loops over all planes do not change behavior
when we begin adding new types of planes (primary and cursor) to the DRM
plane list in future patches.

v2: Switch to using drm_for_each_legacy_plane()

Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>

That's what the spec said! And HSW needs it through pcode (you can
only read it through MCHBAR), so create hsw_write_dcomp to abstract
the weirdness.
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>

Now that PC8 is part of runtime PM, the check is useless.
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>