Catch up with upstream while it's easy.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Don't cast away the __iomem from the io_mapping functions so that
sparse won't be so unhappy when we pass the pointer to the unmap
functions. Instead let's move the cast to where we actually use the
pointer.

Fixes the following sparse warnings:
i915_gem.c:1022:33: warning: incorrect type in argument 1 (different address spaces)
i915_gem.c:1022:33:    expected void [noderef] <asn:2>*vaddr
i915_gem.c:1022:33:    got void *[assigned] vaddr
i915_gem.c:1027:34: warning: incorrect type in argument 1 (different address spaces)
i915_gem.c:1027:34:    expected void [noderef] <asn:2>*vaddr
i915_gem.c:1027:34:    got void *[assigned] vaddr
i915_gem.c:1199:33: warning: incorrect type in argument 1 (different address spaces)
i915_gem.c:1199:33:    expected void [noderef] <asn:2>*vaddr
i915_gem.c:1199:33:    got void *[assigned] vaddr
i915_gem.c:1204:34: warning: incorrect type in argument 1 (different address spaces)
i915_gem.c:1204:34:    expected void [noderef] <asn:2>*vaddr
i915_gem.c:1204:34:    got void *[assigned] vaddr

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

radix_tree_for_each_slot() wants an __rcu annotated pointer for the
slot. So let's add the annotation.

Fixes the following sparse warnings:
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**
i915_gem.c:2217:9: warning: incorrect type in argument 1 (different address spaces)
i915_gem.c:2217:9:    expected void [noderef] <asn:4>**slot
i915_gem.c:2217:9:    got void **slot
i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
i915_gem.c:2217:9:    expected void **slot
i915_gem.c:2217:9:    got void [noderef] <asn:4>**

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 96d77634 ("drm/i915: Use a radixtree for random access to the object's backing storage")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Our fbdev setup requires the device to be awake for access
through the GTT. If one boots without connected displays and
later plugs one in, we won't have any runtime PM references when
the fbdev setup runs. Explicitly grab a runtime PM reference during
the fbdev setup to avoid the following spew:

[   62.518435] RPM wakelock ref not held during HW access
[   62.518459] ------------[ cut here ]------------
[   62.518546] WARNING: CPU: 3 PID: 37 at ../drivers/gpu/drm/i915/intel_drv.h:1800 i915_vma_pin_iomap+0x144/0x150 [i915]
[   62.518585] Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole nls_iso8859_1 nls_cp437 vfat fat efi_pstore coretemp hwmon intel_rapl x86_pkg_temp_thermal e1000e efivars ptp pps_core video evdev ip_tables x_tables ipv6 autofs4
[   62.518741] CPU: 3 PID: 37 Comm: kworker/3:1 Not tainted 4.13.0-rc7-skl+ #1077
[   62.518770] Hardware name:                  /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
[   62.518827] Workqueue: events i915_hotplug_work_func [i915]
[   62.518853] task: ffff88046c00dc00 task.stack: ffffc90000184000
[   62.518896] RIP: 0010:i915_vma_pin_iomap+0x144/0x150 [i915]
[   62.518919] RSP: 0018:ffffc90000187cc8 EFLAGS: 00010292
[   62.518942] RAX: 000000000000002a RBX: ffff880460044000 RCX: 0000000000000006
[   62.518969] RDX: 0000000000000006 RSI: ffffffff819c3e6f RDI: ffffffff819f1c0e
[   62.518996] RBP: ffffc90000187cd8 R08: ffff88046c00e4f0 R09: 0000000000000000
[   62.519022] R10: ffff8804669ca800 R11: 0000000000000000 R12: ffff880461d20000
[   62.519049] R13: ffffc90000187d48 R14: ffff880461d20000 R15: ffff880460044000
[   62.519076] FS:  0000000000000000(0000) GS:ffff88047ed80000(0000) knlGS:0000000000000000
[   62.519107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   62.519130] CR2: 000056478ae213f0 CR3: 0000000002c0f000 CR4: 00000000003406e0
[   62.519156] Call Trace:
[   62.519190]  intelfb_create+0x176/0x360 [i915]
[   62.519216]  __drm_fb_helper_initial_config_and_unlock+0x1c7/0x3c0 [drm_kms_helper]
[   62.519251]  drm_fb_helper_hotplug_event.part.18+0xac/0xc0 [drm_kms_helper]
[   62.519282]  drm_fb_helper_hotplug_event+0x1a/0x20 [drm_kms_helper]
[   62.519324]  intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
[   62.519352]  drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
[   62.519395]  i915_hotplug_work_func+0x24e/0x2b0 [i915]
[   62.519420]  process_one_work+0x1d3/0x6d0
[   62.519440]  worker_thread+0x4b/0x400
[   62.519458]  ? schedule+0x4a/0x90
[   62.519475]  ? preempt_count_sub+0x97/0xf0
[   62.519495]  kthread+0x114/0x150
[   62.519511]  ? process_one_work+0x6d0/0x6d0
[   62.519530]  ? kthread_create_on_node+0x40/0x40
[   62.519551]  ret_from_fork+0x27/0x40
[   62.519569] Code: c4 78 e6 e0 0f ff e9 08 ff ff ff 80 3d d5 bc 0c 00 00 0f 85 0b ff ff ff 48 c7 c7 d8 50 32 a0 c6 05 c1 bc 0c 00 01 e8 9d 78 e6 e0 <0f> ff e9 f1 fe ff ff 0f 1f 44 00 00 0f 1f 44 00 00 0f b6 87 98
[   62.519771] ---[ end trace 5fbe271f991a58ae ]---
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901195456.6386-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

