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>

Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.

The code is shared with atomic_begin/flush, except watermark updating
and vblank evasion are not used.

This is needed for proper atomic suspend/resume support.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868Signed-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>

Read out the initial state, and add a quirk to force add all planes
to crtc_state->plane_mask during initial commit. This will disable
all planes during the initial modeset.

The initial plane quirk is temporary, and will go away when hardware
readout is fully atomic, and the watermark updates in intel_sprite.c
are removed.

Changes since v1:
- Unset state->visible on !primary planes.
- Do not rely on the plane->crtc pointer in intel_atomic_plane,
  instead assume planes are invisible until modeset.
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>

All the checks in intel_modeset_checks are only useful when a modeset
occurs, because there is nothing to update otherwise.

Same for power/cdclk changes, if there is no modeset they are noops.

Unfortunately intel_modeset_pipe_config still gets called without
modeset, because atomic hw readout isn't done yet.
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>

To allow them to be used in intel_set_mode.
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>

This is probably intended to be be done during vblank evasion.
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>

The idea was good, but planes can have a fb even though
they're disabled. This makes the force argument useless
and always true, because only the commit function updates
state.
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>

By passing crtc_state to the check_plane functions a lot of duplicated
code can be removed. There are still some transitional helper calls,
they will be removed later.

Changes since v1:
- Revert state->visible changes.
- Use plane->state->crtc instead of plane->crtc.
- Use drm_atomic_get_existing_crtc_state.
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>

No point in hiding behind big ifs. This will be true most of the time.
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>

This makes it easier to verify that no changes are done when
calling this from crtc instead.

Changes since v1:
 - Make intel_wm_need_update static and always check it.
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>

commit 2c310b9d2859863826c3688c88218d607d5dd19a
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon May 18 12:28:52 2015 +0200

drm/i915: Split skl_update_scaler, v4.

It's easier to read separate functions for crtc and plane scaler state.

Changes since v1:
 - Update documentation.
Changes since v2:
 - Get rid of parameters to skl_update_scaler only used for traces.
   This avoids needing to document the other parameters.
Changes since v3:
 - Rename scaler_idx to scaler_user.
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>

It saves another loop over all crtc's in the state, and computing
clock is more of a per crtc thing.
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>

The scaler setup may add planes, but since they're unchanged we only
have to wait for primary flips. Also set planes_changed to indicate
at least 1 plane is modified.

Changes since v1:
- Instead of removing planes, do minimal validation needed.
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>

Move the check for encoder cloning here.

Changes since v1:
- Remove was/is crtc_disabled. (mattrope)
- Rename function to intel_crtc_atomic_check. (mattrope)
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>

Get rid of a whole lot of ternary operators and assign the index
in scaler_id, instead of the id. They're the same thing.
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>

Grabbing crtc state from atomic state is a lot more involved,
and make sure connectors are added before calling this function.

Move check_digital_port_conflicts to intel_modeset_checks,
it's only useful to check it on a modeset.
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>

We need to call drm_atomic_set_mode_for_crtc() rather than copying the
mode in manually.  As of commit

        commit 99cf4a29
        Author: Daniel Stone <daniels@collabora.com>
        Date:   Mon May 25 19:11:51 2015 +0100

            drm/atomic: Add current-mode blob to CRTC state

the helper now also takes care of setting up the mode property blob for
us; if we don't use the helper and never setup the mode blob, this will
also trigger a failure in drm_atomic_crtc_check() when we have the
DRIVER_ATOMIC flag set (i.e., when using the nuclear pageflip support
via i915.nuclear_pageflip kernel command line parameter).

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

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>

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>

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>

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>

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>

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>

This is a small behavioral change because it leaves DVO_2X_MODE
set between crtc_disable and crtc_enable. This is probably harmless
though and if not should be fixed by calculating 2x mode before
enable/disable pll.

This is needed because intel_crtc->active will be removed eventually.
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>

This needs to be done last after all modesets have been calculated.

A modeset first disables all crtc's, so any crtc that undergoes a
modeset counts as inactive.

If no modeset's done, or > 1 crtc's stay w/a doesn't apply.
Apply workaround on the first crtc if 1 crtc stays active.
Apply workaround on the second crtc if no crtc was active.

