Dump each engine state when i915_gem_set_wedged() is called to give us
some more clues as to why we had to terminate the GPU.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205092201.19476-5-chris@chris-wilson.co.uk

Provide the reason why we call intel_fbc_deactivate() so that debugging
issues with FBC being delayed is clearer.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125224122.27480-1-chris@chris-wilson.co.ukReviewed-by: NJani Nikula <jani.nikula@intel.com>

The headers should be on a separate line for consistency, so add the
missing trailing newline in a few intel_engine_dump() callers.
Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205100618.11001-1-chris@chris-wilson.co.uk

Since unbannable contexts are special and supposed not to be causing GPU
hangs in the first place, make it clear when they are implicated in said
hang. In practice, most unbannable contexts are those created by igt
for the express purpose of throwing untold thousands of hangs at the GPU
and wish to keep doing so to finish the test. Normally they are cleaned
up, but it's when they or the other unbannable kernel contexts stay
stuck in an erroneous state that we need to worry and so need
highlighting.
Suggested-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205094139.10671-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

As we ourselves cancel interrupts during reset by clearing the GTIIR, it
is possible for the master IIR to indicate a pending IRQ for which we
have already cleared from the GTIIR. In this case, the DRM_ERROR are
intended and should not be flagged as an error.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180202153448.23908-1-chris@chris-wilson.co.uk

Be paranoid and flush the GTIIR after clearing the CS interrupt to be
sure it has taken before we re-enable the interrupt handler. We still
see early interrupts following reset, the tasklet handling the mmio read
before it has been written by the CS. This hopefully reduces the
frequency to 0...

References: https://bugs.freedesktop.org/show_bug.cgi?id=104262Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: NMichel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180202145455.29876-1-chris@chris-wilson.co.uk

Save some horizontal space.
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180202130416.18233-1-jani.nikula@intel.com

We're using i915_inject_load_failure() to inject dummy
faults during driver load, but since this is debug utility
we shouldn't expose it in default config as it consumes
both code and data.

add/remove: 0/1 grow/shrink: 0/2 up/down: 0/-302 (-302)
Function                                     old     new   delta
__i915_inject_load_failure                    61       -     -61
i915_gem_init                               1331    1268     -63
i915_driver_load                            5923    5745    -178
Total: Before=1177454, After=1177152, chg -0.03%

add/remove: 0/1 grow/shrink: 0/0 up/down: 0/-4 (-4)
Data                                         old     new   delta
i915_load_fail_count                           4       -      -4
Total: Before=56762, After=56758, chg -0.01%