In the past, vGPU alloc fence registers by walking through mm.fence_list
to find fence which pin_count = 0 and vma is empty. vGPU may not find
enough fence registers this way. Because a fence can be bind to vma even
though it is not in using. We have found such failure many times these
days.

An option to resolve this issue is that we can force-remove fence from
vma in this case.

This patch added two new api to the fence management code:
 - i915_reserve_fence() will try to find a free fence from fence_list
   and force-remove vma if need.
 - i915_unreserve_fence() reclaim a reserved fence after vGPU has
   finished.

With this change, the fence management is more clear to work with vGPU.
GVTg do not need remove fence from fence_list in private.

v3: (Chris)
  - Add struct_mutex lock assertion.
  - Only count for unpinned fence.

v2: (Chris)
  - Rename the new api for symmetry.
  - Add safeguard to ensure at least 1 fence remained for host display.
Signed-off-by: NChangbin Du <changbin.du@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1504512061-5892-1-git-send-email-changbin.du@intel.comAcked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The header comment in include/trace/define_trace.h specifies that the
TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
rather than the trace file including it. Most instances get that wrong
and work around it by adding the $(src) directory to the include path.

While this works, it is preferable to refer to the correct path to the
trace file in the first place and avoid any workaround.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901144954.19620-4-thierry.reding@gmail.com

Add back the GEN8_PPAT_WB cache attributes in cnl_setup_private_ppat(),
which are missed on CNL.

Fixes: 4e34935f ("drm/i915/cnl: Setup PAT Index.")
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NZhi Wang <zhi.a.wang@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1504208177-27784-1-git-send-email-zhi.a.wang@intel.com

Use enum pipe for PCH transcoders also in the FIFO underrun code.

Fixes the following new sparse warnings:
intel_fifo_underrun.c:340:49: warning: mixing different enum types
intel_fifo_underrun.c:340:49:     int enum pipe  versus
intel_fifo_underrun.c:340:49:     int enum transcoder
intel_fifo_underrun.c:344:49: warning: mixing different enum types
intel_fifo_underrun.c:344:49:     int enum pipe  versus
intel_fifo_underrun.c:344:49:     int enum transcoder
intel_fifo_underrun.c:397:57: warning: mixing different enum types
intel_fifo_underrun.c:397:57:     int enum pipe  versus
intel_fifo_underrun.c:397:57:     int enum transcoder
intel_fifo_underrun.c:398:17: warning: mixing different enum types
intel_fifo_underrun.c:398:17:     int enum pipe  versus
intel_fifo_underrun.c:398:17:     int enum transcoder

Cc: Matthias Kaehlcke <mka@chromium.org>
Fixes: a2196033 ("drm/i915: Consistently use enum pipe for PCH transcoders")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-3-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Make gmbus_lock_ops and proxy_lock_ops static to appease sparse
intel_i2c.c:652:34: warning: symbol 'gmbus_lock_ops' was not declared. Should it be static?
intel_sdvo.c:2981:34: warning: symbol 'proxy_lock_ops' was not declared. Should it be static?

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes: a8506684 ("drm/i915: Rework sdvo proxy i2c locking")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Make i9xx_load_ycbcr_conversion_matrix() static to appease sparse:
intel_color.c:110:6: warning: symbol 'i9xx_load_ycbcr_conversion_matrix' was not declared. Should it be static?

Cc: Shashank Sharma <shashank.sharma@intel.com>
Fixes: 25edf915 ("drm/i915: prepare csc unit for YCBCR420 output")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170901143123.7590-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

