Turns out
commit a0562819 ("drm/i915: Get panel_type from OpRegion panel
details") has regressed quite a few machines. So it looks like we
can't use the panel type from OpRegion on all systems, and yet we
absolutely must use it on some specific systems.

Despite trying, I was unable to find any automagic way to determine
if the OpRegion panel type is respectable or not. The only glimmer
of hope I had was bit 8 in the SCIC response, but that turned out to
not work either (it was always 0 on both types of systems).

So, to fix the regressions without breaking the machine we know to need
the OpRegion panel type, let's just add a quirk for this. Only specific
machines known to require the OpRegion panel type will therefore use
it. Everyone else will fall bck to the VBT panel type.

The only known machine so far is a "Conrac GmbH IX45GM2". The PCI
subsystem ID on this machine is just a generic 8086:2a42, so of no use.
Instead we'll go with a DMI match.

I suspect we can now also revert
commit aeddda06 ("drm/i915: Ignore panel type from OpRegion on SKL")
but let's leave that to a separate patch.

v2: Do the DMI match in the opregion code directly, as dev_priv->quirks
    gets populated too late

Cc: Rob Kramer <rob@solution-space.com>
Cc: Martin van Es <martin@mrvanes.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Marco Krüger <krgsch@gmail.com>
Cc: Sean Greenslade <sean@seangreenslade.com>
Cc: Trudy Tective <bertslany@gmail.com>
Cc: Robin Müller <rm1990@gmx.de>
Cc: Alexander Kobel <a-kobel@a-kobel.de>
Cc: Alexey Shumitsky <alexey.shumitsky@gmail.com>
Cc: Emil Andersen Lauridsen <mine809@gmail.com>
Cc: oceans112@gmail.com
Cc: James Hogan <james@albanarts.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: stable@vger.kernel.org
References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html
References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html
References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363
Fixes: a0562819 ("drm/i915: Get panel_type from OpRegion panel details")
Tested-by: NMarco Krüger <krgsch@gmail.com>
Tested-by: NAlexey Shumitsky <alexey.shumitsky@gmail.com>
Tested-by: NSean Greenslade <sean@seangreenslade.com>
Tested-by: NEmil Andersen Lauridsen <mine809@gmail.com>
Tested-by: NRobin Müller <rm1990@gmx.de>
Tested-by: oceans112@gmail.com
Tested-by: NRob Kramer <rob@solution-space.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473758539-21565-1-git-send-email-ville.syrjala@linux.intel.com
References: http://patchwork.freedesktop.org/patch/msgid/1473602239-15855-1-git-send-email-adrienverge@gmail.comAcked-by: NJani Nikula <jani.nikula@intel.com>
(cherry picked from commit c8ebfad7)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts

commit 1c80c25f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed May 18 18:47:12 2016 +0200

    drm/i915/psr: Make idle_frames sensible again

There are panels that needs 4 idle frames before entering PSR,
but VBT is unproperly set.

Also lately it was identified that idle frame count calculated at HW
can be off by 1, what makes the minimum of 2, at least.

Without the current vbt+1 we are with the risk of having HW calculating
0 idle frames and entering PSR when it shouldn't. Regardless the lack
of link training.

[Jani: there is some disagreement on the explanation, but the commit
regresses so revert it is.]

References: http://marc.info/?i=20160904191153.GA2328@light.dominikbrodowski.net
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: 1c80c25f ("drm/i915/psr: Make idle_frames sensible again")
Cc: drm-intel-fixes@lists.freedesktop.org # v4.8-rc1+
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473295351-8766-1-git-send-email-rodrigo.vivi@intel.com
(cherry picked from commit 40918e0b)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

A side effect of removing the midlayer from driver loading was the loss
of a useful message announcing to userspace that i915 had successfully
started, e.g.:

	[drm] Initialized i915 1.6.0 20160425 for 0000:00:02.0 on minor 0
Reported-by: NTimo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: 8f460e2c ("drm/i915: Demidlayer driver loading")
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/20160825072314.17402-1-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit bc5ca47c)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

According to the CI test machines, SNB also uses the
GEN7_PCODE_MIN_FREQ_TABLE_GT_RATIO_OUT_OF_RANGE value to report a bad
GEN6_PCODE_MIN_FREQ_TABLE request.

