If an atomic update fails intel_crtc->atomic may have have some values left
from the last atomic check. One example is atomic->wait_for_vblank,
which results in spurious errors in kms_flip.

[ 1551.892708] ------------[ cut here ]------------
[ 1551.892721] WARNING: CPU: 3 PID: 4179 at ../drivers/gpu/drm/drm_irq.c:1199 drm_wait_one_vblank+0x197/0x1a0 [drm]()
[ 1551.892722] vblank not available on crtc 2, ret=-22
[ 1551.892751] Modules linked in: snd_hda_intel i915 drm_kms_helper drm
intel_gtt i2c_algo_bit cfbfillrect syscopyarea cfbimgblt sysfillrect
sysimgblt fb_sys_fops cfbcopyarea agpgart cfg80211 binfmt_misc
snd_hda_codec_hdmi intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp
kvm_intel snd_hda_codec_realtek kvm snd_hda_codec_generic iTCO_wdt
aesni_intel aes_x86_64 glue_helper lrw snd_hda_codec gf128mul
ablk_helper cryptd snd_hwdep psmouse snd_hda_core pcspkr snd_pcm
snd_timer snd lpc_ich i2c_i801 mfd_core soundcore wmi evdev [last
unloaded: drm]
[ 1551.892753] CPU: 3 PID: 4179 Comm: kms_pipe_crc_ba Tainted: G     U  W       4.3.0-reg+ #6
[ 1551.892754] Hardware name:                  /DZ77BH-55K, BIOS BHZ7710H.86A.0100.2013.0517.0942 05/17/2013
[ 1551.892758]  ffffffffa03128d8 ffff8800cec73890 ffffffff812c0f3c ffff8800cec738d8
[ 1551.892760]  ffff8800cec738c8 ffffffff8104ff36 ffff880116ae2290 0000000000000002
[ 1551.892762]  ffff8800d39fcda0 ffff8800d038b4d0 ffff8800d42b5550 ffff8800cec73928
[ 1551.892763] Call Trace:
[ 1551.892768]  [<ffffffff812c0f3c>] dump_stack+0x4e/0x82
[ 1551.892771]  [<ffffffff8104ff36>] warn_slowpath_common+0x86/0xc0
[ 1551.892773]  [<ffffffff8104ffbc>] warn_slowpath_fmt+0x4c/0x50
[ 1551.892781]  [<ffffffffa02e6708>] ? drm_vblank_get+0x78/0xd0 [drm]
[ 1551.892787]  [<ffffffffa02e6d47>] drm_wait_one_vblank+0x197/0x1a0 [drm]
[ 1551.892813]  [<ffffffffa03d052f>] intel_post_plane_update+0xef/0x120 [i915]
[ 1551.892832]  [<ffffffffa03d11d2>] intel_atomic_commit+0x4c2/0x1600 [i915]
[ 1551.892862]  [<ffffffffa02ff0c7>] ? drm_atomic_check_only+0x147/0x5e0 [drm]
[ 1551.892872]  [<ffffffffa02feeb7>] ? drm_atomic_add_affected_connectors+0x27/0xf0 [drm]
[ 1551.892881]  [<ffffffffa02ff597>] drm_atomic_commit+0x37/0x60 [drm]
[ 1551.892887]  [<ffffffffa034301a>] restore_fbdev_mode+0x28a/0x2c0 [drm_kms_helper]
[ 1551.892895]  [<ffffffffa0345253>] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]
[ 1551.892900]  [<ffffffffa03452cd>] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
[ 1551.892920]  [<ffffffffa03e7a9a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[ 1551.892923]  [<ffffffff8131a5a7>] fb_set_var+0x1a7/0x3f0
[ 1551.892927]  [<ffffffff8109732f>] ? trace_hardirqs_on_caller+0x12f/0x1c0
[ 1551.892931]  [<ffffffff81314f32>] fbcon_blank+0x212/0x2f0
[ 1551.892935]  [<ffffffff81373f4a>] do_unblank_screen+0xba/0x1d0
[ 1551.892937]  [<ffffffff8136b725>] vt_ioctl+0x13d5/0x1450
[ 1551.892940]  [<ffffffff8107cdd1>] ? preempt_count_sub+0x41/0x50
[ 1551.892943]  [<ffffffff8135d8a3>] tty_ioctl+0x423/0xe30
[ 1551.892947]  [<ffffffff8119f721>] do_vfs_ioctl+0x301/0x560
[ 1551.892949]  [<ffffffff8119b1e3>] ? putname+0x53/0x60
[ 1551.892952]  [<ffffffff811ab376>] ? __fget_light+0x66/0x90
[ 1551.892955]  [<ffffffff8119f9f9>] SyS_ioctl+0x79/0x90
[ 1551.892958]  [<ffffffff81552e97>] entry_SYSCALL_64_fastpath+0x12/0x6f
[ 1551.892961] ---[ end trace 3e764d4b6628c91c ]---

Testcase: kms_flip
Reported-and-tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org #v4.3
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/5649C2BA.6080300@mblankhorst.nl

Unsurprisingly macbooks have backlights, just the VBT doesn't seem to
know it in this case.
Reported-and-tested-by: NDaniel Nicoletti <dantti12@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88325
Fixes: c675949e ("drm/i915: do not setup backlight if not available according to VBT")
Cc: stable@vger.kernel.org # v3.15+
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446716999-1796-1-git-send-email-jani.nikula@intel.com

Let's set crtc_y to 0 instead of setting src_y twice.

Multiple assignments in one statement is a good way to hide bugs.
Please don't do that.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: be5651f2 ("drm/i915: Update missing properties in find_initial_plane_obj")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447434973-12369-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.

v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).