We already have the correct new crtc state so just use that instead of
crtc->state.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-7-ville.syrjala@linux.intel.com

Pass the correct new crtc state to intel_update_pipe_config() instead
of using crtc->state.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-6-ville.syrjala@linux.intel.com

Dig up the appropriate new crtc and plane states from the top level
atomic state in intel_pre_plane_update() and intel_post_plane_update().
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-5-ville.syrjala@linux.intel.com

Eliminate plane->state and crtc->state usage from
intel_plane_atomic_check_with_state() and its callers. Instead pass the
proper states in or dig them up from the top level atomic state.

Note that intel_plane_atomic_check_with_state() itself isn't allowed to
use the top level atomic state as there is none when it gets called from
the legacy cursor short circuit path.

v2: Rename some variables for easier comprehension (Maarten)

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-4-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

We can now make use of the intel_device_info.gt field.
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-4-lionel.g.landwerlin@intel.com

As recommended by Chris.

v2: Switch from __initdata to __initconst.
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-3-lionel.g.landwerlin@intel.com

Up to Coffeelake we could deduce this GT number from the device ID.
This doesn't seem to be the case anymore. This change reorders pciids
per GT and adds a gt field to intel_device_info. We set this field on
the following platforms :

   - SNB/IVB/HSW/BDW/SKL/KBL/CFL/CNL

Before & After :

$ modinfo drivers/gpu/drm/i915/i915.ko | grep ^alias | wc -l
209

v2: Add SNB & IVB (Chris)

v3: Fix compilation error in early-quirks (Lionel)

v4: Fix inconsistency between FEATURE/PLATFORM macros (Ville)
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20170830161208.29221-2-lionel.g.landwerlin@intel.com

This patch fixes the DP AUX CH timeouts observed during CI runs causing
CI Failures on a specific PCI device. This issue was fixed previously
by adding a quirk but looks like we need to increase this delay even more
in order to get rid all the DP AUX CH timeouts.

Fixes: c99a259b ("drm/i915/edp: Add a T12 panel delay quirk to fix
DP AUX CH timeouts")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1502823591-25310-1-git-send-email-manasi.d.navare@intel.com

Use explicit old/new states instead of relying on obj->state.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-4-ville.syrjala@linux.intel.com

Pass the appropriate new crtc state explicitly to
intel_pipe_update_start/end() instead of of mucking around with
crtc->state.

v2: The mmio flip stuff is gone

Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-2-ville.syrjala@linux.intel.com

In an effort to eliminate the obj->state usage let's pass on the
new crtc state pointer (which we already have!) to the color management
code.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170823152226.22938-1-ville.syrjala@linux.intel.com

Currently the .modeset_calc_cdclk() hooks check the final cdclk value
against the max allowed. That's not really sufficient since the low
level calc_cdclk() functions effectively clamp the minimum required
cdclk to the max supported by the platform. Hence if the minimum
required exceeds the platforms capabilities we'd keep going anyway
using the max cdclk frequency.

To fix that let's move the check earlier into
intel_crtc_compute_min_cdclk() and we'll check the minimum required
cdclk of the pipe against the maximum supported by the platform.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170710193347.8734-2-ville.syrjala@linux.intel.comReviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Make the min_pixclk thing less confusing by changing it to track
the minimum acceptable cdclk frequency instead. This means moving
the application of the guardbands to a slightly higher level from
the low level platform specific calc_cdclk() functions.

The immediate benefit is elimination of the confusing 2x factors
on GLK/CNL+ in the audio workarounds (which stems from the fact
that the pipes produce two pixels per clock).

v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage handling
v3: Squash with the CNL cdclk limits patch (DK)
v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK)

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170830185703.8189-1-ville.syrjala@linux.intel.com

On clock recovery this function is called to find out
the max voltage swing level that we could go.

However gen 9 functions use the old buffer translation tables
to figure that out. That table is not valid for CNL
causing an invalid number of entries and an invalid selection
on the max voltage swing level.

v2: Let's use same approach that previous platforms.
v3: Actually use n_entries and avoid duplicated -1.
v4: Avoid cnl_max_level and use current style.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170831145356.15932-1-rodrigo.vivi@intel.com

Let's get a proper HDMI DDI entry level for vswing programming
sequences on CNL.

Spec doesn't specify any default for HDMI tables,
so let's pick the last entry as the default for now.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-7-rodrigo.vivi@intel.com

No functional changes. But those functions will be needed
to get max level for HDMI and DP, so let's move those
up closer to other similar functions existent for previous
platforms.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-6-rodrigo.vivi@intel.com

