drm/i915/skl+: calculate ddb minimum allocation (v6)

don't always use 8 ddb as minimum, instead calculate using proper
algorithm.

v2: optimizations as per Matt's comments.

v3 (by Matt):
 - Fix boolean logic for !fb test in skl_ddb_min_alloc()
 - Adjust negative tiling format comparisons in skl_ddb_min_alloc() to
   improve readability.

v4 (by Matt):
 - Rebase onto recent atomic watermark changes
 - Slight tweaks to code flow to make the logic more closely match the
   description in the bspec.

v5 (by Matt):
 - Handle minimum scanline calculation properly for 4 & 8 bpp formats.
   8bpp isn't actually possible right now, but it's listed in the bspec
   so I've included it here for forward compatibility (similar to how
   we have logic for NV12).

v6 (by Matt):
 - Calculate plane_bpp correctly for non-NV12 formats. (Mahesh)

Cc: matthew.d.roper@intel.com
Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Kumar Mahesh <mahesh1.kumar@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464713939-10440-1-git-send-email-matthew.d.roper@intel.com

drm/i915: Don't try to calculate relative data rates during hw readout

We don't actually read out full plane state during driver startup (only
whether the primary plane is enabled/disabled), so all of the src/dest
rectangles are invalid at this point.  However this calculation was
needless anyway since we re-calculate them from scratch on the very
first atomic transaction after boot anyway.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Kumar Mahesh <mahesh1.kumar@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463439121-28974-2-git-send-email-matthew.d.roper@intel.com

drm/i915: Only ignore eDP ports that are connected

If the VBT says that a certain port should be eDP (and hence fused off
from HDMI), but in reality it isn't, we need to try and acquire the HDMI
connection instead. So only trust the VBT edp setting if we can connect
to an eDP device on that port.

Fixes: d2182a6608 (drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV)
References: https://bugs.freedesktop.org/show_bug.cgi?id=96288
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Phidias Chiang <phidias.chiang@canonical.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464766070-31623-1-git-send-email-chris@chris-wilson.co.uk

drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled

On Loading, GuC sets PM interrupts routing (bit 31) and clears ARAT
expired interrupt (bit 9). Host turbo also updates this register
in RPS flows. This patch ensures bit 31 and bit 9 setup by GuC persists.
ARAT timer interrupt is needed in GuC for various features. It also
facilitates halting GuC and hence achieving RC6. PM interrupt routing
will not impact RPS interrupt reception by host as GuC will redirect
them.
This patch fixes igt test pm_rc6_residency that was failing with guc
load/submission enabled. Tested with SKL GuC v6.1 and BXT GuC v5.1 and v8.7.

v2: i915_irq/i915_pm decoupling from intel_guc. (ChrisW)

v3: restructuring the mask update and rebase w.r.t Ville's patch. (ChrisW)

v4: Updating the pm_intr_keep during direct_interrupts_to_guc. (Sagar)

Cc: Chris Harris <chris.harris@intel.com>
Cc: Zhe Wang <zhe1.wang@intel.com>
Cc: Deepak S <deepak.s@intel.com>
Cc: Satyanantha, Rama Gopal M <rama.gopal.m.satyanantha@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Testcase: igt/pm_rc6_residency
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Tested-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464683307-19475-1-git-send-email-sagar.a.kamble@intel.com

drm/i915: kill STANDARD/CURSOR plane screams

Stop yelling the plane type. "STANDARD" doesn't mean anything anyway.
Let's just use the plane name here.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-8-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Give encoders useful names

Rather than let the core generate usless encoder names, let's pass in
something that actually identifies the piece of hardware we're dealing
with.

v2: Use 'DSI %c' instead of 'MIPI %c' for DSI encoders (Jani)
v3: Use port_name() in DSI code since we have it

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-7-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Give meaningful names to all the planes

Let's name our planes in a way that makes sense wrt. the spec:
- skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc.
- g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc.
- pre-g4x -> "plane A", "cursor B" etc.

v2: Rebase on top of the fixed/cleaned error paths
    Use a local 'name' variable to make things easier
v3: Pass the name as a function argument to drm_universal_plane_init() (Jani)
v3: Pass the printf style string to drm_universal_plane_init()

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-6-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Don't leak primary/cursor planes on crtc init failure

Call intel_plane_destroy() instead of drm_plane_cleanup() so that we
also free the plane struct itself when bailing out of the crtc init.

And make intel_plane_destroy() NULL tolerant to avoid having to check
for it in the caller.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Set crtc->name to "pipe A", "pipe B", etc.

v2: Fix intel_crtc leak on failure to allocate the name
    Use a local 'name' variable to make things easier
v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani)
v4: Pass the printf style format string to drm_crtc_init_with_planes()
v5: Drop spurious code changes

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Use plane->name in debug prints

We have plane->name, so let's use that in debug messages instead
of just printing the more or less useless object ID.

v2: slap on a commit message

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Use crtc->name in debug messages

We have crtc->name, so let's use that in debug messages instead
of just printing the more or less useless object ID.

v2: Rebased due to intel_dpll_mgr.c, slap on a commit message

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464371966-15190-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Reject modeset if the dotclock is too high

Reject the modeset if the requested dotclock exceeds the maximum allowed
by the hardware. So far we've only checked this on gen2/3 while also
handling the double wide vs. single wide pipe selection. Extend the
check to all platforms since we have the max dotclock correctly
populated now across the board.

Testcase: igt/kms_invalid_dotclock
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464114859-15610-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix NULL pointer deference when out of PLLs in IVB