add/remove: 4/8 grow/shrink: 0/1 up/down: 245/-591 (-346)
RO Data                                      old     new   delta
__param_str_inject_load_failure               20       -     -20
__UNIQUE_ID_inject_load_failuretype200        34       -     -34
__param_inject_load_failure                   40       -     -40
__func__                                    4998    4896    -102
__UNIQUE_ID_inject_load_failure201           150       -    -150
Total: Before=119095, After=118749, chg -0.29%
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180201173248.3912-1-michal.wajdeczko@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We have the max DP link rate info available in VBT since BDB version
216, included in child device config since commit c4fb60b9
("drm/i915/bios: add DP max link rate to VBT child device
struct"). Parse it and use it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a8b1364d1f2394fba3062b6ad11b474744ea4366.1517482774.git.jani.nikula@intel.com

Make the limiting rate based instead of messing with the array size.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cb03b9419191a7d6359bf371aacb2d3725c746de.1517482774.git.jani.nikula@intel.com

This will be useful later on. Also move the functions around to not need
forward declarations in subsequent patches. No functional changes.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/40f37f08cad33234cd86337d39e823ac6e55805f.1517482774.git.jani.nikula@intel.com

There is no requirement for doing the PCODE request polling atomically,
so do that only for a short time switching to sleeping poll afterwards.
The specification requires a 150usec timeout for the change notification,
so let's use that for the atomic poll. Do the extra 2ms poll - needed as
a workaround on BXT/GLK - in sleeping mode.

v2:
- rebase on v2 of patchset dropping the sandybridge_pcode_read/write
  refactoring (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-2-imre.deak@intel.com

Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.

Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)

This issue is similar to
commit 2c7d0602 ("drm/i915/gen9: Fix PCODE polling during CDCLK
change notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.

v2:
- s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.4+
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com

In case of GuC initialization failure we may continue with driver
load, but we wrongly assume that GuC is fully functional. This
leads to the BUG as we attempt to access non-existing log vma.

[26386.121085] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
[26386.121225] IP: guc_log_runtime_create+0x23/0xe0 [i915]
[26386.121763] Call Trace:
[26386.121870]  guc_log_late_setup+0xfd/0x140 [i915]
[26386.121969]  i915_driver_load+0x7ab/0x1730 [i915]
[26386.122069]  i915_pci_probe+0x2d/0x90 [i915]
[26386.122089]  pci_device_probe+0x9c/0x120
[26386.122107]  driver_probe_device+0x2a9/0x490
[26386.122126]  __driver_attach+0xd9/0xe0
[26386.122143]  ? driver_probe_device+0x490/0x490
[26386.122158]  bus_for_each_dev+0x57/0x90
[26386.122175]  bus_add_driver+0x1eb/0x260
[26386.122190]  ? 0xffffffffa069a000
[26386.122206]  driver_register+0x52/0xc0
[26386.122220]  ? 0xffffffffa069a000
[26386.122234]  do_one_initcall+0x39/0x170
[26386.122252]  ? kmem_cache_alloc_trace+0x1fd/0x2e0
[26386.122273]  do_init_module+0x56/0x1ec
[26386.122289]  load_module+0x219e/0x2550
[26386.122309]  ? vfs_read+0x121/0x140
[26386.122331]  ? SyS_finit_module+0xa5/0xe0
[26386.122346]  SyS_finit_module+0xa5/0xe0
[26386.122371]  entry_SYSCALL_64_fastpath+0x22/0x8f
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131173241.19704-4-michal.wajdeczko@intel.comReviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We're freeing GuC error log in uc_fini_hw() that matches
corresponding uc_init_hw() but we missed the point that this
log object is copied on error path and in case of failure in
uc_init_hw() we will leak this object as uc_fini_hw() is
never called.

If we free this log object as part of the late uC cleanup, where
we also release other firmware objects, we can avoid this BUG:

[70841.001413] BUG drm_i915_gem_object (Tainted: G     U  W       ): Objects remaining in drm_i915_gem_object on __kmem_cache_shutdown()
[70841.001436] INFO: Slab 0x00000000c94e41af objects=21 used=1 fp=0x000000001d60c40a flags=0x8000000000008100

[70841.001466] Call Trace:
[70841.001471]  dump_stack+0x5e/0x8e
[70841.001476]  slab_err+0x99/0xb0
[70841.001483]  ? __slab_alloc.isra.24.constprop.29+0x62/0x70
[70841.001491]  ? __kmalloc+0x1f5/0x320
[70841.001497]  __kmem_cache_shutdown+0x18b/0x400
[70841.001505]  shutdown_cache+0x13/0x1c0
[70841.001511]  kmem_cache_destroy+0x1c2/0x240
[70841.001517]  ? __mutex_unlock_slowpath+0x38/0x270
[70841.001559]  i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.001595]  i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.001630]  i915_driver_load+0x708/0x1720 [i915]
[70841.001638]  ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.001673]  i915_pci_probe+0x2d/0x90 [i915]
[70841.001680]  pci_device_probe+0x9c/0x120
[70841.001687]  driver_probe_device+0x2a9/0x490
[70841.001694]  __driver_attach+0xd9/0xe0
[70841.001700]  ? driver_probe_device+0x490/0x490
[70841.001705]  bus_for_each_dev+0x57/0x90
[70841.001712]  bus_add_driver+0x1eb/0x260
[70841.001717]  ? 0xffffffffa0685000
[70841.001723]  driver_register+0x52/0xc0
[70841.001728]  ? 0xffffffffa0685000
[70841.001733]  do_one_initcall+0x39/0x170
[70841.001739]  ? rcu_read_lock_sched_held+0x6f/0x80
[70841.001746]  ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.001753]  do_init_module+0x56/0x1ec
[70841.001759]  load_module+0x219e/0x2550
[70841.001766]  ? vfs_read+0x121/0x140
[70841.001774]  ? SyS_finit_module+0xa5/0xe0
[70841.001779]  SyS_finit_module+0xa5/0xe0
[70841.001788]  entry_SYSCALL_64_fastpath+0x22/0x8f