[  157.744641] WARNING: CPU: 5 PID: 9238 at
drivers/gpu/drm/i915/intel_pm.c:7760 sandybridge_pcode_write+0x141/0x200 [i915]
[  157.744642] Missing switch case (16) in gen6_check_mailbox_status
[  157.744642] Modules linked in: snd_hda_intel i915 ax88179_178a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me lpc_ich snd_pcm mei broadcom bcm_phy_lib tg3 ptp pps_core [last unloaded: vgem]
[  157.744658] CPU: 5 PID: 9238 Comm: drv_hangman Tainted: G     U  W 4.8.0-rc3-CI-CI_DRM_1589+ #1
[  157.744658] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
[  157.744659]  0000000000000000 ffff88011f093a98 ffffffff81426415 ffff88011f093ae8
[  157.744662]  0000000000000000 ffff88011f093ad8 ffffffff8107d2a6 00001e50810d3c9f
[  157.744663]  ffff880128680000 0000000000000008 0000000000000000 ffff88012868a650
[  157.744665] Call Trace:
[  157.744669]  [<ffffffff81426415>] dump_stack+0x67/0x92
[  157.744672]  [<ffffffff8107d2a6>] __warn+0xc6/0xe0
[  157.744673]  [<ffffffff8107d30a>] warn_slowpath_fmt+0x4a/0x50
[  157.744685]  [<ffffffffa0029831>] sandybridge_pcode_write+0x141/0x200 [i915]
[  157.744697]  [<ffffffffa002a88a>] intel_enable_gt_powersave+0x64a/0x1330 [i915]
[  157.744712]  [<ffffffffa006b4cb>] ? i9xx_emit_request+0x1b/0x80 [i915]
[  157.744725]  [<ffffffffa0055ed3>] __i915_add_request+0x1e3/0x370 [i915]
[  157.744738]  [<ffffffffa00428bd>] i915_gem_do_execbuffer.isra.16+0xced/0x1b80 [i915]
[  157.744740]  [<ffffffff811a232e>] ? __might_fault+0x3e/0x90
[  157.744752]  [<ffffffffa0043b72>] i915_gem_execbuffer2+0xc2/0x2a0 [i915]
[  157.744753]  [<ffffffff815485b7>] drm_ioctl+0x207/0x4c0
[  157.744765]  [<ffffffffa0043ab0>] ? i915_gem_execbuffer+0x360/0x360 [i915]
[  157.744767]  [<ffffffff810ea4ad>] ?  debug_lockdep_rcu_enabled+0x1d/0x20
[  157.744769]  [<ffffffff811fe09e>] do_vfs_ioctl+0x8e/0x680
[  157.744770]  [<ffffffff811a2377>] ? __might_fault+0x87/0x90
[  157.744771]  [<ffffffff811a232e>] ? __might_fault+0x3e/0x90
[  157.744773]  [<ffffffff810d3df2>] ?  trace_hardirqs_on_caller+0x122/0x1b0
[  157.744774]  [<ffffffff811fe6cc>] SyS_ioctl+0x3c/0x70
[  157.744776]  [<ffffffff8180fe69>] entry_SYSCALL_64_fastpath+0x1c/0xac

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97491
Fixes: 87660502 ("drm/i915/gen6+: Interpret mailbox error flags")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/20160826105926.3413-1-chris@chris-wilson.co.ukAcked-by: NMika Kuoppala <mika.kuoppala@intel.com>
(cherry picked from commit 7850d1c3)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Disable 48bit full PPGTT on vGPU too for now.
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160906040412.1274-3-zhenyuw@linux.intel.com
(cherry picked from commit e320d400)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

vGPU capability is handled by GVT-g host driver, not needed to
put extra HW check for vGPU detection. And we'll actually support
vGPU from BDW.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160906040412.1274-2-zhenyuw@linux.intel.com
(cherry picked from commit 8ef89995)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If we hit the error path, we have never called drm_encoder_init() and so
have nothing to cleanup. Doing so hits a null dereference:

[   10.066261] BUG: unable to handle kernel NULL pointer dereference at 00000104
[   10.066273] IP: [<c16054b4>] mutex_lock+0xa/0x15
[   10.066287] *pde = 00000000
[   10.066295] Oops: 0002 [#1]
[   10.066302] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm iTCO_wdt iTCO_vendor_support ppdev evdev snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm snd_timer snd pcspkr uhci_hcd ehci_pci soundcore sr_mod ehci_hcd serio_raw i2c_i801 usbcore i2c_smbus cdrom lpc_ich mfd_core rng_core e100 mii floppy parport_pc parport acpi_cpufreq button processor usb_common eeprom lm85 hwmon_vid autofs4
[   10.066378] CPU: 0 PID: 132 Comm: systemd-udevd Not tainted 4.8.0-rc3-00013-gef0e1ea8 #34
[   10.066389] Hardware name: MicroLink                               /D865GLC                        , BIOS BF86510A.86A.0077.P25.0508040031 08/04/2005
[   10.066401] task: f62db800 task.stack: f5970000
[   10.066409] EIP: 0060:[<c16054b4>] EFLAGS: 00010286 CPU: 0
[   10.066417] EIP is at mutex_lock+0xa/0x15
[   10.066424] EAX: 00000104 EBX: 00000104 ECX: 00000000 EDX: 80000000
[   10.066432] ESI: 00000000 EDI: 00000104 EBP: f5be8000 ESP: f5971b58
[   10.066439]  DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
[   10.066446] CR0: 80050033 CR2: 00000104 CR3: 35945000 CR4: 000006d0
[   10.066453] Stack:
[   10.066459]  f503d740 f824dddf 00000000 f61170c0 f61170c0 f82371ae f850f40e 00000001
[   10.066476]  f61170c0 f5971bcc f5be8000 f9c2d401 00000001 f8236fcc 00000001 00000000
[   10.066491]  f5144014 f5be8104 00000008 f9c5267c 00000007 f61170c0 f5144400 f9c4ff00
[   10.066507] Call Trace:
[   10.066526]  [<f824dddf>] ? drm_modeset_lock_all+0x27/0xb3 [drm]
[   10.066545]  [<f82371ae>] ? drm_encoder_cleanup+0x1a/0x132 [drm]
[   10.066559]  [<f850f40e>] ? drm_atomic_helper_connector_reset+0x3f/0x5c [drm_kms_helper]
[   10.066644]  [<f9c2d401>] ? intel_dvo_init+0x569/0x788 [i915]
[   10.066663]  [<f8236fcc>] ? drm_encoder_init+0x43/0x20b [drm]
[   10.066734]  [<f9bf1fce>] ? intel_modeset_init+0x1436/0x17dd [i915]
[   10.066791]  [<f9b37636>] ? i915_driver_load+0x85a/0x15d3 [i915]
[   10.066846]  [<f9b3603d>] ? i915_driver_open+0x5/0x5 [i915]
[   10.066857]  [<c14af4d0>] ? firmware_map_add_entry.part.2+0xc/0xc
[   10.066868]  [<c1343daf>] ? pci_device_probe+0x8e/0x11c
[   10.066878]  [<c140cec8>] ? driver_probe_device+0x1db/0x62e
[   10.066888]  [<c120c010>] ? kernfs_new_node+0x29/0x9c
[   10.066897]  [<c13438e0>] ? pci_match_device+0xd9/0x161
[   10.066905]  [<c120c48b>] ? kernfs_create_dir_ns+0x42/0x88
[   10.066914]  [<c140d401>] ? __driver_attach+0xe6/0x11b
[   10.066924]  [<c1303b13>] ? kobject_add_internal+0x1bb/0x44f
[   10.066933]  [<c140d31b>] ? driver_probe_device+0x62e/0x62e
[   10.066941]  [<c140a2d2>] ? bus_for_each_dev+0x46/0x7f
[   10.066950]  [<c140c502>] ? driver_attach+0x1a/0x34
[   10.066958]  [<c140d31b>] ? driver_probe_device+0x62e/0x62e
[   10.066966]  [<c140b758>] ? bus_add_driver+0x217/0x32a
[   10.066975]  [<f8403000>] ? 0xf8403000
[   10.066982]  [<c140de27>] ? driver_register+0x5f/0x108
[   10.066991]  [<c1000493>] ? do_one_initcall+0x49/0x1f6
[   10.067000]  [<c1082299>] ? pick_next_task_fair+0x14b/0x2a3
[   10.067008]  [<c1603c8d>] ? __schedule+0x15c/0x4fe
[   10.067016]  [<c1604104>] ? preempt_schedule_common+0x19/0x3c
[   10.067027]  [<c11051de>] ? do_init_module+0x17/0x230
[   10.067035]  [<c1604139>] ? _cond_resched+0x12/0x1a
[   10.067044]  [<c116f9aa>] ? kmem_cache_alloc+0x8f/0x11f
[   10.067052]  [<c11051de>] ? do_init_module+0x17/0x230
[   10.067060]  [<c11703dd>] ? kfree+0x137/0x203
[   10.067068]  [<c110523d>] ? do_init_module+0x76/0x230
[   10.067078]  [<c10cadf3>] ? load_module+0x2a39/0x333f
[   10.067087]  [<c10cb8b2>] ? SyS_finit_module+0x96/0xd5
[   10.067096]  [<c1132231>] ? vm_mmap_pgoff+0x79/0xa0
[   10.067105]  [<c1001e96>] ? do_fast_syscall_32+0xb5/0x1b0
[   10.067114]  [<c16086a6>] ? sysenter_past_esp+0x47/0x75
[   10.067121] Code: c8 f7 76 c1 e8 8e cc d2 ff e9 45 fe ff ff 66 90 66 90 66 90 66 90 90 ff 00 7f 05 e8 4e 0c 00 00 c3 53 89 c3 e8 75 ec ff ff 89 d8 <ff> 08 79 05 e8 fa 0a 00 00 5b c3 53 89 c3 85 c0 74 1b 8b 03 83
[   10.067180] EIP: [<c16054b4>] mutex_lock+0xa/0x15 SS:ESP 0068:f5971b58
[   10.067190] CR2: 0000000000000104
[   10.067222] ---[ end trace 049f1f09da45a856 ]---
Reported-by: NMeelis Roos <mroos@linux.ee>
Fixes: 580d8ed5 ("drm/i915: Give encoders useful names")
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160823092558.14931-1-chris@chris-wilson.co.uk
(cherry picked from commit 8f76aa0e)

Merge commit 5e580523 reverts the version bumping parts of
commit 4aa7fb9c. Bump the versions again and request the specific
firmware version.

The currently recommended versions are: SKL 1.26, KBL 1.01 and BXT 1.07.

Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97242
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 5e580523 ("Backmerge tag 'v4.7' into drm-next")
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471266567-22443-1-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
(cherry picked from commit 536ab3ca)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul@redhat.com
(cherry picked from commit 05a76d3d)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw.  However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.

This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes.  Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).

