Leftover from the big purge

commit a5611654
Author: John Harrison <John.C.Harrison@Intel.com>
Date:   Thu Mar 5 14:03:03 2015 +0000

    drm/i915: Remove ironlake rc6 support

Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Reported-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Limit CHV maximum cdclk to 320MHz.

v2: Rebase to the latest
v3: Clean up of if-else tree
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This commit is just to make the intentions explicit: on HSW+ these
bits are MBZ, but since we only support plane A and the macro
evaluates to zero when plane A is the parameter, we're not fixing any
bug.

v2:
 - Remove useless extra blank like (Chris).
 - Init dpfc_ctl in another place (Chris).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This commit has two main advantages: simplify intel_fbc_update()
and deduplicate the strings.

v2:
 - Rebase due to changes on P1.
 - set_no_fbc_reason() can now return void (Chris).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because we're currently using FBC_UNSUPPORTED_MODE for two different
cases.

This commit will also allow us to write the next one without hiding
information from the user.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already had a few bugs in the past where FBC was compressing
nothing when it was enabled, which makes the feature quite useless.
Add this information to debugfs so the test suites can check for
regressions in this piece of the code.

Our igt/tests/kms_frontbuffer_tracking already has support for this
message.

v2: - Remove pointless VLV check (Ville).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The docs don't support the 64k linear scanout alignment we impose
on gen2/3. And it really makes no sense since we have no DSPSURF
register, so the only thing that the hardware will see is the linear
offset which will be just pixel aligned anyway.

There is one case where 64k comes into the picture, and that's FBC.
The start of the line length buffer corresponds to a 64k aligned
address of the uncompressed framebuffer. So if the uncompressed fb is
not 64k aligned, the first actually used entry in the line length
buffer will not be byte 0. There are 32 extra entries in the line
length buffer to account for this extra alignment so we shouldn't
have to worry about it when mapping the uncompressed fb to the GTT.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV/CHV have problems with 4k aligned linear scanout buffers. The VLV
docs got updated at some point to say that we need to align them to
128k, just like we do on gen4.

So far I've seen the problem manifest when the stride is an odd multiple
of 512 bytes, and the surface address meets the following pattern
'(addr & 0xf000) == 0x1000' (also == 0x2000 is problematic on VLV). The
result is a starcase effect (so some pages get dropped maybe?), with a
few pages here and there clearly getting scannout out at the wrong position.

I've not actually been able to reproduce this problem on gen4, so it's
not clear of the issue is any way related to the 128k restrictions
supposedly inherited from gen4. But let's hope the 128k alignment is
sufficient to hide it all.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: NArun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently intel_gen4_compute_page_offset() simply picks the closest
page boundary below the linear offset. That however may not be suitably
aligned to satisfy any hardware specific restrictions. So let's make
sure the page boundary we choose is properly aligned.

Also to play it a bit safer lets split the remaining linear offset into
x and y values instead of just x. This should make no difference for
most platforms since we convert the x and y offsets back into a linear
offset before feeding them to the hardware. HSW+ are different however
and use x and y offsets even with linear buffers, so they might have
trouble if either the x or y get too big.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Delete the duplicate #defines introduced by:

	commit 6b457d31
	Author: A.Sunil Kamath <sunil.kamath@intel.com>
	Date:   Thu Apr 16 14:22:09 2015 +0530

		drm/i915/skl: Implement enable/disable for Display C5 state.
Signed-off-by: NChandra Konduru <chandra.konduru@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Corrected the documentation on the intel_edp_drrs_flush and
intel_edp_drrs_invalidate.

And accordingly edp_drrs_flush function is modified to restart the idleness
detection after upclocking.

v2: Update kerneldoc

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v1)
Signed-off-by: NRamalingam C <ramalingam.c@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In igt, we want to test handling of GPU hangs, both for recovery
purposes and for reporting. However, we don't want to inject a genuine
GPU hang onto a machine that cannot recover and so be permenantly
wedged. Rather than embed heuristics into igt, have the kernel report
exactly when it expects the GPU reset to work.