[70841.001806] INFO: Object 0x00000000eab7ed96 @offset=6208
[70841.001850] INFO: Allocated in i915_gem_object_create.part.32+0x1f/0x260 [i915] age=38 cpu=0 pid=2708
[70841.001861] 	kmem_cache_alloc+0x23d/0x2d0
[70841.001897] 	i915_gem_object_create.part.32+0x1f/0x260 [i915]
[70841.001937] 	intel_guc_allocate_vma+0x15/0x100 [i915]
[70841.001977] 	intel_guc_log_create+0x34/0x1c0 [i915]
[70841.002014] 	intel_guc_init+0x5a/0x100 [i915]
[70841.002051] 	intel_uc_init+0x3e/0xb0 [i915]
[70841.002089] 	i915_gem_init+0x18e/0x540 [i915]
[70841.002123] 	i915_driver_load+0xa7a/0x1720 [i915]
[70841.002159] 	i915_pci_probe+0x2d/0x90 [i915]
[70841.002165] 	pci_device_probe+0x9c/0x120
[70841.002171] 	driver_probe_device+0x2a9/0x490
[70841.002177] 	__driver_attach+0xd9/0xe0
[70841.002182] 	bus_for_each_dev+0x57/0x90
[70841.002188] 	bus_add_driver+0x1eb/0x260
[70841.002193] 	driver_register+0x52/0xc0
[70841.002198] 	do_one_initcall+0x39/0x170
[70841.002462] kmem_cache_destroy drm_i915_gem_object: Slab cache still has objects

[70841.002491] Call Trace:
[70841.002497]  dump_stack+0x5e/0x8e
[70841.002503]  kmem_cache_destroy+0x1e0/0x240
[70841.002509]  ? __mutex_unlock_slowpath+0x38/0x270
[70841.002551]  i915_gem_load_cleanup+0xbc/0x130 [i915]
[70841.002586]  i915_driver_cleanup_early+0x11/0x60 [i915]
[70841.002621]  i915_driver_load+0x708/0x1720 [i915]
[70841.002629]  ? trace_hardirqs_on_caller+0xe2/0x1c0
[70841.002664]  i915_pci_probe+0x2d/0x90 [i915]
[70841.002671]  pci_device_probe+0x9c/0x120
[70841.002678]  driver_probe_device+0x2a9/0x490
[70841.002684]  __driver_attach+0xd9/0xe0
[70841.002690]  ? driver_probe_device+0x490/0x490
[70841.002696]  bus_for_each_dev+0x57/0x90
[70841.002702]  bus_add_driver+0x1eb/0x260
[70841.002708]  ? 0xffffffffa0685000
[70841.002713]  driver_register+0x52/0xc0
[70841.002719]  ? 0xffffffffa0685000
[70841.002724]  do_one_initcall+0x39/0x170
[70841.002731]  ? rcu_read_lock_sched_held+0x6f/0x80
[70841.002737]  ? kmem_cache_alloc_trace+0x27b/0x2e0
[70841.002745]  do_init_module+0x56/0x1ec
[70841.002751]  load_module+0x219e/0x2550
[70841.002758]  ? vfs_read+0x121/0x140
[70841.002766]  ? SyS_finit_module+0xa5/0xe0
[70841.002772]  SyS_finit_module+0xa5/0xe0
[70841.002781]  entry_SYSCALL_64_fastpath+0x22/0x8f
Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131173241.19704-2-michal.wajdeczko@intel.comReviewed-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Try to catch a bug we've seen in the wild where the shrinker purges the
pd/pdp from under us while allocating our paging structures.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104773Signed-off-by: NMatthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131191453.12676-1-matthew.auld@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-2-chris@chris-wilson.co.uk