Changes since v1:
 - Add a function for copying a pipe's wm values
   (skl_copy_wm_for_pipe()) so we can reuse this later

Fixes: 734fa01f ("drm/i915/gen9: Calculate watermarks during atomic 'check' (v2)")
Fixes: 9b613022 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-4-git-send-email-cpaul@redhat.com
(cherry picked from commit 2722efb9)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV	with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

This will still need additional work in the future: we shouldn't be
enabling the SAGV if any of the currently enabled planes can't enable WM
levels that introduce latencies >= 30 µs.

Changes since v11:
 - Add skl_can_enable_sagv()
 - Make sure we don't enable SAGV when not all planes can enable
   watermarks >= the SAGV engine block time. I was originally going to
   save this for later, but I recently managed to run into a machine
   that was having problems with a single pipe configuration + SAGV.
 - Make comparisons to I915_SKL_SAGV_NOT_CONTROLLED explicit
 - Change I915_SAGV_DYNAMIC_FREQ to I915_SAGV_ENABLE
 - Move printks outside of mutexes
 - Don't print error messages twice
Changes since v10:
 - Apparently sandybridge_pcode_read actually writes values and reads
   them back, despite it's misleading function name. This means we've
   been doing this mostly wrong and have been writing garbage to the
   SAGV control. Because of this, we no longer attempt to read the SAGV
   status during initialization (since there are no helpers for this).
 - mlankhorst noticed that this patch was breaking on some very early
   pre-release Skylake machines, which apparently don't allow you to
   disable the SAGV. To prevent machines from failing tests due to SAGV
   errors, if the first time we try to control the SAGV results in the
   mailbox indicating an invalid command, we just disable future attempts
   to control the SAGV state by setting dev_priv->skl_sagv_status to
   I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg.
 - Move mutex_unlock() a little higher in skl_enable_sagv(). This
   doesn't actually fix anything, but lets us release the lock a little
   sooner since we're finished with it.
Changes since v9:
 - Only enable/disable sagv on Skylake
Changes since v8:
 - Add intel_state->modeset guard to the conditional for
   skl_enable_sagv()
Changes since v7:
 - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
   all we use it for anyway)
 - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
 - Fix a styling error that snuck past me
Changes since v6:
 - Protect skl_enable_sagv() with intel_state->modeset conditional in
   intel_atomic_commit_tail()
Changes since v5:
 - Don't use is_power_of_2. Makes things confusing
 - Don't use the old state to figure out whether or not to
   enable/disable the sagv, use the new one
 - Split the loop in skl_disable_sagv into it's own function
 - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
 - Use time_before() to compare timeout to jiffies
Changes since v2:
 - Really apply minor style nitpicks to patch this time
Changes since v1:
 - Added comments about this probably being one of the requirements to
   fixing Skylake's watermark issues
 - Minor style nitpicks from Matt Roper
 - Disable these functions on Broxton, since it doesn't have an SAGV
Signed-off-by: NLyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-3-git-send-email-cpaul@redhat.com
[mlankhorst: ENOSYS -> ENXIO, whitespace fixes]