In commit f9476a6c6d0c ("drm/i915: Refactor platform specifics out of
intel_get_shared_dpll()"), the ibx_get_dpll() function lacked an error
check, that can lead to a NULL pointer dereference when trying to enable
three pipes.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000068
IP: [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915]
PGD cec87067 PUD d30ce067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: snd_hda_intel i915 drm_kms_helper drm intel_gtt sch_fq_codel cfg80211 binfmt_misc i2c_algo_bit cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp agpgart kvm_intel snd_hda_codec_hdmi kvm iTCO_wdt snd_hda_codec_realtek snd_hda_codec_generic irqbypass aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd psmouse pcspkr snd_hda_codec i2c_i801 snd_hwdep snd_hda_core snd_pcm snd_timer lpc_ich mfd_core snd soundcore wmi evdev tpm_tis tpm [last unloaded: drm]
CPU: 3 PID: 5810 Comm: kms_flip Tainted: G     U  W       4.6.0-test+ #3
Hardware name:                  /DZ77BH-55K, BIOS BHZ7710H.86A.0100.2013.0517.0942 05/17/2013
task: ffff8800d3908040 ti: ffff8801166c8000 task.ti: ffff8801166c8000
RIP: 0010:[<ffffffffa0482275>]  [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915]
RSP: 0018:ffff8801166cba60  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000002
RDX: 0000000000000001 RSI: ffff8800d07f1bf8 RDI: 0000000000000000
RBP: ffff8801166cba88 R08: 0000000000000002 R09: ffff8800d32e5698
R10: 0000000000000001 R11: ffff8800cc89ac88 R12: ffff8800d07f1bf8
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f4c3fc8d8c0(0000) GS:ffff88011bcc0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000068 CR3: 00000000d3b4c000 CR4: 00000000001406e0
Stack:
 0000000000000000 ffff8800d07f1bf8 0000000000000000 ffff8800d04c0000
 0000000000000000 ffff8801166cbaa8 ffffffffa04823a7 ffff8800d07f1bf8
 ffff8800d32e5698 ffff8801166cbab8 ffffffffa04840cf ffff8801166cbaf0
Call Trace:
 [<ffffffffa04823a7>] ibx_get_dpll+0x47/0xa0 [i915]
 [<ffffffffa04840cf>] intel_get_shared_dpll+0x1f/0x50 [i915]
 [<ffffffffa046d080>] ironlake_crtc_compute_clock+0x280/0x430 [i915]
 [<ffffffffa0472ac0>] intel_crtc_atomic_check+0x240/0x320 [i915]
 [<ffffffffa03da18e>] drm_atomic_helper_check_planes+0x14e/0x1d0 [drm_kms_helper]
 [<ffffffffa0474a0c>] intel_atomic_check+0x5dc/0x1110 [i915]
 [<ffffffffa029d3aa>] drm_atomic_check_only+0x14a/0x660 [drm]
 [<ffffffffa029d086>] ? drm_atomic_set_crtc_for_connector+0x96/0x100 [drm]
 [<ffffffffa029d8d7>] drm_atomic_commit+0x17/0x60 [drm]
 [<ffffffffa03dc3b7>] restore_fbdev_mode+0x237/0x260 [drm_kms_helper]
 [<ffffffffa029c65a>] ? drm_modeset_lock_all_ctx+0x9a/0xb0 [drm]
 [<ffffffffa03de9b3>] drm_fb_helper_restore_fbdev_mode_unlocked+0x33/0x80 [drm_kms_helper]
 [<ffffffffa03dea2d>] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper]
 [<ffffffffa03de93a>] drm_fb_helper_hotplug_event+0xaa/0xf0 [drm_kms_helper]
 [<ffffffffa03de9d6>] drm_fb_helper_restore_fbdev_mode_unlocked+0x56/0x80 [drm_kms_helper]
 [<ffffffffa0490f72>] intel_fbdev_restore_mode+0x22/0x80 [i915]
 [<ffffffffa04ba45e>] i915_driver_lastclose+0xe/0x20 [i915]
 [<ffffffffa02810de>] drm_lastclose+0x2e/0x130 [drm]
 [<ffffffffa028148c>] drm_release+0x2ac/0x4b0 [drm]
 [<ffffffff811a6b2d>] __fput+0xed/0x1f0
 [<ffffffff811a6c6e>] ____fput+0xe/0x10
 [<ffffffff81079156>] task_work_run+0x76/0xb0
 [<ffffffff8105aaab>] do_exit+0x3ab/0xc60
 [<ffffffff810a145f>] ? trace_hardirqs_on_caller+0x12f/0x1c0
 [<ffffffff8105c67e>] do_group_exit+0x4e/0xc0
 [<ffffffff8105c704>] SyS_exit_group+0x14/0x20
 [<ffffffff8158bb25>] entry_SYSCALL_64_fastpath+0x18/0xa8
Code: 14 80 48 8d 34 90 b8 01 00 00 00 d3 e0 09 04 b3 5b 41 5c 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 41 54 53 <44> 8b 67 68 48 89 f3 48 8b be 08 02 00 00 4c 8b 2e e8 15 9d fd
RIP  [<ffffffffa0482275>] intel_reference_shared_dpll+0x15/0x100 [i915]
 RSP <ffff8801166cba60>
CR2: 0000000000000068

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: f9476a6c6d0c ("drm/i915: Refactor platform specifics out of intel_get_shared_dpll()")
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463748426-5956-1-git-send-email-ander.conselvan.de.oliveira@intel.com

drm/i915/ilk: Don't disable SSC source if it's in use

Thanks to Ville Syrjälä for pointing me towards the cause of this issue.

Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
configurations. This causes issues on the first modeset, since we don't
expect SSC to be left on and as a result, can't successfully power down
the pipes or the transcoders using it. Here's an example from this Dell
OptiPlex 990:

[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf40000
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
… later we try committing the first modeset …
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
…
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config]     FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config]     scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
------------[ cut here ]------------
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
…
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A

Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.

A better solution would be to add refcounts for the SSC source, but for
now leaving the source clock on should suffice.

Changes since v3:
 - Move temp variable into loop
 - Move checks for using_ssc_source to after we've figured out has_ck505
 - Add using_ssc_source to debug output
Changes since v2:
 - Fix debug output for when we disable the CPU source
Changes since v1:
 - Leave the SSC source clock on instead of just shutting it off on all
   of the DPLL configurations.

Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1464199863-9397-1-git-send-email-cpaul@redhat.com

drm/i915/bxt: Sanitize CDCLK to fix breakage during S4 resume

I noticed that during S4 resume BIOS incorrectly sets bits 18, 19 which
are reserved/MBZ and sets the decimal frequency fields to all 0xff in
the CDCLK register. The result is a hard lockup as display register
accesses are attempted later. Work around this by sanitizing the CDCLK
PLL/dividers the same way it's done on SKL.

While this is clearly a BIOS bug which should be fixed separately, it
doesn't hurt to check/sanitize this regardless.

v2:
- Use the same condition for VCO and CDCLK in broxton_init_cdclk as is
  used in skl_init_cdclk for the same purpose.

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464093513-16258-2-git-send-email-imre.deak@intel.com

drm/i915/gen9: Assume CDCLK PLL is off if it's not locked