v3:
Pin and unpin a fence only if the current view type is normal.

v4:
Extend the "view type is normal" check for pin_fence as well.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NVivek Kasireddy <vivek.kasireddy@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446170078-20792-1-git-send-email-vivek.kasireddy@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>

Reported-by: NKeith Webb <khwebb@gmail.com>
Suggested-by: NKeith Webb <khwebb@gmail.com>
Cc: stable@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106671Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446209424-28801-1-git-send-email-jani.nikula@intel.com

Extend this to SKL and BXT as it's needed for these platforms as well.

v2: Change if condition to HAS_DDI() instead of listing each platform
Signed-off-by: NBob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes the warnings like

"plane A assertion failure, should be disabled but not"

that on the initial modeset during boot. This can happen if
the primary plane is enabled by the firmware, but inheriting
it fails because the DMAR is active or for other reasons.

Most likely caused by

commit 36750f28
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Jun 1 12:49:54 2015 +0200

    drm/i915: update plane state during init

This is a new version of

commit 721a09f7
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Tue Sep 15 14:28:54 2015 +0200

    drm/i915: Add primary plane to mask if it's visible

That was reverted in order to facilitate easier backporting of some
commits from -next to v4.3.
Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429Reported-and-tested-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc()
where it belongs instead of doing it in intel_modeset_readout_hw_state().

The plane disabling was first added in
4cf0ebbd drm/i915: Rework plane readout.

I got the idea from some patches from Partik and/or Maarten but those
moved also the plane state readout to intel_sanitize_crtc() which isn't
quite right in my opinion.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.

Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled

v2: Steal Maarten's idea to move crtc->mode etc. assignment too

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit 721a09f7.

There is nothing wrong with the commit per se. We had two versions of
the commit, one in -next headed for v4.4 and this one for v4.3. Turns
out we'll need to backport more fixes from -next, and they conflict with
the v4.3 version. It gets messy. It will be easiest to revert this one,
and backport all the relevant commits from -next without modifications;
they apply cleanly after this revert.
Requested-by: NJoseph Yasi <joe.yasi@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910#c4
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Apparently writing the DPLL register P1/P2 divider fields won't trigger
an actual change in the DPLL output unless VGA mode is enabled for
prior to the register write that changes the P1/P2 dividers. The write
with the new P1/P2 divider can itself disable VGA mode again without
problems.