(cherry picked from commit 656d1b89)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In order to add proper support for the SAGV, we need to be able to know
what the cause of a failure to change the SAGV through the pcode mailbox
was. The reasoning for this is that some very early pre-release Skylake
machines don't actually allow you to control the SAGV on them, and
indicate an invalid mailbox command was sent.

This also might come in handy in the future for debugging.

Changes since v1:
 - Add functions for interpreting gen6 mailbox error codes along with
   gen7+ error codes, and actually interpret those codes properly
 - Renamed patch to reflect new behavior
Signed-off-by: NLyude <cpaul@redhat.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-2-git-send-email-cpaul@redhat.com
[mlankhorst: -ENOSYS -> -ENXIO for checkpatch]

(cherry picked from commit 87660502)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In the recent patch
bc3d6744 drm/i915: Allow userspace to request no-error-capture upon ...
the final version moved the flags and the associated #defines around
so they were adjacent; unfortunately, they ended up between a comment
and the thing (hw_id) to which the comment applies :(

So this patch reshuffles the comment and subject back together.

Also, as we're touching 'hw_id', let's change it from just 'unsigned'
to a fully-specified 'unsigned int', because some code checking tools
(including checkpatch) object to plain 'unsigned'.

Fixes: bc3d6744 ("drm/i915: Allow userspace to request no-error-capture...")
Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1471616622-6919-1-git-send-email-david.s.gordon@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 0be81156)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If userspace is asynchronously streaming into the batch or other
execobjects, we may not flush those writes along with a change in cache
domain (as there is no change). Therefore those writes may end up in
internal chipset buffers and not visible to the GPU upon execution. We
must issue a flush command or otherwise we encounter incoherency in the
batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
regularly.

v2: Throw a paranoid wmb() into the general flush so that we remain
consistent with before.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
Fixes: 1816f923 ("drm/i915: Support creation of unbound wc user...")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Tested-by: NMatti Hämäläinen <ccr@tnsp.org>
Cc: stable@vger.kernel.org
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-1-chris@chris-wilson.co.uk
(cherry picked from commit 600f4368)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

It's possible to have a non-zero plane mask and still wind up with a
total data rate of zero.  There are two cases where this can happen:

 * planes are active (from the KMS point of view), but are
   all fully clipped (positioned offscreen)
 * the only active plane on a CRTC is the cursor (which is handled
   independently and not counted into the general data rate computations

These are both valid display setups (although unusual), so we need to
drop the WARN().
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Testcase: kms_universal_planes.cursor-only-pipe-*
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466196140-16336-4-git-send-email-matthew.d.roper@intel.com
Cc: stable@vger.kernel.org #v4.7+
(cherry picked from commit 43aa7e87)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

intel_state->active_crtcs is usually only initialized when doing a
modeset.  During our first atomic commit after boot, we're effectively
faking a modeset to sanitize the DDB/wm setup, so ensure that this field
gets initialized before use.

v2:
 - Don't clobber active_crtcs if our first commit really is a modeset
   (Maarten)
 - Grab connection_mutex when faking a modeset during sanitization
   (Maarten)
Reported-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1466196140-16336-2-git-send-email-matthew.d.roper@intel.com
Cc: stable@vger.kernel.org #v4.7+
(cherry picked from commit 1b54a880)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This function would call drm_modeset_lock_all, while the suspend/resume
functions already have their own locking. Fix this by factoring out
__intel_display_resume, and calling the atomic helpers for duplicating
atomic state and disabling all crtc's during suspend.

Changes since v1:
- Deal with -EDEADLK right after lock_all and clean up calls
  to hw readout.
- Always take all modeset locks so updates during gpu reset are blocked.
Changes since v2:
- Fix deadlock in intel_update_primary_planes.
- Move WARN_ON(EDEADLK) to __intel_display_resume.
- pctx -> ctx
- only call __intel_display_resume on success in intel_display_resume.
Changes since v3:
- Rebase on top of dev_priv -> dev change.
- Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
Changes since v4 [by vsyrjala]:
- Deal with skip_intermediate_wm
- Update comment w.r.t. mode_config.mutex vs. ->detect()
- Rebase due to INTEL_GEN() etc.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: stable@vger.kernel.org
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470428910-12125-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 73974893)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This
fixes the following kmemleak message:

unreferenced object 0xffff880213cca000 (size 8192):
  comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff817c808e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff8121f9c2>] kmem_cache_alloc_trace+0x142/0x1d0
    [<ffffffffa06d11ef>] i915_gem_init_ggtt+0x10f/0x210 [i915]
    [<ffffffffa06d71bb>] i915_gem_init+0x5b/0xd0 [i915]
    [<ffffffffa069749a>] i915_driver_load+0x97a/0x1460 [i915]
    [<ffffffffa06a26ef>] i915_pci_probe+0x4f/0x70 [i915]
    [<ffffffff81423015>] local_pci_probe+0x45/0xa0
    [<ffffffff81424463>] pci_device_probe+0x103/0x150
    [<ffffffff81515e6c>] driver_probe_device+0x22c/0x440
    [<ffffffff81516151>] __driver_attach+0xd1/0xf0
    [<ffffffff8151379c>] bus_for_each_dev+0x6c/0xc0
    [<ffffffff8151555e>] driver_attach+0x1e/0x20
    [<ffffffff81514fa3>] bus_add_driver+0x1c3/0x280
    [<ffffffff81516aa0>] driver_register+0x60/0xe0
    [<ffffffff8142297c>] __pci_register_driver+0x4c/0x50
    [<ffffffffa013605b>] 0xffffffffa013605b
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: b18b6bde ("drm/i915/bdw: Free PPGTT struct")
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470420280-21417-1-git-send-email-matthew.auld@intel.com
(cherry picked from commit cb7f2760)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

As pointed out by Chris Harris, we are using the wrong WA name, it
should in fact be WaToEnableHwFixForPushConstHWBug, also it should be
applied from C0 onwards for both BXT and KBL.

Fixes: 7b9005cd ("drm/i915: Add WaInsertDummyPushConstP for bxt and kbl")

Cc: Chris Harris <chris.harris@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reported-by: NChris Harris <chris.harris@intel.com>
Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470127013-29653-1-git-send-email-matthew.auld@intel.com
(cherry picked from commit 575e3ccb)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The spec was recently fixed to have the correct iboost setting for the
SKL Y/U DP DDI buffer translation table entry 2. Update our tables
to match.

Cc: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470140517-13011-1-git-send-email-ville.syrjala@linux.intel.com
Cc: stable@vger.kernel.org
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
(cherry picked from commit 5ac90567)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The bspec was updated a couple weeks ago to add an extra block per line
to plane watermark calculations for linear pixel formats.

Bspec update 115327 description:
  "Gen9+ - Updated the plane blocks per line calculation for linear
  cases. Adds +1 for all linear cases to handle the non-block aligned
  stride cases."

Cc: Lyude <cpaul@redhat.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470344880-27394-1-git-send-email-matthew.d.roper@intel.comReviewed-by: NLyude <cpaul@redhat.com>
(cherry picked from commit 055c3ff6)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display
power well and so the sna-hda audio codec acquires the display power
well while it is operational. However, Skylake separates the powerwells
again, but yet we still need the audio powerwell to setup the registers.
(But then the hardware uses those registers even while powered off???)

Acquiring the powerwell around setting the chicken bits when setting up
the audio channel does at least silence the WARNs from touching our
registers whilst unpowered. We silence our own test cases, but maybe
there is a latent bug in using the audio channel?

v2: Grab both rpm wakelock and audio wakelock

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214
Fixes: 03b135ce "ALSA: hda - remove dependency on i915 power well for SKL")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Libin Yang <libin.yang@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Marius Vlad <marius.c.vlad@intel.com>
Tested-by: NHans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/1470240540-29004-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit d838a110)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Joonas spotted a discrepancy between the pwrite and pread ioctls, in
that pwrite takes the rpm wakelock around its GGTT access, The wakelock
is required in order for the GTT to function. In disregard for the
current convention, we take the rpm wakelock around the access itself
rather than around the struct_mutex as the nesting is not strictly
required and such ordering will one day be fixed by explicitly noting
the barrier dependencies between the GGTT and rpm.

Fixes: b50a5371 ("drm/i915: Support for pread/pwrite ...")
Reported-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Link: http://patchwork.freedesktop.org/patch/msgid/1470298193-21765-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 1dd5b6f2)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are Enabled

"Display flickering may occur when both FBC (Frame Buffer Compression)
and VT - d (Intel® Virtualization Technology for Directed I/O) are enabled
and in use by the display controller."

Ville found the w/a name in the database:
WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt and also dug out that it
affects Broxton.

v2: Log when the quirk is applied.
v3: Ensure i915.enable_fbc is false when !HAS_FBC()
v4: Fix function name after rebase
v5: Add Broxton to the workaround

Note for backporting to stable, we need to add
  #define mkwrite_device_info(ptr) \
	((struct intel_device_info *)INTEL_INFO(ptr))
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/1470296633-20388-1-git-send-email-chris@chris-wilson.co.uk
(cherry picked from commit 36dbc4d7)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Remove the CHV early bail out from intel_cleanup_gt_powersave() so that
we'll clean up the extra RPM reference held due to i915.enable_rc6=0.