If the CDCLK PLL isn't locked or incorrectly configured we can just
assume that it's off resulting in fully re-initializing both CDCLK PLL
and CDCLK dividers. This way the CDCLK PLL sanitization added in the
following patch can be done on BXT the same way as it's done on SKL.

v2: (Ville)
- Remove the remaining PLL specific checks from skl_sanitize_cdclk() and
  depend instead on the corresponding check in skl_dpll0_update().
- Use vco == 0 instead of the corresponding boolean check in
  skl_sanitize_cdclk().

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464093513-16258-1-git-send-email-imre.deak@intel.com

drm/i915: Revert async unpin and nonblocking atomic commit

This reverts the following patches:

d55dbd06bb5e1399aba9ab5227465339d1bbefff drm/i915: Allow nonblocking update of pageflips.
15c86bdb760185e871c7a0f559978328aa500971 drm/i915: Check for unpin correctness.
95c2ccdc82d520f59ae3b6fdc097b63c9b7082bb Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"
a6747b7304a9d66758a196d885dab8bbfa5e7d1f drm/i915: Make unpin async.
03f476e1fcb42fca88fc50b94b0d3adbdbe887f0 drm/i915: Prepare connectors for nonblocking checks.
2099deffef4404f949ba1b68d2b17e0608190bc2 drm/i915: Pass atomic states to fbc update functions.
ee7171af72c39c18b7d7571419a4ac6ca30aea66 drm/i915: Remove reset_counter from intel_crtc.
2ee004f7c59b2e642f0bb2834f847d756f2dd7b7 drm/i915: Remove queue_flip pointer.
b8d2afae557dbb9b9c7bc6f6ec4f5278f3c4c34e drm/i915: Remove use_mmio_flip kernel parameter.
8dd634d922615ec3a9af7976029110ec037f8b50 drm/i915: Remove cs based page flip support.
143f73b3bf48c089b40f58462dd7f7c199fd4f0f drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.
84fc494b64e8c591be446a966b7447a9db519c88 drm/i915: Add the exclusive fence to plane_state.
6885843ae164e11f6c802209d06921e678a3f3f3 drm/i915: Convert flip_work to a list.
aa420ddd8eeaa5df579894a412289e4d07c2fee9 drm/i915: Allow mmio updates on all platforms, v2.
afee4d8707ab1f21b7668de995be3a5961e83582 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates"

"drm/i915: Allow nonblocking update of pageflips" should have been
split up, misses a proper commit message and seems to cause issues in
the legacy page_flip path as demonstrated by kms_flip.

"drm/i915: Make unpin async" doesn't handle the unthrottled cursor
updates correctly, leading to an apparent pin count leak. This is
caught by the WARN_ON in i915_gem_object_do_pin which screams if we
have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins.

Unfortuantely we can't just revert these two because this patch series
came with a built-in bisect breakage in the form of temporarily
removing the unthrottled cursor update hack for legacy cursor ioctl.
Therefore there's no other option than to revert the entire pile :(

There's one tiny conflict in intel_drv.h due to other patches, nothing
serious.

Normally I'd wait a bit longer with doing a maintainer revert, but
since the minimal set of patches we need to revert (due to the bisect
breakage) is so big, time is running out fast. And very soon
(especially after a few attempts at fixing issues) it'll be really
hard to revert things cleanly.

Lessons learned:
- Not a good idea to rush the review (done by someone fairly new to
  the area) and not make sure domain experts had a chance to read it.

- Patches should be properly split up. I only looked at the two
  patches that should be reverted in detail, but both look like the
  mix up different things in one patch.

- Patches really should have proper commit messages. Especially when
  doing more than one thing, and especially when touching critical and
  tricky core code.

- Building a patch series and r-b stamping it when it has a built-in
  bisect breakage is not a good idea.

- I also think we need to stop building up technical debt by
  postponing atomic igt testcases even longer. I think it's clear that
  there's enough corner cases in this beast that we really need to
  have the testcases _before_ the next step lands.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm/i915/debugfs: Show context objects in i915_gem_objects

One of the uses for i915_gem_objects is pin-pointing leaks. For this, we
can compare the number of allocated objects and who owns them, a
discrepancy here often indicates a kernel bug. One allocator of unreported
objects is for backing context objects, so include those in the listing.

v2: Take filelist_mutex which requires a little dance with struct_mutex
to avoid nesting filelist_mutex inside struct_mutex.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-10-git-send-email-chris@chris-wilson.co.uk

drm/i915: Rearrange i915_gem_context

Pack the integers and related types together inside the struct.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-9-git-send-email-chris@chris-wilson.co.uk

drm/i915: Merge legacy+execlists context structs

struct intel_context contains two substructs, one for the legacy RCS and
one for every execlists engine. Since legacy RCS is a subset of the
execlists engine support, just combine the two substructs.

v2: Only pin the default context for legacy mode (the object only exists
for legacy, but adding i915.enable_execlists provides symmetry with the
cleanup functions).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-8-git-send-email-chris@chris-wilson.co.uk

drm/i915: Put the kernel_context in drm_i915_private next to its friends

Just move the kernel_context member of drm_i915_private next to the
engines it is associated with.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-7-git-send-email-chris@chris-wilson.co.uk

drm/i915: Show i915_gem_context owner in debugfs

Print the context's owner (via the pid under file_priv) under debugfs.
In doing so, we must be careful that the filp is not accessed after it
is freed (notified via i915_gem_context_close).

v2: Mark the file_priv as closed.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-6-git-send-email-chris@chris-wilson.co.uk

drm/i915: Move pinning of dev_priv->kernel_context into its creator

Rather than have every context ask "am I owned by the kernel? pin!",
move that logic into the creator of the kernel context, in order to
improve code comprehension.

v2: Throw away the user_handle on failure to allocate the ppgtt.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-5-git-send-email-chris@chris-wilson.co.uk

drm/i915: Name the inner most per-engine intel_context struct

We want to give a name to the currently anonymous per-engine struct
inside the context, so that we can assign it to a local variable and
save clumsy typing. The name we have chosen is intel_context as it
reflects the HW facing portion of the context state (the logical context
state, the registers, the ringbuffer etc).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-4-git-send-email-chris@chris-wilson.co.uk

drm/i915: Rename and inline i915_gem_context_get()

i915_gem_context_get() is a very simple wrapper around idr_find(), so
simple that it would be smaller to do the lookup inline. Also we use the
verb 'lookup' to return a pointer from a handle, freeing 'get' to imply
obtaining a reference to the context.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-3-git-send-email-chris@chris-wilson.co.uk