Changes since v1:
 - Use intel_crtc->atomic as a place to put hsw_workaround_pipe.
 - Make sure quirk only applies to haswell.
 - Use first loop to iterate over newly enabled crtc's only.
   This increases readability.
Changes since v2:
 - Move hsw_workaround_pipe back to crtc_state.
Changes since v3:
 - Return errors from haswell_mode_set_planes_workaround.
Changes since v4:
- Clean up commit message.
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>

intel_crtc->config will be removed eventually, so use crtc->hwmode.
drm_atomic_helper_update_legacy_modeset_state updates hwmode,
but crtc->active will eventually be gone too. Set dotclock to zero
to indicate the crtc is inactive.

Changes since v1:
- With the hwmode update in drm*update_legacy_modeset_state removed,
  intel_modeset_update_state has to assign it instead.
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>

This is a preparation for passing crtc state to the helpers.
When converting all users of crtc->config to use the old or
new state it's easier to find regressions when swap_state is
done first.

If crtc->config is swapped at the same place as swap_state
bugs will never be found.
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>

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.

Calling intel_set_mode will cause intel_display_set_init_power to be
called, make sure init_power gets set again afterwards.

Changes since v1:
- Fix to compile with v2 of the patch that adds intel_display_suspend.
- Add intel_display_set_init_power.
- Set return value to int to allow error checking.
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>

Assume the callers lock everything with drm_modeset_lock_all.

This change had to be done after converting suspend/resume to
use atomic_state so the atomic state is preserved, otherwise
all transitional state is erased.

Now all callers of .crtc_enable and .crtc_disable go through
atomic modeset! :-D

Changes since v1:
- Only check for crtc_state->active in valleyview_modeset_global_pipes.
- Only check for crtc_state->active in modeset_update_crtc_power_domains.
Changes since v2:
- Rework on top of the changed patch order.
Changes since v3:
- Rename intel_crtc_toggle in description to *_control
- Change return value to int.
- Do not add plane state, should be done implicitly already.
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>

To make this work we load the new hardware state into the
atomic_state, then swap it with the sw state.

This lets us change the force restore path in setup_hw_state()
to use a single call to intel_mode_set() to restore all the
previous state.

As a nice bonus this kills off encoder->new_encoder,
connector->new_enabled and crtc->new_enabled. They were used only
to restore the state after a modeset.

Changes since v1:
- Make sure all possible planes are added with their crtc set,
  so they will be turned off on first modeset.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
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>

It makes more sense there, since these are computation steps that can
fail.

Changes since v1:
- Rename __intel_set_mode_checks to intel_modeset_checks (Matt Roper)
- Move intel_modeset_checks to before check_planes, so it won't
  have to be moved later.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
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>