This can also be usefully extended in future to indicate different
levels of fine-grained resets.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tim Gore <tim.gore@intel.com>
Cc: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_runtime_pm_status’:
drivers/gpu/drm/i915/i915_debugfs.c:2528:34: error: ‘struct dev_pm_info’ has no member named ‘usage_count’
      atomic_read(&dev->dev->power.usage_count));

Regression from commit a6aaec8b
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Thu Jun 4 18:23:58 2015 +0100

    drm/i915: Add runtime PM's usage_count in i915_runtime_pm_status
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I noticed one of those and it turned out we have a few lingering around.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's handy to have debug message for the "big" events and this one
qualifies IMHO. Also helpful to see what's happening while we're loading
the firwmare and how much time it takes.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In Linux, macros are usually well done and protect their arguments
properly, even avoiding multiple evaluations of the parameters. Extra ()
are really not needed.

Cc: Suketu Shah <suketu.j.shah@intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be
set because of security-sensitive bits we don't want userspace to mess
with.  On HSW hardware the whitelisted bits control whether atomic
read-modify-write operations are performed on L3 or on GTI, and when
set to L3 (which can be 10x-30x better performing than on GTI,
depending on the application) require great care to avoid a system
hang, so we currently program them to be handled on GTI by default.

Beignet can immediately start taking advantage of this change to
enable L3 atomics.  Mesa should eventually switch to L3 atomics too,
but a number of non-trivial changes are still required so it will
continue using GTI atomics for now.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Reviewed-by: NZhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In some cases it might be unnecessary or dangerous to give userspace
the right to write arbitrary values to some register, even though it
might be desirable to give it control of some of its bits.  This patch
extends the register whitelist entries to contain a mask/value pair in
addition to the register offset.  For registers with non-zero mask,
any LRM writes and LRI writes where the bits of the immediate given by
the mask don't match the specified value will be rejected.

This will be used in my next patch to grant userspace partial write
access to some sensitive registers.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Reviewed-by: NZhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Until now the software command checker assumed that commands could
read or write at most a single register per packet.  This is not
necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length
list of offset/value pairs and writes them in sequence.  The previous
code would only check whether the first entry was valid, effectively
allowing userspace to write unrestricted registers of the MMIO space
by sending a multi-register write with a legal first register, with
potential security implications on Gen6 and 7 hardware.

Fix it by extending the drm_i915_cmd_descriptor table to represent
multi-register access and making validate_cmd() iterate for all
register offsets present in the command packet.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Reviewed-by: NZhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Switch from using 31 PFI credits to 63 PFI credits when cdclk>=czclk on
CHV. The spec lists both 31 and 63 as "suggested" values, but based on
feedback from hardware folks we should actually be using 63. Originally
I picked the 31 basically by flipping a coin.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch fixes the resume from suspend-to-ram on the IBM X30
laptop. The problem is caused by the Bios missing to re-initialize
the iVCH registers, especially the PLL registers.

This patch records the iVCH registers during initialization, and
re-installs this register set when resuming.
Signed-off-by: NThomas Richter <thor@math.tu-berlin.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We are always allocating a single page. No need to be verbose so
remove the suffix.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Free the scratch page if dma mapping fails.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The divider value to convert from CZ clock rate to ms needs a +1
adjustment on VLV just like on CHV. This matches both the spec and
the accuracy test by pm_rc6_residency.

v2:
- simplify logic checking for the CHV 320MHz special case (Rodrigo)

Testcase: igt/pm_rc6_residency
Signed-off-by: NImre Deak <imre.deak@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76877Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we're forgetting to double the port clock when using double
clocked modes with 12bpc on HDMI. We're only accounting for the 1.5x
factor due to the 12bpc. So further double the 1.5x port clock when we
have a double clocked mode.