drm/i915: Apply lockdep annotations to i915_gem_context.c

Markup the functions that require the caller to hold struct_mutex with
lockdep_assert_held(). In the hopefully not-too-distant future we will
split the struct_mutex up, and in doing so we need to be sure that we
know what it protects - here the lockdep annotations are invaluable.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-2-git-send-email-chris@chris-wilson.co.uk
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-2-git-send-email-chris@chris-wilson.co.uk

drm/i915: Rename struct intel_context

Our goal is to rename the anonymous per-engine struct beneath the
current intel_context. However, after a lively debate resolving around
the confusion between intel_context_engine and intel_engine_context, the
realisation is that the two structs target different users. The outer
struct is API / user facing, and so carries the higher level GEM
information. The inner struct is hw facing. Thus we want to name the
inner struct intel_context and the outer one i915_gem_context. As the
first step, we need to rename the current struct:

s/struct intel_context/struct i915_gem_context/

which fits much better with its constructors already conveying the
i915_gem_context prefix!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464098023-3294-1-git-send-email-chris@chris-wilson.co.uk

drm/i915/guc: Disable automatic GuC firmware loading

New GuC code is logging errors at runtime suspend and resume which
causes CI testing to log "orange" status. Default to not trying to
load the firmware until this is resolved.

Example of the log:

 [drm] RC6 on
 [drm:intel_runtime_suspend] Suspending device
 [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x501 failed. ret=-110 status=0x00000501 response=0x40000000
 ...
 [drm:intel_runtime_resume] Resuming device
 [drm:host2guc_action [i915]] *ERROR* GUC: host2guc action 0x502 failed. ret=-110 status=0x00000502 response=0x40000000
 [drm:intel_runtime_resume] Device resumed

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Harris <chris.harris@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1464017675-12257-1-git-send-email-tvrtko.ursulin@linux.intel.com

drm/i915: Assert the dbuf is enabled when disabling DC5/6

Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling.
Let's make sure it has correctly restored the dbuf state to enabled
when we disable the DC states.

v2: s/skl/gen9/ in function name (Imre)

Cc: Imre Deak <imre.deak@intel.com>
Suggested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463407180-28993-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Set BXT cdclk to minimum initially

In case the driver is initialized without active displays, we should
just drop the cdclk to the minimum frequency right off the bat. There
might not be a modeset to drop it to the minimum late rafter all.

With DMC supposedly we should always have the cdclk up and running.
The DMC will shut the DE PLL down when appropriate, so let's nuke
the related FIXMEs as well. Trying to do anything different would
go against the expectations of the DMC firmware, and we all know
how fragile the DMC firmware is.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-22-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk check

Rather than having a BXT specific function to make sure the DE PLL is
enabled after disabling DC6, let's just make sure the current cdclk
is the same as what we last programmed.

Having another check in bxt_display_core_init() almost immediately after
the cdclk init seems redundant, so let's just kill that one.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-21-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Make bxt_set_cdclk() operate in terms of the current vs target DE PLL vco

Make bxt_set_cdclk() more readable by looking at current vs. target
DE PLL vco to determine if the DE PLL needs disabling and/or enabling.
We can also calculate the CD2X divider simply as (vco/cdclk) instead of
depending on magic numbers.

The magic numbers are still needed though, but only to map the supported
cdclk frequencies to corresponding DE PLL frequencies.

Note that w'll now program CDCLK_CTL correctly even for the bypass case.
Actually the CD2X divider should not matter in that case since the
hardware will bypass it too, but the "decimal" part should matter (if we
want to do gmbus/aux with the bypass enabled).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-20-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the DE PLL vco/refclk

Now that we've read out the DE PLL vco and refclk, we can just use them
in the cdclk calculation. While at it switch over to
DIV_ROUND_CLOSEST().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-19-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Update cached cdclk state from broxton_init_cdclk()

Let's make sure our cached cdclk state is accurate right after
broxton_init_cdclk() whether or not we end up changing the cdclk
frequency.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-18-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv

We have need to know the DE PLL refclk and output frequency in various
cdclk calculations, so let's store those in dev_priv.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-17-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk()

Enabling and disalbing the DE PLL are two nice self contained
operations, so let's move them into a few small helper functions.
Makes it easier to see the forest from the trees in broxton_set_cdclk().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-16-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Store cdclk PLL reference clock under dev_priv

Future platforms will have multiple options for the cdclk PLL reference
clock, so let's start tracking that under dev_priv alreday on SKL,
although on SKL it's always 24 MHz.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-15-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Rename skl_vco_freq to cdclk_pll.vco

We'll want to store the cdclk PLL (whatever PLL that is in reality) vco
frequency somewhere on other platforms too, so let's rename the
skl_vco_freq to cdclk_pll.vco, and let's store it in kHz instead of MHz
to match most of the other clocks.

v2: Drop the spurious > vs != change (Imre)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-14-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL

The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz.
Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz.
Let's use the slightly more accurate numbers. Potentially we might
change to computing all of these based on dividers, but let's
stick to the current theme for now..

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-13-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit

SKL and BXT have the same snippets of code for enabling disabling the
DBUF. Extract those into helpers and move the calls from
init/unit_cdclk() to the display core init/init since this stuff isn't
really about cdclk. Also doing the enable twice shouldn't hurt since
you're just setting the request bit again when it was already set.

We can also toss in a few WARNs about the register values into
skl_get_dpll0_vco() now that we know that things should always be
sane there.

Flatten skl_init_cdclk() while at it.

v2: s/skl/gen9/ in function names (Imre)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-12-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Unify SKL cdclk init paths

Currently we initialize cdclk on SKL from two different places,
depending on whether it's during driver init or resume. Let's
unify it to happen from the same place always, and that place will be
the display core init function.

To do this we first run through the cdclk sanitation code, which will
first verify that the PLL is programmed correctly, after which we can
read out the current cdclk frequency, and once the cdclk is known we
verify that the cdclk "decimal" frequency is programmed correctly. If
any of these fail we will force a cdclk change, and to be safe we also
force the PLL to be turned off and on again. If the sanitation step
didn't notice anything amiss, we'll skip the cdclk programming which
will prevent cdclk reprogramming when the displays might be active.

We can also toss in a few WARNs about the register values into
skl_update_dpll0() since we now know that the PLL state should
always be sane when that function is called.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-11-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Beef up skl_sanitize_cdclk() a bit

Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw
out a few unneeded variables, and write the CDCLK_CTL check a bit more
legible way.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-10-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Keep track of preferred cdclk vco frequency on SKL

Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need
something that keeps track of which vco frequency we want to use in case
the current vco is 0. This would be important across supend/resume since
we'll disable DPLL0 around those parts.

We'll also update our idea of max cdclk/dotclock when the preferred
vco changes. That could happen if out initial guess was wrong, and
later eDP would force us to change it. One issue here could be that
changing the max dotclock could cause our mode list to change during
next time the displays get probed. But I don't see a good way to avoid
that, except perhaps by allowing either vco frequency to be used as
needed. But the docs suggest that such usage wasn't really inteded.

Also need to make sure we don't update our max_cdclk value before we
have a preferred vco value, which means moving that to happen after
the cdclk sanitation.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-9-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL

In case we originally guessed wrong which lcpll vco frequency to use,
we will need to shut down the pll and restart it when reprogamming the
cdclk.

This also allows us to track the actual vco frequency in dev_priv
instead of just a guess.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-8-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Report the current DPLL0 vco on SKL/KBL

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-7-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Actually read out DPLL0 vco on skl from hardware

Currently we're trying to guess which lcpll vco frequency is used
use based on the cdclk. That doesn't work for cdclk==540 since
both vco frequencies can generate a 540 Mhz output. Let's stop
guessing and just read the actual vco frequency from the
hardware.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-6-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Extract skl_calc_cdclk()

We have many places where we want to pick a suitable cdclk frequency for
skl based on the dotclock and lcpll vco. Split that code into a small
helper and call it from all over.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915: Move the SKL DPLL0 VCO computation into intel_dp_compute_config()

Shared plls won't get assigned until the .compute_clocks() hook gets
called, which happens from the crtc .atomic_check hook. That's too late
as the cdclk computation has already happened. So let's move the DPLL0
VCO computation into intel_dp_compute_config() so that it's done when
the cdclk computation happens. Also only do it for eDP since we only
pick DPLL0 for eDP.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915/skl: SKL CDCLK change on modeset tracking VCO

WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
is enabled when the cdclk is less then required. DP connected to DDI2
and HPD on either port works correctly.

Set cdclk based on the max required pixel clock based on VCO
selected. Track boot vco instead of boot cdclk.

The vco is now tracked at the atomic level and all CRTCs updated if
the required vco is changed. Not tested with eDP v1.4 panels that
require 8640 vco due to availability.

V1: initial version
V2: add vco tracking in intel_dp_compute_config(), rename
skl_boot_cdclk.
V3: rebase, V2 feedback not possible as encoders are not aware of
atomic.
V4: track target vco is atomic state. modeset all CRTCs if vco changes
V5: rename atomic variable, cleaner if/else logic, use existing vco if
      encoder does not return a new vco value. check_patch.pl cleanup
V6: simplify logic in intel_modeset_checks.
V7: reorder an IF for readability and whitespace fix.
V8: use dev_cdclk for tracking new cdclk during atomic
V9: correctly handle vco 8640 when crtcs==0
V10: Clean up if else in crtcs==0
V11: Rebase for new intel_dpll_mgr.c

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
[vsyrjala: rebased due to churn]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-3-git-send-email-ville.syrjala@linux.intel.com

drm/i915: Fix BXT min_pixclk after state readout

commit 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation")
tried to change BXT to use ilk_max_pixel_rate() to compute the
pipe pixel rate. I failed to notice that there was another place
in the state readout code that needs the same treatment. So let's
change that one too.

Should probably just change things to always compuyte the pipe pixel
rates, instead of just doing on platforms that can change cdclk
dynamically. But for now let's just move BXT fully over to the
side that uses ilk_pipe_pixel_rate().

Cc: Jani Nikula <jani.nikula@intel.com>
Fixes: 4e5ca60fd35a ("drm/i915: Use ilk_max_pixel_rate() for BXT cdclk calculation")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463172100-24715-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>

drm/i915/opregion: Rename init/fini functions to register/unregister

Current intel_opregion_init is called during the driver registration
phase and intel_opregion_fini from the unregistration phase. Rename the
functions so that this is clear from their names. The phases tell us
what we expect the existing hw state to be, e.g. whether interrupts are
still enabled etc.

It should be noted that the opregion init/fini routines are asymmetric
and this is carried across into their new names. Indeed, their new names
make it even clearer that perhaps all is not well in the opregion
suspend/resume sequence (as well in the module unload).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464012490-30961-2-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>

drm/i915/opregion: Convert to using native drm_i915_private

Prefer passing struct drm_i915_private to internal interfaces as this
saves us having to dance between drm_device and our native struct. The
savings hare are small (only 70 bytes of unrequired dancing), but
progressive!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1464012490-30961-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>

drm/i915: Enable GSE interrupt on BDW+

We've never actually enabled or unmasked the GSE interrupt on BDW+,
even though the interrupt handler was always prepared for it.
Let's enable it and see what happens.

Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
driver. He reports that it fixed the "ACPI _BCM/_BCQ-based
brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1
Carbon" for them.

Mark says:
"FWIW, this *is* needed if you want ACPI-based backlight control to
 work.  On Linux you probably don't notice, since "hardware" backlight
 control is preferred over "firmware" or "platform" backlight control.

 It would help me if this did land in the Linux tree though, as it will
 make future imports of the i915 driver into OpenBSD easier."

So even though we don't really need this, let's put it in to help Mark
with future porting efforts. Should be harmless to have it enabled in
any case.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html
Reported-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463649283-28698-1-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/guc: rework guc_add_workqueue_item()

Mostly little optimisations and future-proofing against code breakage.
For instance, if the driver is correctly following the submission
protocol, the "out of space" condition is impossible, so the previous
runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic
effect in development and less impact in end-user systems.

Similarly we can make alignment checking more stringent and replace
other WARN_ON() conditions that don't relate to the runtime hardware
state with either BUILD_BUG_ON() for compile-time-detectable issues, or
GEM_BUG_ON() for logical "can't happen" errors.

With those changes, we can convert it to void, as suggested by Chris
Wilson, and update the calling code appropriately.

v2:
    Note that we're now putting the request seqno in the "fence_id"
    field of each GuC-work-item, in case it turns up somewhere useful
    (e.g. in a GuC log) [Tvrtko Ursulin].

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915/guc: don't spinwait if the GuC's workqueue is full

Rather than wait to see whether more space becomes available in the GuC
submission workqueue, we can just return -EAGAIN and let the caller try
again in a little while. This gets rid of an uninterruptable sleep in
the polling code :)