Cc: Imre Deak <imre.deak@intel.com>
Fixes: b268c699 ("drm/i915: refactor RPM disabling due to RC6 being disabled")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470136053-23276-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>
(cherry picked from commit 8dac1e1f)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Currently we fail to program the iboost stuff for HDMI/DVI. Let's remedy
that.

Cc: stable@vger.kernel.org
Fixes: f8896f5d ("drm/i915/skl: Buffer translation improvements")
Cc: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1468328376-6380-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
(cherry picked from commit 8d8bb85e)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Bspec says:
"For DDIA with x4 capability (DDI_BUF_CTL DDIA Lane Capability Control =
 DDIA x4), the I_boost value has to be programmed in both
 tx_blnclegsctl_0 and tx_blnclegsctl_4."

Currently we only program tx_blnclegsctl_0. Let's do the other one as
well.

Cc: stable@vger.kernel.org
Fixes: f8896f5d ("drm/i915/skl: Buffer translation improvements")
Cc: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1468328376-6380-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
(cherry picked from commit a7d8dbc0)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Even after adding individual page support for GTT mmaping, we can still
fail to find any space within the mappable region, and
drm_mm_insert_node() will then report ENOSPC. We have to then handle
this error by using the shmem access to the pages.

Fixes: b50a5371 ("drm/i915: Support for pread/pwrite ... objects")
Testcase: igt/gem_concurrent_blit
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com
Link: http://patchwork.freedesktop.org/patch/msgid/1468690956-23480-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit d1054ee4)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Upon resetting the GPU, we force the engines to be idle by clearing
their request lists. However, I neglected to clear the GT active status
and so the next request following the reset was not marking the device
as busy again. (We had to wait until any outstanding retire worker
finally ran and cleared the active status.)

Fixes: 67d97da3 ("drm/i915: Only start retire worker when idle")
Testcase: igt/pm_rps/reset
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1468397438-21226-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit b913b33c)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This reverts commit 013dd9e0
("drm/i915/dp: fall back to 18 bpp when sink capability is unknown")

This commit introduced a regression into stable kernels,
as it reduces output color depth to 6 bpc for any video
sink connected to a Displayport connector if that sink
doesn't report a specific color depth via EDID, or if
our EDID parser doesn't actually recognize the proper
bpc from EDID.

Affected are active DisplayPort->VGA converters and
active DisplayPort->DVI converters. Both should be
able to handle 8 bpc, but are degraded to 6 bpc with
this patch.

The reverted commit was meant to fix
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331

A followup patch implements a fix for that specific bug,
which is caused by a faulty EDID of the affected DP panel
by adding a new EDID quirk for that panel.

DP 18 bpp fallback handling and other improvements to
DP sink bpc detection will be handled for future
kernels in a separate series of patches.

Please backport to stable.
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the fbdev probing fails, and in our error path we fail to clear the
dev_priv->fbdev, then we can try and use a dangling fbdev pointer, and
in particular a NULL fb. This could also happen in pathological cases
where we try to operate on the fbdev prior to it being probed.
Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1468431285-28264-2-git-send-email-chris@chris-wilson.co.ukReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
(cherry picked from commit 6bc26542)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This clearly had never gotten tested, probably because you need a fairly
minimal configuration in order to disable DEBUG_FS (several other
options select it).

The dummy inline functions that were used for the no-DEBUG_FS case were
missing the argument names in the declarations.

Fixes: 1dac891c ("drm/i915: Register debugfs interface last")
Reported-and-tested-by: NJörg Otte <jrg.otte@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Bspec says:
"Restriction : SRD must not be enabled when the PSR Setup time from DPCD
00071h is greater than the time for vertical blank minus one line."

Let's check for that and disallow PSR if we exceed the limit.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck
in an infinite batch buffer loop. The GPU apparently hogs something
critical and CPUs start to lose interrupts and whatnot. We can keep
the system limping along by unmasking some interrupts in
GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for
that task, so let's never mask it.