Commit e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes")
believed that because it did not insert its freshly allocated page
directory into the pd tree, it was safe from the shrinker. I failed to
heed the lesson learnt from commit dd19674b ("drm/i915: Remove bitmap
tracking for used-ptes") that we need to pin all the levels in the tree
before hitting the shrinker or else the shrinker may free an upper layer
as we proceed to allocate the tree. Thus leaving dangling pointers
everywhere and a GPF should we hit direct reclaim at just the wrong
moment.

CPU: 0 PID: 7374 Comm: chromium Tainted: P           O    4.14.13-1-ARCH #1
Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 06/18/2017
task: ffff994f696c2c40 task.stack: ffffb1a789d4c000
RIP: 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915]
RSP: 0018:ffffb1a789d4f940 EFLAGS: 00010206
RAX: 81c1788cc4f68138 RBX: ffff994f54db8000 RCX: ffff994f696c2c40
RDX: 000000023bc73003 RSI: ffff994d598b6b80 RDI: ffff994f54db8000
RBP: ffff994d598b6b80 R08: 0000000000000000 R09: 0000000000000000
R10: ffffb1a789d4f550 R11: ffff994eaf3c3208 R12: 0000000000000027
R13: 0000000000005000 R14: 0000000004e8f000 R15: ffff994f54dba000
FS:  00007f585886aa00(0000) GS:ffff994faec00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004ac8e8 CR3: 00000002552c8004 CR4: 00000000003606f0
Call Trace:
 gen8_ppgtt_alloc_pdp+0x178/0x320 [i915]
 gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915]
 ppgtt_bind_vma+0x30/0x70 [i915]
 i915_vma_bind+0x68/0xd0 [i915]
 __i915_vma_do_pin+0x2d6/0x3a0 [i915]
 eb_lookup_vmas+0x7a2/0xb50 [i915]
 i915_gem_do_execbuffer+0x4d7/0x10e0 [i915]
 ? sock_wfree+0x34/0x60
 ? unix_stream_read_generic+0x1f9/0x7e0
 ? import_iovec+0x37/0xd0
 ? i915_gem_execbuffer2+0x5d/0x390 [i915]
 i915_gem_execbuffer2+0x1b7/0x390 [i915]
 ? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
 drm_ioctl_kernel+0x59/0xb0 [drm]
 drm_ioctl+0x2d5/0x370 [drm]
 ? i915_gem_execbuffer+0x2d0/0x2d0 [i915]
 ? __seccomp_filter+0x3b/0x260
 do_vfs_ioctl+0xa1/0x610
 ? syscall_trace_enter+0xdb/0x2b0
 SyS_ioctl+0x74/0x80
 do_syscall_64+0x55/0x110
 entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f584fa82d27
RSP: 002b:00007ffee14a7828 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 000003b0126a1030 RCX: 00007f584fa82d27
RDX: 00007ffee14a7870 RSI: 0000000040406469 RDI: 0000000000000080
RBP: 00007ffee14a7870 R08: 0000000000000002 R09: 0000000000000077
R10: 00007f5839f2b780 R11: 0000000000000246 R12: 0000000040406469
R13: 0000000000000080 R14: 00007f5842b00040 R15: 0000000000000000
Code: 01 00 83 81 58 0a 00 00 01 48 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 c3
RIP: gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: ffffb1a789d4f940
Reported-by: NEric Blau <eblau@eblau.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773
Fixes: e2b763ca ("drm/i915: Remove bitmap tracking for used-pdpes")
References: dd19674b ("drm/i915: Remove bitmap tracking for used-ptes")
Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180131214440.7141-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>

This enables the Mesa driver to advertise support for ARB_timer_query,
and thus an OpenGL version higher than 3.2.

Based on the CNL patch by Nanley Chery.

v2: Rebase.

Cc: Anuj Phogat <anuj.phogat@intel.com>
Cc: Nanley Chery <nanley.g.chery@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Requested-by: NAnuj Phogat <anuj.phogat@intel.com>
Tested-by: NAnuj Phogat <anuj.phogat@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-10-paulo.r.zanoni@intel.com

This patch clears a single bit. The bit is 0 by default but expected
not to be set. Explicitly clearing the bit in this patch is intended
to indicate some thinking has occurred, and that we want this bit
cleared and we are not just excepting the default value.

We also stop setting GFX_RUN_LIST_ENABLE, which is correct since that
bit is gone.

v2 (from Paulo): fix indentation.
v3: Changed GEN check to >= 11. Corrected author name.
v4 (from Paulo): improve commit message (Daniele).
Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: NKelvin Gardiner <kelvin.gardiner@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-9-paulo.r.zanoni@intel.com

ICL+ adds changes the PLANE_CTL_FORMAT field from [27:24] to [27:23],
however, all existing PLANE_CTL_FORMAT_* definitions still map to the
correct values.  Add an ICL_PLANE_CTL_FORMAT_MASK definition, and use
that for masking for the conversion to fourcc.

v2: No changes