We'll also add a counter to the GuC client statistics, to see how often
we find the WQ full.

v2:
    Flag the likely() code path (Tvtrko Ursulin).

v4:
    Add/update comments about failure counters (Tvtrko Ursulin).

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

The knowledge of how to derive the relevant client from the request
should be localised within i915_guc_submission.c; the LRC code shouldn't
have to know about the internal details of the GuC submission process.
And all the information the GuC code needs should be encapsulated in (or
reachable from) the request.

v2:
    GEM_BUG_ON() for bad GuC client (Tvrtko Ursulin).
    Add/update kerneldoc explaining check_space/submit protocol

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915/guc: add enable_guc_loading parameter

Split the function of "enable_guc_submission" into two separate
options.  The new one ("enable_guc_loading") controls only the
*fetching and loading* of the GuC firmware image. The existing
one is redefined to control only the *use* of the GuC for batch
submission once the firmware is loaded.

In addition, the degree of control has been refined from a simple
bool to an integer key, allowing several options:
-1 (default)     whatever the platform default is
 0  DISABLE      don't load/use the GuC
 1  BEST EFFORT  try to load/use the GuC, fallback if not available
 2  REQUIRE      must load/use the GuC, else leave the GPU wedged

The new platform default (as coded here) will be to attempt to
load the GuC iff the device has a GuC that requires firmware,
but not yet to use it for submission. A later patch will change
to enable it if appropriate.