I tested the behaviour on my 946GZ, and when manually frobbing the
register with the display on, the behaviour is very clear. However I
can't explain why this machine actually works. The P1/P2 divider
changes caused by normal modesets do seem to make it through to the
hardware somehow since I get a stable picture on the monitor with
any resolution. Maybe it's the "three times for luck" stuff that
somehow masks the problem, or something.

But apparently there are machines (eg. Nick Bowler's G45) where that
isn't the case and we fail to get the correct clock from the DPLL.

Things used to work because we enabled VGA mode for disabled DPLLs,
so when re-enabling the DPLL VGA mode was enabled just prior to the
first register write, and hence the P1/P2 change went through without
a hitch. That got changed in

b8afb911 drm/i915: Keep GMCH DPLL VGA mode always disabled

in the name of consistency. In order to keep the consistency part,
leave VGA mode disabled for disabled DPLLs, but turn it on just prior
to updating the P1/P2 dividers to make sure the hardware picks up
on the new values.

Cc: Nick Bowler <nbowler@draconx.ca>
Reported-by: NNick Bowler <nbowler@draconx.ca>
Tested-by: NNick Bowler <nbowler@draconx.ca>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We accidentally lost the initial DPLL register write in
1c4e0274 drm/i915: Fix DVO 2x clock enable on 830M

The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.
Reported-and-tested-by: NNick Bowler <nbowler@draconx.ca>
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: stable@vger.kernel.org
Cc: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This is a squash of the following commits:

Revert "drm/i915: Drop intel_update_sprite_watermarks"
This reverts commit 47c99438.

Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check"
This reverts commit 7809e5ae.

Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)"
This reverts commit 3a05f5e2.