v3: Change new definition name, drop comment (Rodrigo)

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-8-paulo.r.zanoni@intel.com

It's 10us for gen 11.
Reviewed-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-7-paulo.r.zanoni@intel.com

This patch introduce MBus control registers and their bit-fields
MBUS_ABOX_CTL
MBUS_BBOX_CTL
MBUS_DBOX_CTL
MBUS_UBOX_CTL

Changes Since V1:
 - Use function like macros (Paulo)
 - fix copy-paste error (Paulo)
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-6-paulo.r.zanoni@intel.com

We don't have planar pixel format support implemented for ICL yet.
ICL require 2 display planes to be allocated for Planar formats unlike
previous GEN. So ICL/GEN11 doesn't require to write Y-plane ddb data in
NV12_BUF_CFG register and PLANE_NV12_BUF_CFG register is removed in ICL.

This patch removes the PLANE_NV12_BUF_CFG write for ICL.

Changes Since V1:
 - Improve commit message as per Paulo's comment
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-5-paulo.r.zanoni@intel.com

ICL require DDB allocation of plane to be more than "minimum display
buffer needed" for each level in order to enable WM level.

This patch implements and consider the same while allocating DDB
and enabling WM.

Changes Since V1:
 - rebase
Changes Since V2:
 - Remove extra parentheses
 - Use FP16.16 only when absolutely necessary (Paulo)
Changes Since V3:
 - Rebase
Changes since v4 (from Paulo):
 - Coding style issue.
Changes since v5 (from Paulo):
 - Do the final checks according to BSpec.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-4-paulo.r.zanoni@intel.com

GEN9/10 had fixed DBuf block size of 512. Dbuf block size is not a
fixed number anymore in GEN11, it varies according to bits per pixel
and tiling. If 8bpp & Yf-tile surface, block size = 256 else block
size = 512

This patch addresses the same.

v2 (from Paulo):
  - Make it compile.
  - Fix a few coding style issues.
v3:
  - Rebase on top of upstream patches
v4 (from Paulo):
  - Bikeshed if statements (James).
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-3-paulo.r.zanoni@intel.com

GEN9 onwards bypass path allocation of 4 blocks was needed, as per
hardware design. ICL doesn't require bypass path allocation of 4 DDB
blocks, handling the same in this patch.

v2 (from Paulo):
  - No need for a comment that says what the code already says.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130134918.32283-2-paulo.r.zanoni@intel.com

This is a precautionary measure as I have no evidence to suggest we've
hit a bug here (I was hoping this might explain gdg's odd behaviour, but
alas), but given that we have a function to flush the ggtt writes it
seems prudent to use it prior to changing the fence register. Due to the
intrinsic nature of the GTT often operating as an independent mmio path,
we should not just rely on the write to the fence acting as a full flush
for 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/20180130164457.14037-1-chris@chris-wilson.co.uk

guc_log_relay_file_create will return -EEXIST if we invoke
relay_late_setup_files multiple times as part of i915_guc_log_control.
However this is to be not cosidered as fail and need to return 0.
This was mistakenly introduced in the below commit. Fix it.