v4:
    Changed some error-message levels, mostly ERROR->INFO, per
    review comments by Tvrtko Ursulin.

v5:
    Dropped one more error message, disabled GuC submission on
    hypothetical firmware-free devices [Tvrtko Ursulin].

v6:
    Logging tidy by Tvrtko Ursulin:
     * Do not log falling back to execlists when wedging the GPU.
     * Do not log fw load errors when load was disabled by user.
     * Pass down some error code from fw load for log message to
       make more sense.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Tested-by: Fiedorowicz, Lukasz <lukasz.fiedorowicz@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v5)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com> (v6)

drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED

For now, anything with a GuC requires uCode loading, and then supports
command submission once loaded. But these are logically distinct from
simply "having a GuC", so we need a separate macro for the latter. Then,
various tests should use this new macro rather than HAS_GUC_UCODE() or
testing enable_guc_submission.

v4:
    Added a couple more uses of the new macro.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915/guc: rename loader entry points

The GuC initialisation code could do other things apart from loading
firmware, so here we rename the three primary entry points to remove any
specific reference to "ucode" (no functional changes, just renaming).

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

drm/i915: Update DRIVER_DATE to 20160522

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

drm/i915: Inline sg_next() for the optimised SGL iterator

Avoiding the out-of-line call to sg_next() reduces the kernel execution
overhead by 10% in some workloads (for example the Unreal Engine 4 demo
Atlantis on 2GiB GTTs) which are dominated by the cost of inserting PTEs
due to texture thrashing. We can demonstrate this in a microbenchmark
that forces us to rebind the object on every execbuf, where we can
measure a 25% improvement, in the time required to execute an execbuf
requiring a texture to be rebound, for inlining the sg_next() for large
texture sizes.

Benchmark: igt/benchmarks/gem_exec_fault
Benchmark: igt/benchmarks/gem_exec_trace/Atlantis
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-5-git-send-email-chris@chris-wilson.co.uk

drm/i915: Introduce & use new lightweight SGL iterators

The existing for_each_sg_page() iterator is somewhat heavyweight, and is
limiting i915 driver performance in a few benchmarks. So here we
introduce somewhat lighter weight iterators, primarily for use with GEM
objects or other case where we need only deal with whole aligned pages.

Unlike the old iterator, the new iterators use an internal state
structure which is not intended to be accessed by the caller; instead
each takes as a parameter an output variable which is set before each
iteration. This makes them particularly simple to use :)

One of the new iterators provides the caller with the DMA address of
each page in turn; the other provides the 'struct page' pointer required
by many memory management operations.

Various uses of for_each_sg_page() are then converted to the new macros.

v2: Force inlining of the sg_iter constructor and make the union
anonymous.

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-4-git-send-email-chris@chris-wilson.co.uk

drm/i915: optimise i915_gem_object_map() for small objects

We're using this function for ringbuffers and other "small" objects, so
it's worth avoiding an extra malloc()/free() cycle if the page array is
small enough to put on the stack. Here we've chosen an arbitrary cutoff
of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a
context image (currently up to 22 pages).

v5:
    change name of local array [Chris Wilson]

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-3-git-send-email-chris@chris-wilson.co.uk

drm/i915: refactor i915_gem_object_pin_map()

The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code, this patch pulls out the "mapping" part of
the operation (involving local allocations which must be undone before
return) into its own subfunction.

The next patch will then insert the new optimisation into the middle of
the now-separated subfunction.

This reorganisation will probably not affect the generated code, as the
compiler will most likely inline it anyway, but it makes the logical
structure a bit clearer and easier to modify.

v2:
    Restructure loop-over-pages & error check [Chris Wilson]

v3:
    Add page count to debug messages [Chris Wilson]
    Convert WARN_ON() to GEM_BUG_ON()

v4:
    Drop the DEBUG messages [Tvrtko Ursulin]

Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1463741647-15666-2-git-send-email-chris@chris-wilson.co.uk

drm/i915/psr: Implement PSR2 w/a for gen9

Found this while browsing Bspec. Looks like it applies to both skl and
kbl.

v2: Also for bxt (Art).

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "Runyan, Arthur J" <arthur.j.runyan@intel.com>
Reviewed-by: Sonika Jindal<sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463642060-30728-1-git-send-email-daniel.vetter@ffwll.ch

drm/i915/psr: Use ->get_aux_send_ctl functions

I just wanted to get rid of the rmw cycle for gen9, but this also
fixes some bugs we haven't carried over, like using recommended
precharge and timeout values.

Also I noticed that we don't set the fastwake sync length on skl, and
that's used by PSR2 selective updates. Fix that.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-6-git-send-email-daniel.vetter@ffwll.ch

drm/i915/psr: Order DP aux transactions correctly