Unfortunately I don't have any displays that support both 12bpc and
double clocked modes, so I was unable to test this.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Account for the pixel multiplier when reading out the HDMI
mode dotclock. Makes the state checked happier on my ILK when using
double clocked modes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Check that the DIP is enabled on the right port on IBX and VLV/CHV as
we're doing on g4x, and also check for all the infoframe enable bits on
all platforms.

Eventually we should track each infoframe type independently, and also
their contents. This is a small step in that direction as .infoframe_enabled()
return value could be easily turned into a bitmask.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently we just disable the GCP infoframe when turning off the port.
That means if the same transcoder is used on a DP port next, we might
end up pushing infoframes over DP, which isn't intended. Just disable
all the infoframes when turning off the port.

Also protect against two ports stomping on each other on g4x due to
the single video DIP instance. Now only the first port to enable
gets to send infoframes.

v2: Rebase
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Follow the procedure listed in Bspec to toggle the port enable bit off
and on when enabling HDMI with 12bpc and pixel repeat on IBX. The old
code didn't actually enable the port before "toggling" the bit back off,
so the whole workaround was essentially a nop.

Also take the opportunity to clarify the code by splitting the gmch
platforms to a separate (much more straightforward) function.

v2: Rebased due to crtc->config changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

IBX BSpec says we must specify 8bpc in TRANSCONF for both 8bpc
and 12bpc HDMI output. Do so.

v2: Pass intel_crtc to intel_pipe_has_type()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When the video timings are suitably aligned so that all different
periods start at phase 0 (ie. none of the periods start mid-pixel)
we can inform the sink about this. Supposedly the sink can then
optimize certain things. Obviously this is only relevant when
outputting >8bpc data since otherwise there are no mid-pixel phases.

v2: Rebased due to crtc->config changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

GCP infoframes are required to inform the HDMI sink about the color
depth.

Send the GCP infoframe whenever the sink supports any deep color modes
since such sinks must anyway be capable of receiving them. For sinks
that don't support deep color let's skip the GCP in case it might
confuse the sink, although HDMI 1.4 spec does say all sinks must be
capable of reciving them. In theory we could skip the GCP infoframe
for deep color sinks in 8bpc mode as well since sinks must fall back to
8bpc whenever GCP isn't received for some time.

BSpec says we should disable GCP after disabling the port, so do that as
well.

v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
    Rebased due to crtc->config changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict with lack of chv phy patches and fixup typo
Chandra spotted.]
Reviewed-by: NChandra Konduru <Chandra.konduru@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

CPT/PPT require a specific procedure for enabling 12bpc HDMI. Implement
it, and to keep things neat pull the code into a function.

v2: Rebased due to crtc->config changes
    s/HDMI_GC/HDMIUNIT_GC/ to match spec better
    Factor out intel_enable_hdmi_audio()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-By: NChandra Konduru <Chandra.konduru@intel.com>