Repeated calls to begin_crtc_commit can cause warnings like this:
[  169.127746] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616
[  169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
[  169.127840] 3 locks held by kms_flip/1947:
[  169.127843]  #0:  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff814774bc>] __drm_modeset_lock_all+0x9c/0x130
[  169.127860]  #1:  (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffff814774cd>] __drm_modeset_lock_all+0xad/0x130
[  169.127870]  #2:  (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffff81477178>] drm_modeset_lock+0x38/0x110
[  169.127879] irq event stamp: 665690
[  169.127882] hardirqs last  enabled at (665689): [<ffffffff817ffdb5>] _raw_spin_unlock_irqrestore+0x55/0x70
[  169.127889] hardirqs last disabled at (665690): [<ffffffffc0197a23>] intel_pipe_update_start+0x113/0x5c0 [i915]
[  169.127936] softirqs last  enabled at (665470): [<ffffffff8108a766>] __do_softirq+0x236/0x650
[  169.127942] softirqs last disabled at (665465): [<ffffffff8108ae75>] irq_exit+0xc5/0xd0
[  169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+ #4039
[  169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014
[  169.127957]  ffff8800c49036f0 ffff8800cde5fa28 ffffffff817f6907 0000000080000001
[  169.127964]  0000000000000000 ffff8800cde5fa58 ffffffff810aebed 0000000000000046
[  169.127970]  ffffffff81c5d518 0000000000000268 0000000000000000 ffff8800cde5fa88
[  169.127981] Call Trace:
[  169.127992]  [<ffffffff817f6907>] dump_stack+0x4f/0x7b
[  169.128001]  [<ffffffff810aebed>] ___might_sleep+0x16d/0x270
[  169.128008]  [<ffffffff810aed38>] __might_sleep+0x48/0x90
[  169.128017]  [<ffffffff817fc359>] mutex_lock_nested+0x29/0x410
[  169.128073]  [<ffffffffc01635f0>] ? vgpu_write64+0x220/0x220 [i915]
[  169.128138]  [<ffffffffc017fddf>] ? ironlake_update_primary_plane+0x2ff/0x410 [i915]
[  169.128198]  [<ffffffffc0190e75>] intel_frontbuffer_flush+0x25/0x70 [i915]
[  169.128253]  [<ffffffffc01831ac>] intel_finish_crtc_commit+0x4c/0x180 [i915]
[  169.128279]  [<ffffffffc00784ac>] drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper]
[  169.128338]  [<ffffffffc0184264>] __intel_set_mode+0x684/0x830 [i915]
[  169.128378]  [<ffffffffc018a84a>] intel_crtc_set_config+0x49a/0x620 [i915]
[  169.128385]  [<ffffffff817fdd39>] ? mutex_unlock+0x9/0x10
[  169.128391]  [<ffffffff81467b69>] drm_mode_set_config_internal+0x69/0x120
[  169.128398]  [<ffffffff8119b547>] ? might_fault+0x57/0xb0
[  169.128403]  [<ffffffff8146bf93>] drm_mode_setcrtc+0x253/0x620
[  169.128409]  [<ffffffff8145c600>] drm_ioctl+0x1a0/0x6a0
[  169.128415]  [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50
[  169.128424]  [<ffffffff811e9ab8>] do_vfs_ioctl+0x2f8/0x530
[  169.128429]  [<ffffffff810d0fcd>] ? trace_hardirqs_on+0xd/0x10
[  169.128435]  [<ffffffff812e7676>] ? selinux_file_ioctl+0x56/0x100
[  169.128439]  [<ffffffff811e9d71>] SyS_ioctl+0x81/0xa0
[  169.128445]  [<ffffffff81800697>] system_call_fastpath+0x12/0x6f

Solve it by using the newly introduced drm_atomic_helper_commit_planes_on_crtc.

The problem here was that the drm_atomic_helper_commit_planes() helper
we were using was basically designed to do

    begin_crtc_commit(crtc #1)
    begin_crtc_commit(crtc #2)
    ...
    commit all planes
    finish_crtc_commit(crtc #1)
    finish_crtc_commit(crtc #2)

The problem here is that since our hardware relies on vblank evasion,
our CRTC 'begin' function waits until we're out of the danger zone in
which register writes might wind up straddling the vblank, then disables
interrupts; our 'finish' function re-enables interrupts after the
registers have been written.  The expectation is that the operations between
'begin' and 'end' must be performed without sleeping (since interrupts
are disabled) and should happen as quickly as possible.  By clumping all
of the 'begin' calls together, we introducing a couple problems:
 * Subsequent 'begin' invocations might sleep (which is illegal)
 * The first 'begin' ensured that we were far enough from the vblank that
   we could write our registers safely and ensure they all fell within
   the same frame.  Adding extra delay waiting for subsequent CRTC's
   wasn't accounted for and could put us back into the 'danger zone' for
   CRTC #1.

This commit solves the problem by using a new helper that allows an
order of operations like:

   for each crtc {
        begin_crtc_commit(crtc)  // sleep (maybe), then disable interrupts
        commit planes for this specific CRTC
        end_crtc_commit(crtc)    // reenable interrupts
   }

so that sleeps will only be performed while interrupts are enabled and
we can be sure that registers for a CRTC will be written immediately
once we know we're in the safe zone.

The crtc->config->base.crtc update may seem unrelated, but the helper
will use it to obtain the crtc for the state. Without the update it
will dereference NULL and crash.

Changes since v1:
- Use Matt Roper's commit message.
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>