On bdw/hsw we have a separate psr dp aux registers to set up, but on
bdw it's shared with the main dp aux thing. Which means any subsequent
dp aux transaction will trample over it, and hence must be done
beforehand.

Also this means we can't do any dp aux transactions while PSR is
active, or at least we must restore the old state.

Probably need a psr disable/enable pair around dp aux transactions in
general.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-5-git-send-email-daniel.vetter@ffwll.ch

drm/i915/psr: Make idle_frames sensible again

This reverts

commit dfaf37baa07513d2c37afff79978807d2d10221a
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Mon Dec 7 14:45:20 2015 -0800

    drm/i915: Fix idle_frames counter.

and

commit 97173eaf5f33b1e85efdb06d593d333480b60bf3
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Tue Jul 7 16:28:55 2015 -0700

    drm/i915: PSR: Increase idle_frames

and implements

commit d44b4dcbd1b44737462b77971d216d21a9413341
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Fri Nov 14 08:52:31 2014 -0800

    drm/i915: HSW/BDW PSR Set idle_frames = VBT + 1

without the hack to use 2 idle frames when VBT says 1. We keep the + 1
just for safety, although I haven't really figured out why that one
exists.

It's nonsense. idle_frames = number of frames where the screen is
entirely idle before we think about entering PSR.

idle_patter = part of link training, and we probably totally butchered
link training because we told the hw to entirely skip it. No wonder
PSR occasionally just fell over.

I suspect the reason we've increased idle frames is that it makes PSR
entry slightly less likely, and more likely to happen in a quite
system, which probably increased the changes the panel came back up
without link training. The proper fix is to implement link training
for PSR.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-3-git-send-email-daniel.vetter@ffwll.ch

drm/i915/psr: Try to program link training times correctly

The default of 0 is 500us of link training, but that's not enough for
some platforms. Decoding this correctly means we're using 2.5ms of
link training on these platforms, which fixes flickering issues
associated with enabling PSR.

v2: Unbotch the math a bit.

v3: Drop debug hunk.

v4: Improve commit message.

Tested-by: Lyude <cpaul@redhat.com>
Cc: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: fritsch@kodi.tv
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463590036-17824-2-git-send-email-daniel.vetter@ffwll.ch

drm/i915/userptr: Convert to drm_i915_private

userptr directly only uses drm_device in a single interface where it
meant to use drm_i915_private (everywhere else we have to derive it from
the drm_i915_gem_object and so require going from drm_device).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463671036-3235-1-git-send-email-chris@chris-wilson.co.uk

drm/i915: Allow nonblocking update of pageflips.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-22-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Check for unpin correctness.

If planes are added to the state after the call to
drm_atomic_helper_check_planes planes_changed may not be set
and we will not unpin the old framebuffer. This results in a
pin leak long after the framebuffer is destroyed, so to find
this add some checks when it happens.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-21-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates"

This reapplies commit acf4e84d6167317ff21be5c03e1ea76ea5783701.
With async unpin this should no longer break.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-20-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Make unpin async.

All of intel_post_plane_update is handled there now, so move it over.
This is run after the hw state checker because it can't handle checking
crtc's separately yet.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-19-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Prepare connectors for nonblocking checks.

intel_unpin_work may not take the list lock because it requires the connector_mutex.
To prevent taking locks we add an array of old and new state. The old state to free,
the new state to commit and verify.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-18-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Pass atomic states to fbc update functions.

This is required to let fbc updates run async. It has a lot of
checks whether certain locks are taken, which can be removed when
the relevant states are passed in as pointers.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-17-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Remove reset_counter from intel_crtc.

With the removal of cs-based flips all mmio waits will
finish without requiring the reset counter, because the
waits will complete during gpu reset.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-16-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Remove queue_flip pointer.

With the removal of cs support this is no longer reachable.
Can be revived if needed.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-15-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Remove use_mmio_flip kernel parameter.

With the removal of cs flips this is always force enabled.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-14-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Remove cs based page flip support.

With mmio flips now available on all platforms it's time to remove
support for cs flips.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-13-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.

Create a work structure that will be used for all changes. This will
be used later on in the atomic commit function.

Changes since v1:
- Free old_crtc_state from unpin_work_fn properly.
Changes since v2:
- Add hunk for calling hw state verifier.
- Add missing support for color spaces.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-12-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Add the exclusive fence to plane_state.

Set plane_state->base.fence to the dma_buf exclusive fence,
and add a wait to the mmio function. This will make it easier
to unify plane updates later on.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-11-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Convert flip_work to a list.

This will be required to allow more than 1 update in the future.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-10-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Allow mmio updates on all platforms, v2.

With intel_pipe_update begin/end we ensure that the mmio updates
don't run during vblank interrupt, using the hw counter we can
be sure that when current vblank count != vblank count at the time
of pipe_update_end the mmio update is complete.

This allows us to use mmio updates on all platforms, using the
update_plane call.

With Chris Wilson's patch to skip waiting for vblanks for
legacy_cursor_update this potentially leaves a small race
condition, in which update_plane can be called with a freed
crtc_state. Because of this commit acf4e84d61673
("drm/i915: Avoid stalling on pending flips for legacy cursor updates")
is temporarily reverted.

Changes since v1:
- Split out the flip_work rename.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-9-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates"

This reverts commit acf4e84d6167317ff21be5c03e1ea76ea5783701.
Unfortunately this breaks the next commit with a use-after-free, so
temporarily revert until we can apply a solution.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-8-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Unify unpin_work and mmio_work into flip_work, v2.

Rename intel_unpin_work to intel_flip_work and use it for mmio flips
and unpinning. Use flip_queued_req to hold the wait request in the
mmio case, and the vblank counter from intel_crtc_get_vblank_counter.

MMIO flips get their own path through intel_finish_page_flip_mmio,
handled on vblank. CS page flips go through *_cs.

Changes since v1:
- Clean up destinction between MMIO and CS flips.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-7-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Add support for detecting vblanks when hw frame counter is unavailable.

This uses the newly created drm_accurate_vblank_count_and_time to accurately
get a vblank count when the hw counter is unavailable.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-6-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Remove intel_prepare_page_flip, v3.

Instead of calling prepare_flip right before calling finish_page_flip
do everything from prepare_page_flip in finish_page_flip.

Putting prepare and finish page_flip in a single step removes the need
for INTEL_FLIP_COMPLETE, so it can be removed. This simplifies the code
slightly.

