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

As described in the WA on GLK and CNL planes on the right edge of the
screen that have less than 4 pixels visible from the beginning of the
plane to the edge of the screen can cause FIFO underflow and display
corruption.

On GLK/CNL I could trigger the problem only if the plane was at the same
time also aligned to the top edge of the screen (after clipping) and
there were exactly 2 pixels visible from the start of the plane to the
right edge of the screen (so couldn't trigger it with 1 or 3 pixels
visible). Nevertheless, to be sure, I also applied the WA for these cases.

I also couldn't see any problem with the cursor plane and later Art
confirmed that it's not affected, so the WA is applied only for the
other plane types.

v2:
- Use -ERANGE instead of -EINVAL. (Chris)
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-1-imre.deak@intel.com

If the table result is out of bounds on the array map
there is something really wrong with VBT pin so we don't
return that vbt_pin, but only return 0 instead.

This basically reverts commit 'a8e6f388 ("drm/i915/cnp:
Ignore VBT request for know invalid DDC pin.")'

Also this properly fixes commit 9c3b2689 ("drm/i915/cnl:
Map VBT DDC Pin to BSpec DDC Pin.")

v2: Do in a way that we don't break other platforms. (Jani)

v3: Keep debug message (Jani)

v4: Don't mess with 0 mapping was noticed by Jani and
    addressed with a simple solution suggested by Lucas
    that makes this even simpler.

Fixes: a8e6f388 ("drm/i915/cnp: Ignore VBT request for know invalid DDC pin.")
Fixes: 9c3b2689 ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Kai Heng Feng <kai.heng.feng@canonical.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Suggested-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Tested-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125222524.22059-1-rodrigo.vivi@intel.com

Assert that we do not try to unsubmit a completed request, as should we
try to resubmit it later, the ring is already past the request's
breadcrumb and the breadcrumb will not be updated.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129094912.14428-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>

Older gcc is complaining it can't follow the guards and thinks that
addr may be used uninitialised

In the process, we can simplify down to one loop,
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-131 (-131)
Function                                     old     new   delta
setup_scratch_page                           545     414    -131
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180129102840.19901-1-chris@chris-wilson.co.uk

Pull 4.15 into drm-intel-next-queued for next feature pull.
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>

This reverts commit 5b54eddd.

 Conflicts:
	drivers/gpu/drm/i915/i915_pci.c

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: 5b54eddd ("drm/i915: mark all device info struct with __initconst")
Link: https://patchwork.freedesktop.org/patch/msgid/20180129083346.29173-1-lionel.g.landwerlin@intel.com

Remove the WARN_ON(ce->state) inside the static function only called
when ce->state == NULL and downgrade the w/a batch setup warning into a
developer only mode (GEM_WARN_ON).

v2: Move the deferred alloc guard into the callee, eliminating the need
for the WARN_ON:
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-1 (-1)
Function                                     old     new   delta
execlists_context_pin                       1819    1818      -1
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180126121846.12007-1-chris@chris-wilson.co.uk

CTX_CONTEXT_CONTROL (CTX_SR_CTL) operates as a masked register and so
will only apply the bits that are selected by the upper half. In the
case of selectively enabling sr inhibit, this may mean the context keeps
the current setting (so forgetting to save the context later, eventually
leading to a very upset GPU!).

Fixes: 517aaffe ("drm/i915/execlists: Inhibit context save/restore for the fake preempt context")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180125112443.12745-1-chris@chris-wilson.co.ukReviewed-by: NMichel Thierry <michel.thierry@intel.com>

Merge tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

Fixes for 4.16:

Fixes one Kconfig issue and a enable some panels to work properly.
There is also a fix of error code return in sun4i.

* tag 'drm-misc-next-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-misc:
  drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig
  drm/panel: lvds: Handle the optional regulator case properly
  drm/sun4i: Fix error code in sun4i_tcon_bind()

 A few more fixes for 4.16, nothing major.

A few more fixes for 4.16.  This is on top of the pull request from
last week.  Most notable change here is a fix to the link order for
the now separate from amdgpu GPU scheduler to fix crashes when the
modules are build into the kernel rather than as modules.

* 'drm-next-4.16' of git://people.freedesktop.org/~agd5f/linux:
  drm: fix gpu scheduler link order
  drm/amd/display: Demote error print to debug print when ATOM impl missing
  drm/amdgpu: Avoid leaking PM domain on driver unbind (v2)
  drm/amd/amdgpu: Add Polaris version check
  drm/amdgpu: Reenable manual GPU reset from sysfs
  drm/amdgpu: disable MMHUB power gating on raven
  drm/ttm: Don't unreserve swapped BOs that were previously reserved
  drm/ttm: Don't add swapped BOs to swap-LRU list
  drm/amdgpu: only check for ECC on Vega10
  drm/amd/powerplay: Fix smu_table_entry.handle type
  drm/ttm: add VADDR_FLAG_UPDATED_COUNT to correctly update dma_page global count
  drm/radeon: fill in rb backend map on evergreen/ni.
  drm/amdgpu/gfx9: fix ngg enablement to clear gds reserved memory (v2)
  drm/ttm: only free pages rather than update global memory count together
  drm/amdgpu: fix CPU based VM updates
  drm/amdgpu: fix typo in amdgpu_vce_validate_bo
  drm/amdgpu: fix amdgpu_vm_pasid_fault_credit
  drm/ttm: check the return value of register_shrinker
  drm/radeon: fix sparse warning: Should it be static?

It should initialize before the drivers using it.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104736Reviewed-by: NMike Lothian <mike@fireburn.co.uk>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

I assumed wrongfully that all relevant functions should be implemented.
Apparently this isn't the case. Demote the print to debug level for now.
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NTony Cheng <Tony.Cheng@amd.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>