Let's start converging CNL buf translations to same style
used on previous platforms. So first thing is to use the
standard signature so we don't need to propagate the voltage
check into other parts of the code, but only on the parts
that it is really useful.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-5-rodrigo.vivi@intel.com

Sequences for DisplayPort asks us to
" Configure voltage swing and related IO settings.
Refer to DDI Buffer section."

before "Configure and enable DDI_BUF_CTL"

On BXT and CNL this means to execute the ddi vswing sequences.

At this point these sequences calls are getting duplicated for DP
because they are all called from DP link trainning sequences.

However this patch is not yet removing it before a futher discussion
since spec also allows that during link training without disabling
anything:

"
Notes
Changing voltage swing during link training:
Change the swing setting following the DDI Buffer section.
The port does not need to be disabled.
"

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-4-rodrigo.vivi@intel.com

Vswing sequences on BXT and CNL are equivalent
to the ddi buffer registers setting on other platforms.

For some reason it got aligned with skl_ddi_set_iboost what
is semantically incorrect. This forced us to keep skipping
ddi buffer translation tables on the platforms that has
the vswing sequences.

v2: Don't mess with DP signal levels on this patch.

Cc: Vandana Kannan <vandana.kannan@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-3-rodrigo.vivi@intel.com

Let's decouple bxt, glk and cnl dp signal levels
from other DDIs to avoid confusion.

No functional change. Only a reorg to avoid messing
with currently working DP signal levels when
moving voltage swing sequences around to match spec.

v2: ddi_signal_levels is also called from other ddi
    platforms, so don't remove IS_GEN9_BC check from
    skl_ddi_set_iboos. (Ville).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-2-rodrigo.vivi@intel.com

No functional changes. This only moves the DP level
selection to a separated function that will be later
used to organize better the vswing sequences.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-1-rodrigo.vivi@intel.com

Driver’s CPU access to GTT is via the GTTMMADR BAR.

The current HW implementation of that BAR is to only
support <= DW (and maybe QW) writes—not 16/32/64B writes
that could occur with WC and/or SSE/AVX moves.

GTTMMADR must be marked uncacheable (UC).
Accesses to GTTMMADR(GTT), must be 64 bits or less (ie. 1 GTT entry).

v2: Get clarification on the reasons and spec is getting
    updated to reflect it now.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Suggested-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829230907.21363-1-rodrigo.vivi@intel.com

On CNL B0 stepping GAM is not able to detect some deadlock
condition and then rise the rise the gam_coh_flush.

WA database and spec both mentions to set 4AB8[24]=1 as
workaround. Although register offset 0x4AB8 is not
documented for any platform.

References: HSD#1945815, BSID#1112

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829230751.21047-1-rodrigo.vivi@intel.com

WA to enable HW L1 Banking fix that allows aniso to operate
at full sample rate.

References: HSD#1937670

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Anuj Phogat <anuj.phogat@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829230723.20898-1-rodrigo.vivi@intel.com

No functional changes.

Our code was only a bit messy with mixed style there so
let's clean up a bit using the short codenames for the platforms.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829052026.15038-1-rodrigo.vivi@intel.com

The CCS won't have the same stride as the main surface anyway so trying
to guard against the fence stride not matching the CCS stride is
not sensible. Just skip the fence vs. fb alignment check for the aux
plane.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Daniel Stone <daniels@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170824191100.10949-3-ville.syrjala@linux.intel.comReviewed-by: NBen Widawsky <ben@bwidawsk.net>
Fixes: 2e2adb05 ("drm/i915: Add render decompression support")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Userspace wants to treat fb->offsets[] as raw byte offsets into the gem
bo. Adjust the kernel code to match.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Daniel Stone <daniels@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170824191100.10949-2-ville.syrjala@linux.intel.comAcked-by: NBen Widawsky <ben@bwidawsk.net>
Fixes: 2e2adb05 ("drm/i915: Add render decompression support")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since we hold the device wakeref when writing through the GTT (otherwise
the writes would fail), we presumed that before the device sleeps those
writes would naturally be flushed and that we wouldn't need our mmio
read trick. However, that presumption seems false and a sleepy bxt seems
to require us to always manually flush the GTT writes prior to direct
access.

Fixes: e2a2aa36 ("drm/i915: Check we have an wake device before flushing GTT writes")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829192546.1087-1-chris@chris-wilson.co.uk

If we fail to clear the outstanding request queue before suspending,
mark those requests as lost.

References: https://bugs.freedesktop.org/show_bug.cgi?id=102037Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170826110935.10237-3-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>

When we wake up from suspend, the device has been powered down and
should come back afresh. We should be able to safely remove the wedged
status from the previous session and start afresh.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170826110935.10237-2-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>