v2: s/gen6_rps_pm_mask/gen6_sanitize_rps_pm_mask/ (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93122Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1464014568-4529-1-git-send-email-ville.syrjala@linux.intel.com
Cc: stable@vger.kernel.org
(cherry picked from commit 12c100bf)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bspec tells us to keep bashing the PCU for up to 3ms when trying to
inform it about an upcoming change in the cdclk frequency. Currently
we only keep at it for 15*10usec (+ whatever delays gets added by
the sandybridge_pcode_read() itself). Let's change the limit to 3ms.

I decided to keep 10 usec delay per iteration for now, even though
the spec doesn't really tell us to do that.

Cc: stable@vger.kernel.org
Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume")
Cc: David Weinehall <david.weinehall@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1468416723-23440-1-git-send-email-ville.syrjala@linux.intel.comTested-by: NDavid Weinehall <david.weinehall@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 848496e5)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some of our "for_each_xyz()" macro constructs make gcc unhappy about
lack of braces around if-statements inside or outside the loop, because
the loop construct itself has a "if-then-else" statement inside of it.

The resulting warnings look something like this:

  drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dump_lrc’:
  drivers/gpu/drm/i915/i915_debugfs.c:2103:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wparentheses]
     if (ctx != dev_priv->kernel_context)
        ^

even if the code itself is fine.

Since the warning is fairly easy to avoid by adding a braces around the
if-statement near the for_each_xyz() construct, do so, rather than
disabling the otherwise potentially useful warning.

(The if-then-else statements used in the "for_each_xyz()" constructs are
designed to be inherently safe even with no braces, but in this case
it's quite understandable that gcc isn't really able to tell that).

This finally leaves the standard "allmodconfig" build with just a
handful of remaining warnings, so new and valid warnings hopefully will
stand out.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add this workaround to prevent hang when in place compression
is used.

References: HSD#2135774
Cc: stable@vger.kernel.org
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 4ba9c1f7)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit 041824ee.

We have latency issues that might impact the performance: #96606.
and hangs and loading issues on resume after S4: #96526.

This is also blocking a platform milestone so let's disable
this for now while we make sure we don't have any more loading
issue, or related basic hangs and it pass BAT for real in all
platofmrs.

In case BAT is wrong let's first fix BAT before re-enable it here.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96606
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96526
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Christophe Prigent <christophe.prigent@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1468884477-30086-1-git-send-email-rodrigo.vivi@intel.com
(cherry picked from commit fe993bc9)
[danvet: Drop cc: stable since this is for 4.8 only.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Setting a write-back cache policy in the MOCS entry definition also
implies snooping, which has a considerable overhead. This is
unexpected for a few reasons:
- From user-space's point of view since it didn't want a coherent
  surface (it didn't set the buffer as such via the set caching IOCTL).
- There is a separate MOCS entry field for snooping (which we never
  set).
- This MOCS table is about caching in (e)LLC and there is no (e)LLC on
  BXT. There is a separate table for L3 cache control.

Considering the above the current behavior of snooping looks like an
unintentional side-effect of the WB setting. Changing it to be LLC-UC
gets rid of the snooping without any ill-effects. For a coherent
surface the application would use a separate MOCS entry at index 1 and
call the set caching IOCTL to setup the PTE entries for the
corresponding buffer to be snooped. In the future we could also add a
new MOCS entry for coherent surfaces.

This resulted in 70% improvement in synthetic texturing benchmarks.

Kudos to Valtteri Rantala, Eero Tamminen and Michael T Frederick and
Ville who helped to narrow the source of problem to the kernel and to
the snooping behaviour in particular.

With a follow-up change to adjust the 3rd entry value
igt/gem_mocs_settings is passing after this change.

v2:
- Rebase on v2 of patch 1/2.
v3:
- Set the entry as LLC uncached instead of PTE-passthrough. This way
  we also keep snooping disabled, but we also make the cacheability/
  coherency setting indepent of the PTE which is managed by the
  kernel. (Chris)

CC: Rong R Yang <rong.r.yang@intel.com>
CC: Yakui Zhao <yakui.zhao@intel.com>
CC: Valtteri Rantala <valtteri.rantala@intel.com>
CC: Eero Tamminen <eero.t.tamminen@intel.com>
CC: Michael T Frederick <michael.t.frederick@intel.com>
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Acked-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NRong R Yang <rong.r.yang@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1467380406-11954-3-git-send-email-imre.deak@intel.com
(cherry picked from commit 6bee14ed)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use named struct initializers for clarity. Also fix the target cache
definition to reflect its role in GEN9 onwards. On GEN8 a TC value of 0
meant ELLC but on GEN9+ it means the TC and LRU controls are taken from
the PTE.

No functional change, igt/gem_mocs_settings still passing after this
change.

v2: (Chris)
- Add back the hexa literals for the entries.
  Add note that igt/gem_mocs_settings still passes.

CC: Rong R Yang <rong.r.yang@intel.com>
CC: Yakui Zhao <yakui.zhao@intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Acked-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1467380406-11954-2-git-send-email-imre.deak@intel.com
(cherry picked from commit e419899b)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>