Fixes: 70deeadd "drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex"
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1517379279-12967-1-git-send-email-sagar.a.kamble@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Previously, we relied on only running the hangcheck while somebody was
waiting on the GPU, in order to minimise the amount of time hangcheck
had to run. (If nobody was watching the GPU, nobody would notice if the
GPU wasn't responding -- eventually somebody would care and so kick
hangcheck into action.) However, this falls apart from around commit
4680816b ("drm/i915: Wait first for submission, before waiting for
request completion"), as not all waiters declare themselves to hangcheck
and so we could switch off hangcheck and miss GPU hangs even when
waiting under the struct_mutex.

If we enable hangcheck from the first request submission, and let it run
until the GPU is idle again, we forgo all the complexity involved with
only enabling around waiters. We just have to remember to be careful that
we do not declare a GPU hang when idly waiting for the next request to
be come ready, as we will run hangcheck continuously even when the
engines are stalled waiting for external events. This should be true
already as we should only be tracking requests submitted to hardware for
execution as an indicator that the engine is busy.

Fixes: 4680816b ("drm/i915: Wait first for submission, before waiting for request completion"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104840Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129144104.3921-1-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>

On CNL SKUs that uses port F,  max DP rate is 8.1G for all
ports when we have the elevated voltage (higher than 0.85V).

v2: Make commit message more generic.
v3: Move conditions to a helper to get easier to read. (Ville).
v4: Add a mention to the numerical voltage on commit
    message per Manasi request.
v5: Thanks CI! "error: control reaches end of non-void function"

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-10-rodrigo.vivi@intel.com

Now let's finish the Port-F support by adding the
proper port F detection, irq and power well support.

v2: Rebase
v3: Use BIT_ULL
v4: Cover missed case on ddi init.
v5: Update commit message.
v6: Rebase on top of display headers rework.
v7: Squash power-well handling related to DDI F to this
    patch to avoid warns as pointed out by DK.
v8: Introduce DDI_F_LANES to PG2. (DK)
v9: Squash in the PORT_F case for enabling DP MST encoder. (DK)

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-9-rodrigo.vivi@intel.com

On CNP boards that are using DDI F,
bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing
the Digital Port F hotplug line when the Digital
Port F hotplug detect input is enabled.

v2: Reuse all existent structure instead of adding a
new HPD_PORT_F pointing to pin of port E.
v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming
    this right now. If that SKU ever get a proper name
    we come back and update it.
v4: Rebase on top of digital connected port using encoder
    instead of port.
v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
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/20180129232223.766-8-rodrigo.vivi@intel.com

Let's try to simplify this mapping to hpd_pin -> bit
instead using port.
So for CNL with port F where we have this port using
hdp_pin and bits of other ports we don't need to duplicated
the mapping.

But for now this is only a re-org with no functional change
expected.

v2: Add missing lines and nuke @port reference from code
    documentation. (Ville)

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
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/20180129232223.766-7-rodrigo.vivi@intel.com

On CNP Pin 3 is for misc of Port F usage depending on the
configuration. For CNL that uses Port F, pin 3 is the one.

v2: Make it more generic and update commit message.

Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-6-rodrigo.vivi@intel.com

Since when it got introduced with commit '555e38d2
("drm/i915/cnl: DDI - PLL mapping")' the support for Port F
was wrong, because Port F bits are far from bits used
for A to E.

Since Port F is not used so far we don't need to propagate
Fixes back there.

v2: Reuse _SHIFT definition to avoid complicated duplication (DK).

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-5-rodrigo.vivi@intel.com

This was wrong since its introduction on commit '04416108
("drm/i915/cnl: Add registers related to voltage swing sequences.")'

But since no Port F was needed so far we don't need to
propagate fixes back there.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-4-rodrigo.vivi@intel.com

We also need to extend this WA to Aux F.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-3-rodrigo.vivi@intel.com

On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.

There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.

v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
v8: Fix Aux bits for Port F (DK)
v9: Fix VBT definition of Port F (DK).
v10: Squash power well addition to this patch to avoid
     warns as pointed by DK.
v11: Clean up squashed commit message. (David)
v12: Remove unnecessary handling for older platforms (DK)
     Adding AUX_F to PG2 following other existent ones. (DK)

Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-2-rodrigo.vivi@intel.com

The only difference is that this SKUs has the full
Port A/E split named as Port F.

But since SKUs differences don't matter on the platform
definition group and ids, let's merge all off them together.

v2: Really include the PCI IDs to the picidlist[];
v3: Add the PCI Id for another SKU (Anusha).
v4: Update IDs, really include to pciidlists again.
v5: Unify all GT2 IDs.
v6: Unify in a way that we don't break early-quirks.c
v7: Remove GT reference since it doesn't matter here (Paulo)
    Also move IS_CNL_WITH_PORT_F macro to this patch to
    make it easier for review this part and also to get
    used sooner.
v8: Rebased on top of commit 5db47e37 ("Revert "drm/i915:
mark all device info struct with __initconst"")

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-1-rodrigo.vivi@intel.com

While running the kms_plane clipping test I noticed a similar problem to
the one described in Display WA #1175. In this case, similarly for
planes other than the cursor, with 1 or 3 pixels visible from the left
edge of the screen to the end of the plane and an odd plane X offset
used for clipping causes the same kind of underflow and display
corruption as described for WA #1175. Fix this in a similar way as that
WA rejecting planes ending <4 pixels from the left screen edge.

v2:
- Rebase on v2 of patch 1/1.

Testcase: igt/kms_plane/plane-clipping-pipe-*-planes
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180116112415.22060-2-imre.deak@intel.com