Testecase: igt/kms_render/*
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The cursor should only be enabled if it's visible. This fixes
igt/kms_cursor_crc, which may otherwise produce the following
warning:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 3425 at drivers/gpu/drm/i915/intel_display.c:9995 intel_crtc_update_cursor+0x14c/0x4d0 [i915]()
Missing switch case (0) in i9xx_update_cursor
Modules linked in: i915
CPU: 0 PID: 3425 Comm: kms_cursor_crc Tainted: G        W       4.1.0-rc7-patser+ #4079
Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
 ffffffffc01aad10 ffff8800b083faa8 ffffffff817f7827 0000000080000001
 ffff8800b083faf8 ffff8800b083fae8 ffffffff81084955 ffff8800b083fad8
 ffff8800c4931148 0000000001200000 ffff8800c48b0000 0000000000000000
Call Trace:
 [<ffffffff817f7827>] dump_stack+0x4f/0x7b
 [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0
 [<ffffffff810849d1>] warn_slowpath_fmt+0x41/0x50
 [<ffffffffc0139f2c>] intel_crtc_update_cursor+0x14c/0x4d0 [i915]
 [<ffffffffc01497f4>] __intel_set_mode+0x6c4/0x750 [i915]
 [<ffffffffc0150143>] intel_crtc_set_config+0x473/0x5c0 [i915]
 [<ffffffff81467da9>] drm_mode_set_config_internal+0x69/0x120
 [<ffffffff8146c1b9>] drm_mode_setcrtc+0x189/0x540
 [<ffffffff8145c7e0>] drm_ioctl+0x1a0/0x6a0
 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
 [<ffffffff811e9c28>] do_vfs_ioctl+0x2f8/0x530
 [<ffffffff810d0f7d>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff812e7746>] ? selinux_file_ioctl+0x56/0x100
 [<ffffffff811e9ee1>] SyS_ioctl+0x81/0xa0
 [<ffffffff81801617>] system_call_fastpath+0x12/0x6f
---[ end trace abf0f71163290a96 ]---
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This was introduced after converting hw readout to atomic,
so it should have been part of the revert too.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Use a full atomic call instead. intel_crtc_page_flip will still
have to live until async updates are allowed.

This doesn't seem to be a regression from the convert to atomic,
part 3 patch. During GPU reset it fixes the following warning:

 ------------[ cut here ]------------
WARNING: CPU: 0 PID: 752 at drivers/gpu/drm/drm_crtc.c:5337 drm_mode_page_flip_ioctl+0x27b/0x360()
Modules linked in: i915
CPU: 0 PID: 752 Comm: Xorg Not tainted 4.1.0-rc7-patser+ #4090
Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
 ffffffff81c90866 ffff8800d87c3ca8 ffffffff817f7d87 0000000080000001
 0000000000000000 ffff8800d87c3ce8 ffffffff81084955 ffff880000000000
 ffff8800d87c3dc0 ffff8800d93d1208 0000000000000000 ffff8800b7d1f3e0
Call Trace:
 [<ffffffff817f7d87>] dump_stack+0x4f/0x7b
 [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0
 [<ffffffff81084a35>] warn_slowpath_null+0x15/0x20
 [<ffffffff8146dffb>] drm_mode_page_flip_ioctl+0x27b/0x360
 [<ffffffff8145ccb0>] drm_ioctl+0x1a0/0x6a0
 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
 [<ffffffff812e5540>] ? avc_has_perm+0x20/0x280
 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
 [<ffffffff811ea0f8>] do_vfs_ioctl+0x2f8/0x530
 [<ffffffff811f6001>] ? expand_files+0x261/0x270
 [<ffffffff812e7c16>] ? selinux_file_ioctl+0x56/0x100
 [<ffffffff811ea3b1>] SyS_ioctl+0x81/0xa0
 [<ffffffff81801b97>] system_call_fastpath+0x12/0x6f
---[ end trace 9ce834560085bd64 ]---
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This should fix fallout caused by making intel_crtc_control
and update_dpms atomic, which became a problem after reverting the
atomic hw readout patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit 3bae26eb2991c00670df377cf6c3bc2b0577e82a.

Seems it introduces regressions for 3 different reasons, oh boy..

In bug #90868 as I can see the atomic state will be restored on
resume without the planes being set up properly. Because plane
setup here requires the atomic state, we'll have to settle
for committing atomic planes first.

In bug #90861 the failure appears to affect mostly DP devices,
and happens because reading out the atomic state prevents a modeset
on boot, which would require better hw state readout.

In bug #90874 it's shown that cdclk should be part of the atomic
state, so only performing a single modeset during resume excarbated
the issue.

It's better to fix those issues first, and then commit this patch,
so do that temporarily.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90874Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit 490f400db5d886fc28566af69b02f6497f31be4b.

We're not ready yet to make it atomic, we calculate some state in
advance, but without atomic plane support atomic the hw readout will
fail.

It's required to revert this commit to revert the atomic hw
state readout patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

crtc->active will be gone eventually, and this check should be just as good.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>