With these reverts, SKL finally stops failing every single FBC test
with FIFO underrun error messages. After some brief testing, it also
seems that this commit prevents the machine from completely freezing
when we run igt/kms_fbc_crc (see fd.o #92355).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Drop some useless 'reg' variables when we only use them once.

v2: A few more, including a few variable moves
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>

The PIPE_FRMCOUNT_GM45 and PIPE_FLIPCOUNT_GM45 names have bothered me
for a long time. The work equally well for ELK and onwards, so let's
s/GM45/G4X/.
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>

We should serialise access to the intel_crtc->unpin_work through the
dev->event_lock spinlock. It should not be possible for it to disappear
without severe error as the mmio_flip worker has not tagged the
unpin_work pending flip-completion. Similarly if the error exists, just
taking the unpin_work whilst holding the spinlock and then using it
unserialised just masks the race. (It is supposed to be valid as the
unpin_work exists until the flip completion interrupt which should not
fire until we flush the mmio writes to update the display base which is
the last time we access the unpin_work from the kthread.)

References: https://bugs.freedesktop.org/show_bug.cgi?id=92335Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's been reported that the atomic watermark series triggers some
regressions on SKL, which we haven't been able to track down yet.  Let's
temporarily revert these patches while we track down the root cause.

This commit squashes the reverts of:
  76305b1a drm/i915: Calculate watermark configuration during atomic check (v2)
  a4611e44 drm/i915: Don't set plane visible during HW readout if CRTC is off
  a28170f3 drm/i915: Calculate ILK-style watermarks during atomic check (v3)
  de4a9f83 drm/i915: Calculate pipe watermarks into CRTC state (v3)
  de165e0b drm/i915: Refactor ilk_update_wm (v3)

Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-October/077190.html
Cc: "Zanoni, Paulo R" <paulo.r.zanoni@intel.com>
Cc: "Vetter, Daniel" <daniel.vetter@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The comment suggests the check was there for some non-fully-atomic
case, and I couldn't find a case where we wouldn't correctly
initialize plane_state, so remove the check.

Let's leave a WARN there just in case.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Technology has evolved and now we have eDP panels with 3200x1800
resolution. In the meantime, the BIOS guys didn't change the default
32mb for stolen memory. On top of that, we can't assume our users will
be able to increase the default stolen memory size to more than 32mb -
I'm not even sure all BIOSes allow that.

So just the fbcon buffer alone eats 22mb of my stolen memroy, and due
to the BDW/SKL restriction of not using the last 8mb of stolen memory,
all that's left for FBC is 2mb! Since fbcon is not the coolest feature
ever, I think it's better to save our precious stolen resource to FBC
and the other guys.

On the other hand, we really want to use as much stolen memory as
possible, since on some older systems the stolen memory may be a
considerable percentage of the total available memory.

This patch tries to achieve a little balance using a simple heuristic:
if the fbcon wants more than half of the available stolen memory,
don't use stolen memory in order to leave some for FBC and the other
features.

The long term plan should be to implement a way to set priorities for
stolen memory allocation and then evict low priority users when the
high priority ones need the memory. While we still don't have that,
let's try to make FBC usable with the simple solution.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

SKL and BXT qualifies the HAS_DDI() check, and hence haswell
modeset functions are re-used for modeset sequence. But DDI
interface doesn't include support for DSI.
This patch adds:
1. cases for DSI encoder, in those modeset functions and allows
   a CRTC modeset
2. Adds call to pre_pll enabled from CRTC modeset function. Nothing
   needs to be done as such in CRTC for DSI encoder, as PLL, clock
   and and transcoder programming will be taken care in encoder's
   pre_enable and pre_pll_enable function.

v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI
    encoder like DSI for platforms having HAS_DDI as true.

v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid
    encoder.

v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion.
    Fixed the sequence for pre_pll_enable.

v5: Protected DDI code paths in case of DSI encoder calls.
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Don't forget to actually check the cstate->active value when
    tallying up the number of active CRTC's.  (Ander)
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>

We already ensure that pstate->visible = false when crtc->active = false
during runtime programming; make sure we follow the same logic when
reading out initial hardware state.
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>

Calculate pipe watermarks during atomic calculation phase, based on the
contents of the atomic transaction's state structure.  We still program
the watermarks at the same time we did before, but the computation now
happens much earlier.

While this patch isn't too exciting by itself, it paves the way for
future patches.  The eventual goal (which will be realized in future
patches in this series) is to calculate multiple sets up watermark
values up front, and then program them at different times (pre- vs
post-vblank) on the platforms that need a two-step watermark update.

While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since
this function only applies to ILK-style watermarks and we have a
completely different function for SKL-style watermarks.

Note that the original code had a memcmp() in ilk_update_wm() to avoid
calling ilk_program_watermarks() if the watermarks hadn't changed.  This
memcmp vanishes here, which means we may do some unnecessary result
generation and merging in cases where watermarks didn't change, but the
lower-level function ilk_write_wm_values already makes sure that we
don't actually try to program the watermark registers again.

v2: Squash a few commits from the original series together; no longer
    leave pre-calculated wm's in a separate temporary structure since
    it's easier to follow the logic if we just cut over to using the
    pre-calculated values directly.

v3:
 - Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint
   and use intel_atomic_get_crtc_state() to avoid need for extra
   casting.  (Ander)
 - Drop unused intel_check_crtc() function prototype.  (Ander)
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>

The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update.  However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never used by the SKL code, so on SKL an update_sprite_wm is
effectively identical to an update_wm call.  Since we're already
ensuring that the regular intel_update_wm is called any time we'd try to
call intel_update_sprite_watermarks, the whole call is redundant and can
be dropped.
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>

Determine whether we need to apply this workaround at atomic check time
and just set a flag that will be used by the main watermark update
routine.

Moving this workaround into the atomic framework reduces
ilk_update_sprite_wm() to just a standard watermark update, so drop it
completely and just ensure that ilk_update_wm() is called whenever a
sprite plane is updated in a way that would affect watermarks.
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>

A bunch of SKL watermark-related structures have the cursor plane as a
separate entry from the rest of the planes.  Since a previous patch
updated I915_MAX_PLANES such that those plane arrays now have a slot for
the cursor, update the code to use the new slot in the existing plane
arrays and kill off the cursor-specific structures.

There shouldn't be any functional change here; this is just shuffling
around how the data is stored in some of the data structures.  The whole
patch is generated with Coccinelle via the following semantic patch:

        @@ struct skl_pipe_wm_parameters WMP; @@
        - WMP.cursor
        + WMP.plane[PLANE_CURSOR]

        @@ struct skl_pipe_wm_parameters *WMP; @@
        - WMP->cursor
        + WMP->plane[PLANE_CURSOR]

        @@ @@
        struct skl_pipe_wm_parameters {
        ...
        - struct intel_plane_wm_parameters cursor;
        ...
        };

        @@
        struct skl_ddb_allocation DDB;
        expression E;
        @@
        - DDB.cursor[E]
        + DDB.plane[E][PLANE_CURSOR]

        @@
        struct skl_ddb_allocation *DDB;
        expression E;
        @@
        - DDB->cursor[E]
        + DDB->plane[E][PLANE_CURSOR]

        @@ @@
        struct skl_ddb_allocation {
        ...
        - struct skl_ddb_entry cursor[I915_MAX_PIPES];
        ...
        };

        @@
        struct skl_wm_values WMV;
        expression E1, E2;
        @@
        (
        - WMV.cursor[E1][E2]
        + WMV.plane[E1][PLANE_CURSOR][E2]
        |
        - WMV.cursor_trans[E1]
        + WMV.plane_trans[E1][PLANE_CURSOR]
        )

        @@
        struct skl_wm_values *WMV;
        expression E1, E2;
        @@
        (
        - WMV->cursor[E1][E2]
        + WMV->plane[E1][PLANE_CURSOR][E2]
        |
        - WMV->cursor_trans[E1]
        + WMV->plane_trans[E1][PLANE_CURSOR]
        )

        @@ @@
        struct skl_wm_values {
        ...
        - uint32_t cursor[I915_MAX_PIPES][8];
        ...
        - uint32_t cursor_trans[I915_MAX_PIPES];
        ...
        };

        @@ struct skl_wm_level WML; @@
        (
        - WML.cursor_en
        + WML.plane_en[PLANE_CURSOR]
        |
        - WML.cursor_res_b
        + WML.plane_res_b[PLANE_CURSOR]
        |
        - WML.cursor_res_l
        + WML.plane_res_l[PLANE_CURSOR]
        )

        @@ struct skl_wm_level *WML; @@
        (
        - WML->cursor_en
        + WML->plane_en[PLANE_CURSOR]
        |
        - WML->cursor_res_b
        + WML->plane_res_b[PLANE_CURSOR]
        |
        - WML->cursor_res_l
        + WML->plane_res_l[PLANE_CURSOR]
        )

        @@ @@
        struct skl_wm_level {
        ...
        - bool cursor_en;
        ...
        - uint16_t cursor_res_b;
        - uint8_t cursor_res_l;
        ...
        };

v2: Use a PLANE_CURSOR enum entry rather than making the code reference
    I915_MAX_PLANES or I915_MAX_PLANES+1, which was confusing.  (Ander)
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>

In commit

        commit e4ca0612
        Author: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
        Date:   Wed Jul 8 15:31:52 2015 +0200

            drm/i915: Don't forget to mark crtc as inactive after disable

we added extra watermark updates to all of the .crtc_disable()
entrypoints to avoid problems problems with system resume on SKL.  Those
disable entrypoints are currently called in just two places in the
driver: intel_atomic_commit (i.e., during a modeset) and
intel_crtc_disable_noatomic (which is called during hardware readout).
It seems that this extra watermark recalculation should only be
important in the latter case (which happens during a resume operation);
the former case should always have appropriate watermark programming
happening at other points in the modeset sequence.

Let's move the watermark update out of the .crtc_disable() entrypoints
and place it directly in intel_crtc_disable_noatomic() so that it only
happens on S3 resume and not during a regular modeset (since the
existing watermark handling should properly update watermarks during
normal atomic commits).

Cc: Patrik Jakobsson <patrik.jakobsson@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>

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

Previously we've relied on having basically one backlight and one
backlight type per platform. This is already a bit quirky with PMIC PWM
support on VLV/CHV platforms with MIPI DSI. In the foreseeable future
we'll have at least DPCD based backlight control on eDP and DCS command
based backlight control on MIPI DSI. Backlight is becoming more and more
connector specific, so reflect this fact by making the backlight control
hooks connector specific.

This enables further work to reuse generic backlight code in
intel_panel.c while adding more specific backlight code accessed via the
hooks.

Cc: Deepak M <m.deepak@intel.com>
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDeepak M <m.deepak@intel.com>
Reviewed-by: NYetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As with the cdclk, read out czclk from CCK as well. This gives us the
real current value and avoids having to decode fuses and whatnot.

Also store it in kHz under dev_priv like we do for cdlck since it's not
just an rps related clock, and having it in kHz is more
standard/convenient for some things.

Imre also pointed out that we currently fail to read czclk on VLV, which
means the PFI credit programming isn't working as expected.
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>

Rename the DISPLAY_TRUNK_* and DISPLAY_FREQUENCY_* bits to CCK_... instead
of DISPLAY_... to make it clear they apply to all CCK clock control registers.
Suggested by Ville.
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

v2: Deal with _CURABASE too
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

Make adjusted_mode const whereever we don't have to modify it. This only
covers cases when we have a local adjusted_mode variable, and doesn't
make any difference for cases where we just dereference
pipe_config->adjusted_mode.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The adjustead_mode crtc_ timings are what we will program into the hardware,
so it's those timings we should be looking practically everywhere.

The normal and crtc_ timings should differ only when stere doubling is
used. In that case the normal timings are the orignal non-doubled
timigns, and crtc_ timings are the doubled timings used by the hardware.

The only case where we continue to look at the normal timings is when we
pass the adjusted_mode to drm_match_{cea,hdmi}_mode() to find the VIC.
drm_edid keeps the modes aronund in the non-double form only, so it
needs the non-double timings to match against.

Done with sed
's/adjusted_mode->\([vhVH]\)/adjusted_mode->crtc_\1/g'
's/adjusted_mode->clock/adjusted_mode->crtc_clock/g'
with a manual s/VDisplay/vdisplay/ within the comment in intel_dvo.c

v2: Update due to intel_dsi.c changes
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes the warnings like

"plane A assertion failure, should be disabled but not"

that on the initial modeset during boot. This can happen if
the primary plane is enabled by the firmware, but inheriting
it fails because the DMAR is active or for other reasons.

Most likely caused by

commit 36750f28
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon Jun 1 12:49:54 2015 +0200

    drm/i915: update plane state during init

This is the 4.4 version of

commit 721a09f7
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Tue Sep 15 14:28:54 2015 +0200

    drm/i915: Add primary plane to mask if it's visible
Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429Reported-and-tested-by: NEmil Renner Berthing <kernel@esmil.dk>
Tested-by: NAndreas Reis <andreas.reis@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Always name any variable pointing at the adjusted mode as
'adjustead_mode'. This will make it much easier to identify
when we should use the crtc_ timings and when we shoudln't.

Conversion was performed with coccinelle:
@@
expression E;
identifier I;
@@
- struct drm_display_mode *I = &E.adjusted_mode;
+ struct drm_display_mode *adjusted_mode = &E.adjusted_mode;
<...
- I
+ adjusted_mode
...>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
[danvet: Fixup conflicts.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>