Changes since v1:
- Invert if case to simplify code.
- Add missing barrier.
- Reword commit message.
Changes since v2:
- intel_page_flip_plane is removed.
- work->pending is turned into a bool.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-5-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Remove intel_finish_page_flip_plane.

This function is duplicated with intel_finish_page_flip,
and is only ever used from planes that could use the
other function anyway.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-4-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/i915: Remove stallcheck special handling, v3.

Both intel_unpin_work.pending and intel_unpin_work.enable_stall_check
were used to see if work should be enabled. By only using pending
some special cases are gone, and access to unpin_work can be simplified.

A flip could previously be queued before
stallcheck was active. With the addition of the pending member
enable_stall_check became obsolete and can thus be removed.

Use this to only access work members untilintel_mark_page_flip_active
is called, or intel_queue_mmio_flip is used. This will prevent
use-after-free, and makes it easier to verify accesses.

Changes since v1:
- Reword commit message.
- Do not access unpin_work after intel_mark_page_flip_active.
- Add the right memory barriers.
Changes since v2:
- atomic_read() needs a full smp_rmb.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-3-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>

drm/core: Add drm_accurate_vblank_count, v5.

This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Changes since v1:
- Take vblank_time_lock and don't use drm_vblank_count_and_time.
Changes since v2:
- Don't return time of last vblank.
Changes since v3:
- Change pipe to unsigned int. (Ville)
- Remove unused documentation for tv_ret. (kbuild)
Changes since v4:
- Add warning to docs when the function is useful.
- Add a WARN_ON when get_vblank_timestamp is unavailable.
- Use drm_vblank_count.

Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v4
Acked-by: David Airlie <airlied@linux.ie> #irc, v4
Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-2-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>

drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM

This patch resizes the GuC WOPCM (specifically on BXT)
so that the GuC and RC6 memory spaces do not overlap.

v2:
    Made calculation of WOPCM size into a separate function,
    so that it's consistent between the firmware size-check
    and the register-programming operations [Dave Gordon].

Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
Signed-off-by: Peter Antoine <peter.antoine@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com>
Tested-by: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463494365-26330-1-git-send-email-david.s.gordon@intel.com

drm/i915: Simplify control flow in intel_atomic_check a bit.

- Unconditionally add plane states. Core helpers would have done this
  in drm_atomic_helper_check_modeset, doing it once more won't cause
  harm and is less fragile.

- Simplify the continue logic when disabling a pipe.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1462779085-2458-1-git-send-email-daniel.vetter@ffwll.ch

drm/i915/dsi: CABC support for Panel PWM backlight control

In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.

The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion here assumes that the
panels use standard SW register for control.

CABC is supported only when the PWM source for backlight is
from the panel.

v2 by Jani: rebase, renames, check cabc support earlier, etc.

Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/883faade74d2e598b143221ccc7df6daf4393a13.1461676337.git.jani.nikula@intel.com

drm/i915/dsi: Add DCS control for Panel PWM

If the source of the backlight PWM is from the
panel then the PWM can be controlled by DCS
command, this patch adds the support to
enable/disbale panel PWM, control backlight level
etc...

v2: Moving the CABC bkl functions to new file.(Jani)

v3: Rebase

v4: Rebase

v5: Use mipi_dsi_dcs_write() instead of mipi_dsi_dcs_write_buffer() (Jani)
    Move DCS macro`s to include/video/mipi_display.h (Jani)

v6: Rename the file to intel_dsi_panel_pwm.c
    Removing the CABC operations

v7 by Jani: renames, rebases, etc.

v8 by Jani: s/INTEL_BACKLIGHT_CABC/INTEL_BACKLIGHT_DSI_DCS/

v9 by Jani: rename init function to intel_dsi_dcs_init_backlight_funcs

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: Deepak M <m.deepak@intel.com>
Reviewed-by: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/71238a4b14b8c3a6c04070c789f09f1b4bc00a15.1461676337.git.jani.nikula@intel.com

Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queued

Backmerge request by Jani to get at

commit 249c4f538b1aae55d41699f8bafc6cb762a7f48f
Author: Deepak M <m.deepak@intel.com>
Date:   Wed Mar 30 17:03:39 2016 +0300

    drm: Add new DCS commands in the enum list

Some simple conflicts in intel_dp.c.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Merge tag 'topic/drm-misc-2016-05-13' of git://anongit.freedesktop.org/drm-intel into drm-next

I kinda hoped that I could still sneak in Noralf's
drm_simple_display_pipe, since there's intereset by others now (for tilcdc
at least). But it wasn't ready by a hair. Oh well.

Otherwise random stuff plus prep patches from Noralf.

* tag 'topic/drm-misc-2016-05-13' of git://anongit.freedesktop.org/drm-intel:
  drm/atomic: Add drm_atomic_helper_best_encoder()
  drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs
  drm/fb-cma-helper: Hook up to DocBook and fix some docs
  drm/fb-helper: Remove mention of CONFIG_FB_DEFERRED_IO in docs
  drm/sti: include linux/seq_file.h where needed
  drm/tegra: Use lockless gem BO free callback
  drm/exynos: Use lockless gem BO free callback
  drm: Make drm_encoder_helper_funcs optional

Merge branch 'topic-arcpgu-updates' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux into drm-next

Please pull this mini-series that allows ARC PGU to use
dedicated memory location as framebuffer backing storage.

* 'topic-arcpgu-updates' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux:
  ARC: [axs10x] Specify reserved memory for frame buffer
  drm/arcpgu: use dedicated memory area for frame buffer

drm/i915: don't mix bitwise and logical operations for has_snoop

Also make the code more readable.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463148278-23193-2-git-send-email-jani.nikula@intel.com

drm/i915: Skip clearing the GGTT on full-ppgtt systems

Under full-ppgtt, access to the global GTT is carefully regulated
through hardware functions (i.e. userspace cannot read and write to
arbitrary locations in the GGTT via the GPU). With this restriction in
place, we can forgo clearing stale entries from the GGTT as they will
not be accessed.

For aliasing-ppgtt, we could almost do the same except that we do allow
userspace access to the global-GTT via execbuf in order to workraound
some quirks of certain instructions. (This execbuf path is filtered out
with EINVAL on full-ppgtt.)

The most dramatic effect this will have will be during resume, as with
full-ppgtt the GGTT is only used sparingly.

References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Weinehall <david.weinehall@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Tested-by: David Weinehall <david.weinehall@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1463207195-22076-4-git-send-email-chris@chris-wilson.co.uk