drm/i915/mst: Hookup DRM DP MST late_register/early_unregister callbacks

i915 can enable aux device nodes for DP MST by calling
drm_dp_mst_connector_late_register()/
drm_dp_mst_connector_early_unregister(),
so let's hook that up.

Changes since v1:
* Call intel_connector_register/unregister() from
  intel_dp_mst_connector_late_register/unregister() so we don't lose
  error injection - Ville Syrjälä
Changes since v2:
* Don't forget to clean up if intel_connector_register() fails - Ville

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: "Lee, Shawn C" <shawn.c.lee@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200310195122.1590925-1-lyude@redhat.com

drm/i915: Improve the start alignment of bonded pairs

Always wait on the start of the signaler request to reduce the problem
of dequeueing the bonded pair too early -- we want both payloads to
start at the same time, with no latency, and yet still allow others to
make full use of the slack in the system. This reduce the amount of time
we spend waiting on the semaphore used to synchronise the start of the
bonded payload.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306133852.3420322-3-chris@chris-wilson.co.uk

drm/i915/gt: Defend against concurrent updates to execlists->active

[  206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915]
[  206.875654]
[  206.875666] race at unknown origin, with read to 0xffff8881f7644480 of 8 bytes by task 703 on cpu 3:
[  206.875901]  __i915_schedule+0x7fc/0x930 [i915]
[  206.876130]  __bump_priority+0x63/0x80 [i915]
[  206.876361]  __i915_sched_node_add_dependency+0x258/0x300 [i915]
[  206.876593]  i915_sched_node_add_dependency+0x50/0xa0 [i915]
[  206.876824]  i915_request_await_dma_fence+0x1da/0x530 [i915]
[  206.877057]  i915_request_await_object+0x2fe/0x470 [i915]
[  206.877287]  i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[  206.877517]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[  206.877535]  drm_ioctl_kernel+0xe4/0x120
[  206.877549]  drm_ioctl+0x297/0x4c7
[  206.877563]  ksys_ioctl+0x89/0xb0
[  206.877577]  __x64_sys_ioctl+0x42/0x60
[  206.877591]  do_syscall_64+0x6e/0x2c0
[  206.877606]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

v2: Be safe and include mb

References: https://gitlab.freedesktop.org/drm/intel/issues/1318
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309170540.10332-1-chris@chris-wilson.co.uk

drm/i915: Lock gmbus/aux mutexes while changing cdclk

gmbus/aux may be clocked by cdclk, thus we should make sure no
transfers are ongoing while the cdclk frequency is being changed.
We do that by simply grabbing all the gmbus/aux mutexes. No one
else should be holding any more than one of those at a time so
the lock ordering here shouldn't matter.

v2: Use mutex_lock_nest_lock() (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302174442.5803-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Pass the crtc to the low level read_lut() funcs

The low level read_lut() functions don't need the entire crtc state
as they know exactly what they're reading. Just need to pass in the
crtc to get at the pipe. This now neatly mirrors the load_lut()
direction.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-10-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Fix readout of PIPEGCMAX

PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can
represent a value of 1.0 when the maximum we can store in the
software LUT is 0.ffff. Clamp the value so that it gets
saturated to the max the uapi supports.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-9-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Refactor LUT read functions

Extract all the 'hw value -> LUT entry' stuff into small helpers
to make the main 'read out the entire LUT' loop less bogged down
by such mundane details.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-8-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Clean up integer types in color code

A variable called 'i' having an unsigned type is just looking for
trouble, and using a sized type generally makes no sense either.
Change all of them to just plain old int. And do the same for some
'lut_size' variables which generally provide the loop end codition
for 'i'.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-7-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/

chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so
let's rename it to reflect that fact. This also mirrors
the other direction's chv_load_cgm_gamma().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-6-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: s/blob_data/lut/

We're talking about LUT contents here so let's call the thing
'lut' rather than 'blob_data'. This is the name the load_lut()
code used before already.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-5-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Split i9xx_read_lut_8() to gmch vs. ilk variants

To mirror the load_luts path let's clone an ilk+ version
from i9xx_read_lut_8(). I guess the extra branch isn't a huge
issue but feels better to make a clean split.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-4-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Clean up i9xx_load_luts_internal()

Split i9xx_load_luts_internal() into neat gmch vs. ilk+ chunks.
Avoids at least one branch in the inner loop, and makes life
a bit less confusing.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-3-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915: Polish CHV CGM CSC loading

Only load the CGM CSC based on the cgm_mode bit like we
do with the gamma/degamma LUTs. And make the function
naming and arguments consistent as well.

TODO: the code to convert the coefficients look totally
bogus. IIRC CHV uses two's complement format but the code
certainly doesn't generate that, so probably negative
coefficients are totally busted.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303173313.28117-2-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915/gt: Mark up intel_rps.active for racy reads

We read the current state of intel_rps.active outside of the lock, so
mark up the racy access.

[  525.037073] BUG: KCSAN: data-race in intel_rps_boost [i915] / intel_rps_park [i915]
[  525.037091]
[  525.037103] write to 0xffff8881f145efa1 of 1 bytes by task 192 on cpu 2:
[  525.037331]  intel_rps_park+0x72/0x230 [i915]
[  525.037552]  __gt_park+0x61/0xa0 [i915]
[  525.037771]  ____intel_wakeref_put_last+0x42/0x90 [i915]
[  525.037991]  __intel_wakeref_put_work+0xd3/0xf0 [i915]
[  525.038008]  process_one_work+0x3b1/0x690
[  525.038022]  worker_thread+0x80/0x670
[  525.038037]  kthread+0x19a/0x1e0
[  525.038051]  ret_from_fork+0x1f/0x30
[  525.038062]
[  525.038074] read to 0xffff8881f145efa1 of 1 bytes by task 733 on cpu 3:
[  525.038304]  intel_rps_boost+0x67/0x1f0 [i915]
[  525.038535]  i915_request_wait+0x562/0x5d0 [i915]
[  525.038764]  i915_gem_object_wait_fence+0x81/0xa0 [i915]
[  525.038994]  i915_gem_object_wait_reservation+0x489/0x520 [i915]
[  525.039224]  i915_gem_wait_ioctl+0x167/0x2b0 [i915]
[  525.039241]  drm_ioctl_kernel+0xe4/0x120
[  525.039255]  drm_ioctl+0x297/0x4c7
[  525.039269]  ksys_ioctl+0x89/0xb0
[  525.039282]  __x64_sys_ioctl+0x42/0x60
[  525.039296]  do_syscall_64+0x6e/0x2c0
[  525.039311]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309113623.24208-1-chris@chris-wilson.co.uk

drm/i915/execlsts: Mark up racy inspection of current i915_request priority

[  120.176548] BUG: KCSAN: data-race in __i915_schedule [i915] / effective_prio [i915]
[  120.176566]
[  120.176577] write to 0xffff8881e35e6540 of 4 bytes by task 730 on cpu 3:
[  120.176792]  __i915_schedule+0x63e/0x920 [i915]
[  120.177007]  __bump_priority+0x63/0x80 [i915]
[  120.177220]  __i915_sched_node_add_dependency+0x258/0x300 [i915]
[  120.177438]  i915_sched_node_add_dependency+0x50/0xa0 [i915]
[  120.177654]  i915_request_await_dma_fence+0x1da/0x530 [i915]
[  120.177867]  i915_request_await_object+0x2fe/0x470 [i915]
[  120.178081]  i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[  120.178292]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[  120.178309]  drm_ioctl_kernel+0xe4/0x120
[  120.178322]  drm_ioctl+0x297/0x4c7
[  120.178335]  ksys_ioctl+0x89/0xb0
[  120.178348]  __x64_sys_ioctl+0x42/0x60
[  120.178361]  do_syscall_64+0x6e/0x2c0
[  120.178375]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  120.178387]
[  120.178397] read to 0xffff8881e35e6540 of 4 bytes by interrupt on cpu 2:
[  120.178606]  effective_prio+0x25/0xc0 [i915]
[  120.178812]  process_csb+0xe8b/0x10a0 [i915]
[  120.179021]  execlists_submission_tasklet+0x30/0x170 [i915]
[  120.179038]  tasklet_action_common.isra.0+0x42/0xa0
[  120.179053]  __do_softirq+0xd7/0x2cd
[  120.179066]  irq_exit+0xbe/0xe0
[  120.179078]  do_IRQ+0x51/0x100
[  120.179090]  ret_from_intr+0x0/0x1c
[  120.179104]  cpuidle_enter_state+0x1b8/0x5d0
[  120.179117]  cpuidle_enter+0x50/0x90
[  120.179131]  do_idle+0x1a1/0x1f0
[  120.179145]  cpu_startup_entry+0x14/0x16
[  120.179158]  start_secondary+0x120/0x180
[  120.179172]  secondary_startup_64+0xa4/0xb0

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-5-chris@chris-wilson.co.uk

drm/i915/execlists: Mark up read of i915_request.fence.flags

[  145.927961] BUG: KCSAN: data-race in can_merge_rq [i915] / signal_irq_work [i915]
[  145.927980]
[  145.927992] write (marked) to 0xffff8881e513fab0 of 8 bytes by interrupt on cpu 2:
[  145.928250]  signal_irq_work+0x134/0x640 [i915]
[  145.928268]  irq_work_run_list+0xd7/0x120
[  145.928283]  irq_work_run+0x1d/0x50
[  145.928300]  smp_irq_work_interrupt+0x21/0x30
[  145.928328]  irq_work_interrupt+0xf/0x20
[  145.928356]  _raw_spin_unlock_irqrestore+0x34/0x40
[  145.928596]  execlists_submission_tasklet+0xde/0x170 [i915]
[  145.928616]  tasklet_action_common.isra.0+0x42/0xa0
[  145.928632]  __do_softirq+0xd7/0x2cd
[  145.928646]  irq_exit+0xbe/0xe0
[  145.928665]  do_IRQ+0x51/0x100
[  145.928684]  ret_from_intr+0x0/0x1c
[  145.928699]  schedule+0x0/0xb0
[  145.928719]  worker_thread+0x194/0x670
[  145.928743]  kthread+0x19a/0x1e0
[  145.928765]  ret_from_fork+0x1f/0x30
[  145.928784]
[  145.928796] read to 0xffff8881e513fab0 of 8 bytes by task 738 on cpu 1:
[  145.929046]  can_merge_rq+0xb1/0x100 [i915]
[  145.929282]  __execlists_submission_tasklet+0x866/0x25a0 [i915]
[  145.929518]  execlists_submit_request+0x2a4/0x2b0 [i915]
[  145.929758]  submit_notify+0x8f/0xc0 [i915]
[  145.929989]  __i915_sw_fence_complete+0x5d/0x3e0 [i915]
[  145.930221]  i915_sw_fence_complete+0x58/0x80 [i915]
[  145.930453]  i915_sw_fence_commit+0x16/0x20 [i915]
[  145.930698]  __i915_request_queue+0x60/0x70 [i915]
[  145.930935]  i915_gem_do_execbuffer+0x3997/0x4c20 [i915]
[  145.931175]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[  145.931194]  drm_ioctl_kernel+0xe4/0x120
[  145.931208]  drm_ioctl+0x297/0x4c7
[  145.931222]  ksys_ioctl+0x89/0xb0
[  145.931238]  __x64_sys_ioctl+0x42/0x60
[  145.931260]  do_syscall_64+0x6e/0x2c0
[  145.931275]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-4-chris@chris-wilson.co.uk

drm/i915/gt: Mark up racy check of last list element

[   25.025543] BUG: KCSAN: data-race in __i915_request_create [i915] / process_csb [i915]
[   25.025561]
[   25.025573] write (marked) to 0xffff8881e85c1620 of 8 bytes by task 696 on cpu 1:
[   25.025789]  __i915_request_create+0x54b/0x5d0 [i915]
[   25.026001]  i915_request_create+0xcc/0x150 [i915]
[   25.026218]  i915_gem_do_execbuffer+0x2f70/0x4c20 [i915]
[   25.026428]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[   25.026445]  drm_ioctl_kernel+0xe4/0x120
[   25.026459]  drm_ioctl+0x297/0x4c7
[   25.026472]  ksys_ioctl+0x89/0xb0
[   25.026484]  __x64_sys_ioctl+0x42/0x60
[   25.026497]  do_syscall_64+0x6e/0x2c0
[   25.026510]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   25.026522]
[   25.026532] read to 0xffff8881e85c1620 of 8 bytes by interrupt on cpu 2:
[   25.026742]  process_csb+0x8d6/0x1070 [i915]
[   25.026949]  execlists_submission_tasklet+0x30/0x170 [i915]
[   25.026969]  tasklet_action_common.isra.0+0x42/0xa0
[   25.026984]  __do_softirq+0xd7/0x2cd
[   25.026997]  irq_exit+0xbe/0xe0
[   25.027009]  do_IRQ+0x51/0x100
[   25.027021]  ret_from_intr+0x0/0x1c
[   25.027033]  poll_idle+0x3e/0x13b
[   25.027047]  cpuidle_enter_state+0x189/0x5d0
[   25.027060]  cpuidle_enter+0x50/0x90
[   25.027074]  do_idle+0x1a1/0x1f0
[   25.027086]  cpu_startup_entry+0x14/0x16
[   25.027100]  start_secondary+0x120/0x180
[   25.027116]  secondary_startup_64+0xa4/0xb0

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-2-chris@chris-wilson.co.uk

drm/i915: Mark up unlocked update of i915_request.hwsp_seqno

During i915_request_retire() we decouple the i915_request.hwsp_seqno
from the intel_timeline so that it may be freed before the request is
released. However, we need to warn the compiler that the pointer may
update under its nose.

[  171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fence [i915] / i915_request_retire [i915]
[  171.438920]
[  171.438932] write to 0xffff8881e7e28ce0 of 8 bytes by task 148 on cpu 2:
[  171.439174]  i915_request_retire+0x1ea/0x660 [i915]
[  171.439408]  retire_requests+0x7a/0xd0 [i915]
[  171.439640]  engine_retire+0xa1/0xe0 [i915]
[  171.439657]  process_one_work+0x3b1/0x690
[  171.439671]  worker_thread+0x80/0x670
[  171.439685]  kthread+0x19a/0x1e0
[  171.439701]  ret_from_fork+0x1f/0x30
[  171.439721]
[  171.439739] read to 0xffff8881e7e28ce0 of 8 bytes by task 696 on cpu 1:
[  171.439990]  i915_request_await_dma_fence+0x162/0x520 [i915]
[  171.440230]  i915_request_await_object+0x2fe/0x470 [i915]
[  171.440467]  i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[  171.440704]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[  171.440722]  drm_ioctl_kernel+0xe4/0x120
[  171.440736]  drm_ioctl+0x297/0x4c7
[  171.440750]  ksys_ioctl+0x89/0xb0
[  171.440766]  __x64_sys_ioctl+0x42/0x60
[  171.440788]  do_syscall_64+0x6e/0x2c0
[  171.440802]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309110934.868-1-chris@chris-wilson.co.uk

drm/i915/execlists: Mark up the racy access to switch_priority_hint

[ 7534.150687] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] / process_csb [i915]
[ 7534.150706]
[ 7534.150717] write to 0xffff8881f1bc24b4 of 4 bytes by task 24404 on cpu 3:
[ 7534.150925]  __execlists_submission_tasklet+0x1158/0x2780 [i915]
[ 7534.151133]  execlists_submit_request+0x2e8/0x2f0 [i915]
[ 7534.151348]  submit_notify+0x8f/0xc0 [i915]
[ 7534.151549]  __i915_sw_fence_complete+0x5d/0x3e0 [i915]
[ 7534.151753]  i915_sw_fence_complete+0x58/0x80 [i915]
[ 7534.151963]  i915_sw_fence_commit+0x16/0x20 [i915]
[ 7534.152179]  __i915_request_queue+0x60/0x70 [i915]
[ 7534.152388]  i915_gem_do_execbuffer+0x3997/0x4c20 [i915]
[ 7534.152598]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 7534.152615]  drm_ioctl_kernel+0xe4/0x120
[ 7534.152629]  drm_ioctl+0x297/0x4c7
[ 7534.152642]  ksys_ioctl+0x89/0xb0
[ 7534.152654]  __x64_sys_ioctl+0x42/0x60
[ 7534.152667]  do_syscall_64+0x6e/0x2c0
[ 7534.152681]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 7534.152693]
[ 7534.152703] read to 0xffff8881f1bc24b4 of 4 bytes by interrupt on cpu 2:
[ 7534.152914]  process_csb+0xe7c/0x10a0 [i915]
[ 7534.153120]  execlists_submission_tasklet+0x30/0x170 [i915]
[ 7534.153138]  tasklet_action_common.isra.0+0x42/0xa0
[ 7534.153153]  __do_softirq+0xd7/0x2cd
[ 7534.153166]  run_ksoftirqd+0x15/0x20
[ 7534.153180]  smpboot_thread_fn+0x1ab/0x300
[ 7534.153194]  kthread+0x19a/0x1e0
[ 7534.153207]  ret_from_fork+0x1f/0x30

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309144249.10309-1-chris@chris-wilson.co.uk

drm/i915: Mark racy read of intel_engine_cs.saturated

[ 3783.276728] BUG: KCSAN: data-race in __i915_request_submit [i915] / i915_request_await_dma_fence [i915]
[ 3783.276766]
[ 3783.276787] write to 0xffff8881f1bc60a0 of 1 bytes by interrupt on cpu 2:
[ 3783.277187]  __i915_request_submit+0x47e/0x4a0 [i915]
[ 3783.277580]  __execlists_submission_tasklet+0x997/0x2780 [i915]
[ 3783.277973]  execlists_submission_tasklet+0xd3/0x170 [i915]
[ 3783.278006]  tasklet_action_common.isra.0+0x42/0xa0
[ 3783.278035]  __do_softirq+0xd7/0x2cd
[ 3783.278063]  irq_exit+0xbe/0xe0
[ 3783.278089]  do_IRQ+0x51/0x100
[ 3783.278114]  ret_from_intr+0x0/0x1c
[ 3783.278140]  finish_task_switch+0x72/0x260
[ 3783.278170]  __schedule+0x1e5/0x510
[ 3783.278198]  schedule+0x45/0xb0
[ 3783.278226]  smpboot_thread_fn+0x23e/0x300
[ 3783.278256]  kthread+0x19a/0x1e0
[ 3783.278283]  ret_from_fork+0x1f/0x30
[ 3783.278305]
[ 3783.278327] read to 0xffff8881f1bc60a0 of 1 bytes by task 19440 on cpu 3:
[ 3783.278724]  i915_request_await_dma_fence+0x2a6/0x530 [i915]
[ 3783.279130]  i915_request_await_object+0x2fe/0x470 [i915]
[ 3783.279524]  i915_gem_do_execbuffer+0x45dc/0x4c20 [i915]
[ 3783.279908]  i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
[ 3783.279940]  drm_ioctl_kernel+0xe4/0x120
[ 3783.279968]  drm_ioctl+0x297/0x4c7
[ 3783.279996]  ksys_ioctl+0x89/0xb0
[ 3783.280021]  __x64_sys_ioctl+0x42/0x60
[ 3783.280047]  do_syscall_64+0x6e/0x2c0
[ 3783.280074]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309132726.28358-1-chris@chris-wilson.co.uk

drm/i915/gt: Mark up intel_rps.active for racy reads

We read the current state of intel_rps.active outside of the lock, so
mark up the racy access.

[  525.037073] BUG: KCSAN: data-race in intel_rps_boost [i915] / intel_rps_park [i915]
[  525.037091]
[  525.037103] write to 0xffff8881f145efa1 of 1 bytes by task 192 on cpu 2:
[  525.037331]  intel_rps_park+0x72/0x230 [i915]
[  525.037552]  __gt_park+0x61/0xa0 [i915]
[  525.037771]  ____intel_wakeref_put_last+0x42/0x90 [i915]
[  525.037991]  __intel_wakeref_put_work+0xd3/0xf0 [i915]
[  525.038008]  process_one_work+0x3b1/0x690
[  525.038022]  worker_thread+0x80/0x670
[  525.038037]  kthread+0x19a/0x1e0
[  525.038051]  ret_from_fork+0x1f/0x30
[  525.038062]
[  525.038074] read to 0xffff8881f145efa1 of 1 bytes by task 733 on cpu 3:
[  525.038304]  intel_rps_boost+0x67/0x1f0 [i915]
[  525.038535]  i915_request_wait+0x562/0x5d0 [i915]
[  525.038764]  i915_gem_object_wait_fence+0x81/0xa0 [i915]
[  525.038994]  i915_gem_object_wait_reservation+0x489/0x520 [i915]
[  525.039224]  i915_gem_wait_ioctl+0x167/0x2b0 [i915]
[  525.039241]  drm_ioctl_kernel+0xe4/0x120
[  525.039255]  drm_ioctl+0x297/0x4c7
[  525.039269]  ksys_ioctl+0x89/0xb0
[  525.039282]  __x64_sys_ioctl+0x42/0x60
[  525.039296]  do_syscall_64+0x6e/0x2c0
[  525.039311]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200309113623.24208-1-chris@chris-wilson.co.uk

drm/i915/tgl: Don't treat unslice registers as masked

The UNSLICE_UNIT_LEVEL_CLKGATE and UNSLICE_UNIT_LEVEL_CLKGATE2 registers
that we update in a few engine workarounds are not masked registers
(i.e., we don't have to write a mask bit in the top 16 bits when
updating one of the lower 16 bits).  As such, these workarounds should
be applied via wa_write_or() rather than wa_masked_en()

v2:
 - Rebase

Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Reported-by: kernelci.org bot <bot@kernelci.org>
References: https://github.com/ClangBuiltLinux/linux/issues/918
Fixes: 50148a25f841 ("drm/i915/tgl: Move and restrict Wa_1408615072")
Fixes: 3551ff928744 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()")
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306171139.1414649-1-matthew.d.roper@intel.com

drm/i915: Fix documentation for intel_dpll_get_freq()

Fix the following kerneldoc warning and while at it also the doc for the
corresponding vfunc hook.

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs'

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304150918.25473-1-imre.deak@intel.com

drm/i915/gt: Wait for the wa batch to be pinned

Be sure to wait for the vma to be in place before we tell the GPU to
execute from the wa batch. Since initialisation is mostly synchronous
(or rather at some point during start up we will need to sync anyway),
we can affort to do an explicit i915_vma_sync() during wa batch
construction rather than check for a required await on every context
switch. (We don't expect to change the wa bb at run time so paying the
cost once up front seems preferrable.)

Fixes: ee2413eeed76 ("drm/i915: Add mechanism to submit a context WA on ring submission")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200307122425.29114-1-chris@chris-wilson.co.uk

drm/i915/gt: Close race between cacheline_retire and free

If the cacheline may still be busy, atomically mark it for future
release, and only if we can determine that it will never be used again,
immediately free it.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1392
Fixes: ebece7539242 ("drm/i915: Keep timeline HWSP allocated until idle across the system")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.2+
Link: https://patchwork.freedesktop.org/patch/msgid/20200306154647.3528345-1-chris@chris-wilson.co.uk

drm/i915/execlists: Enable timeslice on partial virtual engine dequeue

If we stop filling the ELSP due to an incompatible virtual engine
request, check if we should enable the timeslice on behalf of the queue.

This fixes the case where we are inspecting the last->next element when
we know that the last element is the last request in the execution queue,
and so decided we did not need to enable timeslicing despite the intent
to do so!

Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306113012.3184606-1-chris@chris-wilson.co.uk

drm/i915/selftests: Apply a heavy handed flush to i915_active

Due to the ordering of cmpxchg()/dma_fence_signal() inside node_retire(),
we must also use the xchg() as our primary memory barrier to flush the
outstanding callbacks after expected completion of the i915_active.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306133852.3420322-1-chris@chris-wilson.co.uk

drm/i915: Do not poison i915_request.link on removal

Do not poison the timeline link on the i915_request to allow both
forward/backward list traversal under RCU.

[ 9759.139229] RIP: 0010:active_request+0x2a/0x90 [i915]
[ 9759.139240] Code: 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 c5 60 e8 49 de dc e0 48 8b 83 e8 01 00 00 48 39 c5 74 12 48 8d 90 20 fe ff ff <48> 8b 80 50 fe ff ff a8 01 74 11 e8 66 20 dd e0 48 89 d8 5b 5d 41
[ 9759.139251] RSP: 0018:ffffc9000014ce80 EFLAGS: 00010012
[ 9759.139260] RAX: dead000000000122 RBX: ffff888817cac040 RCX: 0000000000022000
[ 9759.139267] RDX: deacffffffffff42 RSI: ffff888817cac040 RDI: ffff888851fee900
[ 9759.139275] RBP: ffff888851fee960 R08: 000000000000001a R09: ffffffffa04702e0
[ 9759.139282] R10: ffffffff82187ea0 R11: 0000000000000002 R12: 0000000000000004
[ 9759.139289] R13: ffffffffa04d5179 R14: ffff8887f994ae40 R15: ffff888857b9a068
[ 9759.139296] FS:  0000000000000000(0000) GS:ffff88885ed80000(0000) knlGS:0000000000000000
[ 9759.139304] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 9759.139311] CR2: 00007fff5bdec000 CR3: 00000008534fe001 CR4: 00000000001606e0
[ 9759.139318] Call Trace:
[ 9759.139325]  <IRQ>
[ 9759.139389]  execlists_reset+0x14d/0x310 [i915]
[ 9759.139400]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[ 9759.139445]  ? fwtable_read32+0x90/0x230 [i915]
[ 9759.139499]  execlists_submission_tasklet+0xf6/0x150 [i915]
[ 9759.139508]  tasklet_action_common.isra.17+0x32/0xa0
[ 9759.139516]  __do_softirq+0x114/0x3dc
[ 9759.139525]  ? handle_irq_event_percpu+0x59/0x70
[ 9759.139533]  irq_exit+0xa1/0xc0
[ 9759.139540]  do_IRQ+0x76/0x150
[ 9759.139547]  common_interrupt+0xf/0xf
[ 9759.139554]  </IRQ>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306140115.3495686-1-chris@chris-wilson.co.uk

drm/i915/tgl: Make Wa_1606700617 permanent

This workaround is to disable FF DOP Clock gating. The fix
in B0 was backed out due to timing reasons and decided to
be made permanent.

Bspec: 52890
Signed-off-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305181204.28856-1-swathi.dhanavanthri@intel.com

drm/i915/hotplug: Use phy to get the hpd_pin instead of the port (v5)

On some platforms such as Elkhart Lake, although we may use DDI D
to drive a connector, we have to use PHY A (Combo Phy PORT A) to
detect the hotplug interrupts as per the spec because there is no
one-to-one mapping between DDIs and PHYs. Therefore, use the
function intel_port_to_phy() which contains the logic for such
mapping(s) to find the correct hpd_pin.

This change should not affect other platforms as there is always
a one-to-one mapping between DDIs and PHYs.

v2:
- Convert the case statements to use PHYs instead of PORTs (Jani)

v3:
- Refactor the function to reduce the number of return statements by
  lumping all the case statements together except PHY_F which needs
  special handling (Jose)

v4:
- Add a comment describing how the HPD pin value associated with any
  port can be retrieved using port or phy enum value. (Jani)

v5:
- Use case ranges instead of individual labels and also normalize the
  return statement by adding -PHY_A to the expression (Ville)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304234240.12062-1-vivek.kasireddy@intel.com

drm/i915/selftests: try to rein in alloc_smoke

Depending on RNG we might try to fill an 8G region for every possible
order, using the smallest possible chunk size of 4K, which seems to be
very slow. Try to remedy the situation by adding an overall timeout for
the test, while also selecting each order level in a random fashion.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1310
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305204711.217783-2-matthew.auld@intel.com

drm/i915/buddy: avoid double list_add

Be careful not to mark an already free node as free again.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305204711.217783-1-matthew.auld@intel.com

drm/i915: properly sanity check batch_start_offset

Check the edge case where batch_start_offset sits exactly on the batch
size.

v2: add new range_overflows variant to capture the special case where
the size is permitted to be zero, like with batch_len.

v3: other way around. the common case is the exclusive one which should
just be >=, with that we then just need to convert the three odd ball
cases that don't apply to use the new inclusive _end version.

Testcase: igt/gem_exec_params/invalid-batch-start-offset
Fixes: 0b5372727be3 ("drm/i915/cmdparser: Use cached vmappings")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306094735.258285-1-matthew.auld@intel.com

drm/i915/gem: Limit struct_mutex to eb_reserve

We only need to serialise the multiple pinning during the eb_reserve
phase. Ideally this would be using the vm->mutex as an outer lock, or
using a composite global mutex (ww_mutex), but at the moment we are
using struct_mutex for the group.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1381
Fixes: 003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306071614.2846708-3-chris@chris-wilson.co.uk

drm/i915: Always propagate the invocation to i915_schedule

We only call i915_schedule() when we know we have changed the priority
on a request and so require to propagate any change in priority to its
signalers (for PI). By unconditionally checking all of our signalers, we
avoid skipping changes made prior to construction of the request (as the
request may be waited upon before submission when used in parallel).

References: https://gitlab.freedesktop.org/drm/intel/issues/1318
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306071614.2846708-2-chris@chris-wilson.co.uk

drm/i915: Assert requests within a context are submitted in order

Check the flow of requests into the hardware to verify that are
submitted in order along their timeline.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306071614.2846708-1-chris@chris-wilson.co.uk

drm/i915: be more solid in checking the alignment

The alignment is u64, and yet is_power_of_2() assumes unsigned long,
which might give different results between 32b and 64b kernel.

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305203534.210466-1-matthew.auld@intel.com
Cc: stable@vger.kernel.org

drm/i915/phys: unconditionally call release_memory_region

The release method will undo what we did at creation, and so we
shouldn't care if we have pages or not. Fixes a small leak in the
mock_phys selftest.

Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305204258.216302-1-matthew.auld@intel.com

drm/i915/gen7: Clear all EU/L3 residual contexts

On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.

This security mitigation changes does not triggers any performance
regression. Performance is on par with current drm-tips.

v2: Add igt generated header file for CB kernel assembled with Mesa tool
and addressed use of Kernel macro for ptr_align comment.

v3: Resolve Sparse warnings with newly generated, and imported CB
kernel.

v4: Include new igt generated CB kernel for gen7 and gen7.5. Also
add code formatting and compiler warnings changes (Chris Wilson)

Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Balestrieri Francesco <francesco.balestrieri@intel.com>
Cc: Bloomfield Jon <jon.bloomfield@intel.com>
Cc: Dutt Sudeep <sudeep.dutt@intel.com>
Acked-by: Chris Wilson <chris@chris-wilso.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306000957.2836150-2-chris@chris-wilson.co.uk

drm/i915: Add mechanism to submit a context WA on ring submission

This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.

The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.

However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.

This security mitigation change does not trigger any performance
regression. Performance is on par with current mainline/drm-tip.

v2: Update vm_alias params to point to correct address space "vm" due to
changes made in the patch "f21613797bae98773"

v3-v4: none

Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Balestrieri Francesco <francesco.balestrieri@intel.com>
Cc: Bloomfield Jon <jon.bloomfield@intel.com>
Cc: Dutt Sudeep <sudeep.dutt@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200306000957.2836150-1-chris@chris-wilson.co.uk

drm/i915/execlists: Show the "switch priority hint" in dumps

Show the timeslicing priority hint in engine dumps to aide debugging.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305135843.2760512-1-chris@chris-wilson.co.uk

drm/i915: Return early for await_start on same timeline

Requests within a timeline are ordered by that timeline, so awaiting for
the start of a request within the timeline is a no-op. This used to work
by falling out of the mutex_trylock() as the signaler and waiter had the
same timeline and not returning an error.

Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.5+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305134822.2750496-1-chris@chris-wilson.co.uk

drm/i915: Actually emit the await_start

Fix the inverted test to emit the wait on the end of the previous
request if we /haven't/ already.

Fixes: 6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.5+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200305104210.2619967-1-chris@chris-wilson.co.uk

drm/i915/display: Decrease log level

Converting error to debug print if sink fails to configure scrambling or
TMDS bit clock ratio. In this case, we are timing out while disabling
the scrambling and setting the SCDC ratio, as there is no response
to the I2C SCDC write from the sink device. Error isn't due to something
wrong done from driver side.

Signed-off-by: Swati Sharma <swati2.sharma@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302213807.6488-1-swati2.sharma@intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>

drm/i915: Implement display w/a 1140 for glk/cnl

Display w/a #1140 tells us we have to program the transition
watermark to the minimum value on glk/cnl. Let's do that.

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

drm/i915: Enable transition watermarks for glk

We are mistakenly skipping transition watermarks on glk. Fix
up the condition for glk, and toss in the w/a name from
the database.

v2: Reorder the ipc enabled vs. platform check to be more sensible

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20200228203552.30273-3-ville.syrjala@linux.intel.com

drm/i915: Don't check for wm changes until we've compute the wms fully

Currently we're comparing the watermarks between the old and new states
before we've fully computed the new watermarks. In particular
skl_build_pipe_wm() will not account for the amount of ddb space we'll
have. That information is only available during skl_compute_ddb()
which will proceed to zero out any watermark level exceeding the
ddb allocation. If we're short on ddb space this will end up
adding the plane to the state due erronously determining that the
watermarks have changed. Fix the problem by deferring
skl_wm_add_affected_planes() until we have the final watermarks
computed.

Noticed this when trying enable transition watermarks on glk.
We now computed the trans_wm as 28, but we only had 14 blocks
of ddb, and thus skl_compute_ddb() ended up disabling the cursor
trans_wm every time. Thus we ended up adding the cursor to every
commit that didn't actually affect the cursor at all.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228203552.30273-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915: Don't check uv_wm in skl_plane_wm_equals()

The hardware never sees the uv_wm values (apart from
uv_wm.min_ddb_alloc affecting the ddb allocation). Thus there
is no point in comparing uv_wm to determine if we need to
reprogram the watermark registers. So let's check only the
rgb/y watermark in skl_plane_wm_equals(). But let's leave
a comment behind so that the next person reading this doesn't
get as confused as I did when I added this check.

If the ddb allocation ends up changing due to uv_wm
skl_ddb_add_affected_planes() takes care of adding the plane
to the state.

TODO: we should perhaps just eliminate uv_wm from the state
and simply track the min_ddb_alloc for uv instead.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228203552.30273-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>

drm/i915/tgl: WaDisableGPGPUMidThreadPreemption

Enable FtrPerCtxtPreemptionGranularityControl bit and select thread-
group as the default preemption level.

v2:
 * Remove register whitelisting (Rafael, Tony).

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: piotr.zdunowski@intel.com
Cc: michal.mrozek@intel.com
Cc: Tony Ye <tony.ye@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Acked-by: Rafael Antognolli <rafael.antognolli@intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Tony Ye <tony.ye@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304153144.10675-1-tvrtko.ursulin@linux.intel.com

drm/i915/gt: Cancel banned contexts after GT reset

As we started marking the ce->gem_context as NULL on closure, we can no
longer use that to carry closure information. Instead, we can look at
whether the context was killed on closure instead.

Fixes: 130a95e9098e ("drm/i915/gem: Consolidate ctx->engines[] release")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1379
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304165113.2449213-1-chris@chris-wilson.co.uk

drm/i915: Add invert-brightness quirk for Thundersoft TST178 tablet

The Thundersoft TST178 tablet uses a DSI panel with an external PWM
controller (as all DSI panels do). But unlike other DSI panels a duty-cycle
of 100% turns the backlight off and 0% sets it to maximum brightness.

I've checked the VBT and there is a BDB_LVDS_BACKLIGHT section, but
it does not set the active_low_pwm flag. This tablet re-uses the main
PCI vendor and product ids for the subsystem ids, so I see no other option
then to add a DMI based quirk to fix this.

Note that the PWM backlight code in intel_panel.c currently does not honor
the vbt.active_low_pwm flag, but that does not matter in this case.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-2-hdegoede@redhat.com

drm/i915: panel: Use intel_panel_compute_brightness() from pwm_setup_backlight()

Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221172927.510027-1-hdegoede@redhat.com

drm/i915/gt: Propagate change in error status to children on unhold

As we release the head requests back into the queue, propagate any
change in error status that may have occurred while the requests were
temporarily suspended.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1277
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304121849.2448028-2-chris@chris-wilson.co.uk

drm/i915: Apply i915_request_skip() on submission

Trying to use i915_request_skip() prior to i915_request_add() causes us
to try and fill the ring upto request->postfix, which has not yet been
set, and so may cause us to memset() past the end of the ring.

Instead of skipping the request immediately, just flag the error on the
request (only accepting the first fatal error we see) and then clear the
request upon submission.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304121849.2448028-1-chris@chris-wilson.co.uk

drm/i915/ehl: Check PHY type before reading DPLL frequency

intel_ddi_clock_get() tests the DPLL ID against DPLL_ID_ICL_TBTPLL (2)
to determine whether to try to descend into a TBT-specific handler.
However this test will also be true when DPLL4 on EHL is used since that
shares the same DPLL ID (2).

Add an extra check to ensure the PHY is actually a Type-C PHY before
descending into the TBT handling.  This should ensure EHL still takes
the correct code path and somewhat future-proof the code as well.

v2: Drop the gen+ check since only gen11+ platforms can have Type-C
    outputs.  (Imre)

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1369
Fixes: 45e4728b87ad ("drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.c")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303195043.959913-1-matthew.d.roper@intel.com

drm/i915/gvt: Inlcude intel_gvt.h where needed

drivers/gpu/drm/i915/gvt/gvt.c:264:6: error: no previous prototype for ‘intel_gvt_clean_device’ [-Werror=missing-prototypes]
drivers/gpu/drm/i915/gvt/gvt.c:301:5: error: no previous prototype for ‘intel_gvt_init_device’ [-Werror=missing-prototypes]

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200304002331.2126072-1-chris@chris-wilson.co.uk

drm/i915: Force DPCD backlight mode for some Dell CML 2020 panels

According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls depending on whether or not the panel is in HDR or
SDR mode. Yikes.

Regardless, we need to add quirks for these so that DPCD backlight
controls get enabled by default, since without additional driver support
that's the only form of brightness control that will work. Hopefully in
the future we can remove these quirks once we have a better way of
probing for this.

Changes since v1:
* Add one more EDID per Dell's request
* Remove model number (which is possibly wrong) and replace with Dell
  CML 2020 systems

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-4-lyude@redhat.com
Reviewed-by: Adam Jackson <ajax@redhat.com>

drm/i915: Force DPCD backlight mode on X1 Extreme 2nd Gen 4K AMOLED panel

The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but we haven't gotten any more details on this from Lenovo
just yet. For the time being though, making sure the backlight 'just
works' is a bit more important.

So, add a quirk to force DPCD backlight controls on for these systems
based on EDID (since this panel doesn't appear to fill in the device ID).
Hopefully in the future we'll figure out a better way of probing this.

Changes since v2:
* The bugzilla URL is deprecated, bug reporting happens on gitlab now.
  Update the messages we print to reflect this
* Also, take the opportunity to move FDO_BUG_URL out of i915_utils.c and
  into i915_utils.h so that other places which print things that aren't
  traditional errors but are worth filing bugs about, can actually use
  it.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303215320.93491-1-lyude@redhat.com

drm/dp: Introduce EDID-based quirks

The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I can't imagine it's a very good idea to try relying on OUIs
for applying quirks. As well, some laptop vendors have confirmed to us
that their panels have this exact issue.

So, let's introduce the ability to apply DP quirks based on EDID
identification. We reuse the same quirk bits for OUI-based quirks, so
that callers can simply check all possible quirks using
drm_dp_has_quirk().

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200211183358.157448-2-lyude@redhat.com

drm/i915/hdcp: Fix config_stream_type() ret value

DP shim's config_stream_type considered to be succeeded when
return value of intel_dp_hdcp2_write_msg() equals to size of
message to be written, it makes config_stream_type to return
a zero success value in order to succeed the HDCP auth.

v2:
- config_stream_type() returns 0 on success. [Ram]

CC: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303073838.25871-1-anshuman.gupta@intel.com

drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg

HDCP Repeater initializes seq_num_V to 0 at the beginning of
hdcp Session i.e. after AKE_init received, refer
HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20.

HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT
considers failure of authentication if the repeater provides a
non-zero value in seq_num_V in the first,
RepeaterAuth_Send_ReceiverID_List message.

Make sure that HDCP repeater initializes seq_num_V to zero at
beginning of session i.e. after AKE_Init, fail the Auth if
there is non zero seq_num_V.

v2:
- Used existing hdcp2_encrypted flag instead of
  declaring new flag. [Ram]

Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220123217.23635-2-anshuman.gupta@intel.com

drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl

As we no longer stash anything inside i915_vma under the exclusive
protection of struct_mutex, we do not need to revoke the i915_vma
stashes before dropping struct_mutex to handle pagefaults. Knowing that
we must drop the struct_mutex while keeping the eb->vma around, means
that we are required to hold onto to the object reference until we have
marked the vma as active.

Fixes: 155ab8836caa ("drm/i915: Move object close under its own lock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-3-chris@chris-wilson.co.uk

drm/i915/gem: Extract transient execbuf flags from i915_vma

For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as our
primary means of tracking the user's list of objects and their virtual
mappings, we use a local eb_vma with the same lists as before (just now
local not global).

This should allow us to only perform the lookup of vma used for
execution once during the execbuf ioctl, as currently we need to remove
our secrets from inside i915_vma everytime we drop the struct_mutex as
another execbuf may use the shared locations.

Once potential user visible consequence is that we can remove the
requirement that the execobj[] be unique, and only require that they do
not conflict (i.e. you cannot softpin the same object into two locations.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-2-chris@chris-wilson.co.uk

drm/i915: Drop inspection of execbuf flags during evict

With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_node() is
the only user outside of execbuf that currently peeks at the flag to
convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
this nicety and only report ENOSPC if the location is in current use,
either due to this execbuf or another.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303204345.1859734-1-chris@chris-wilson.co.uk

drm/i915/tgl: Move and restrict Wa_1408615072

Following the changes in the previous patch
"drm/i915/gen11: Moving WAs to rcs_engine_wa_init()" also moving TGL
Wa_1408615072 to rcs_engine_wa_init() this way after a engine
reset it will be reapplied also restricting it to A0 as it is fixed in
B0 stepping.

BSpec: 52890
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302231421.224322-2-jose.souza@intel.com

drm/i915/gen11: Moving WAs to rcs_engine_wa_init()

This are register of render engine, so after a render reset those
would return to the default value and init_clock_gating() is not
called for single engine reset.
So here moving it rcs_engine_wa_init() that will guarantee that this
WAs will not be lost.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302231421.224322-1-jose.souza@intel.com

drm/i915/selftests: Fix uninitialized variable

Static code analysis tool identified struct lrc_timestamp data as being
uninitialized and then data.ce[] is being checked for NULL/negative
value in the error path. Initializing data variable fixes the issue.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303142347.15696-1-aditya.swarup@intel.com

drm/i915/gt: Drop the timeline->mutex as we wait for retirement

As we have pinned the timeline (using tl->active_count), we can safely
drop the tl->mutex as we wait for what we believe to be the final
request on that timeline. This is useful for ensuring that we do not
block the engine heartbeat by hogging the kernel_context's timeline on a
dead GPU.

References: https://gitlab.freedesktop.org/drm/intel/issues/1364
Fixes: 058179e72e09 ("drm/i915/gt: Replace hangcheck by heartbeats")
Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303140009.1494819-1-chris@chris-wilson.co.uk

drm/i915: Drop vma is-closed assertion on insert

The is-closed flag may be added after we have acquired the vma under the
ctx->mutex, but will not take effect until after we release the
vm->mutex. i.e. the flag may be set on the vma as attempt to bind it and
that will cause the vma to be unbound later after we unpin it.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303093157.1153887-1-chris@chris-wilson.co.uk

drm/i915/gem: Check that the context wasn't closed during setup

As setup takes a long time, the user may close the context during the
construction of the execbuf. In order to make sure we correctly track
all outstanding work with non-persistent contexts, we need to serialise
the submission with the context closure and mop up any leaks.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-3-chris@chris-wilson.co.uk

drm/i915/gt: Prevent allocation on a banned context

If a context is banned even before we submit our first request to it,
report the failure before we attempt to allocate any resources for the
context.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-2-chris@chris-wilson.co.uk

drm/i915/gem: Consolidate ctx->engines[] release

Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.

v2ish: Use the ce->pin_count to close the execbuf gap.

Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-1-chris@chris-wilson.co.uk

drm/i915: Polish CHV .load_luts() a bit

It irks me to use crtc_state_is_legacy_gamma() inside the guts
of the CHV color management code. Let's get rid of it and instead
just consult cgm_mode to figure out if we want to enable the pipe
gamma or the CGM gamma.

Also CHV display engine is based on i965/g4x so we should fall back
to the i965 path when the CGM gamma is not used.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-3-ville.syrjala@linux.intel.com
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>

drm/i915/gvt: only include intel_gvt.h where needed

i915_drv.c is the only caller.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-3-jani.nikula@intel.com

drm/i915/gvt: make intel_gvt_active internal to intel_gvt

Nobody else uses it.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-2-jani.nikula@intel.com

drm/i915/vgpu: improve vgpu abstractions

Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to
intel_vgpu_detect() to match other function naming, un-inline
intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and
intel_vgpu_has_huge_gtt() to reduce header interdependencies.

The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-1-jani.nikula@intel.com

drm/i915: Fix kbuild test robot build error

has_transcoder() was unused because function which was using it,
intel_display_capture_error_state() defined under
CONFIG_DRM_I915_CAPTURE_ERROR.
Moving has_transcoder() to under CONFIG_DRM_I915_CAPTURE_ERROR.
No functional change.

Fixes: d54c1a513c48 ("drm/i915: Fix broken transcoder err state")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227175147.11362-1-anshuman.gupta@intel.com

drm/i915/hdcp: conversion to struct drm_device based logging macros.

Converts remaining instances of the printk based logging macros in
i915/display/intel_hdcp.c with the struct drm_device based macros
manually.

This is continuation of commit 65833c463886 ("drm/i915/hdcp: conversion
to struct drm_device based logging macros.")

v2:
  i915_dev_priv is used instead of drm_device for reusability [JaniN]
v3:
  Made it independent from the series.
  once instance of dev_priv naming is changed to i915 [Jani N]

Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212123007.6659-1-ramalingam.c@intel.com

drm/i915: move watermark structs more towards usage

Shrink i915_drv.h a bit by moving watermark structs where they are
needed.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227170047.31089-3-jani.nikula@intel.com

drm/i915: Fix doclinks

Update locations for

./drivers/gpu/drm/i915/i915_vma.h:1: warning: 'Virtual Memory Address' not found
./drivers/gpu/drm/i915/i915_gem_gtt.c:1: warning: 'Global GTT views' not found

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302145254.520447-1-chris@chris-wilson.co.uk

drm/i915/dmc: Use firmware v2.06 for TGL

New firmware contains minor fixes around context restore.

Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227235005.18706-1-jose.souza@intel.com

drm/i915: fix documentation build after rename

intel_csr.c was moved under display.

Fixes: 06d3ff6e7451 ("drm/i915: move intel_csr.[ch] under display/")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302170218.16496-1-jani.nikula@intel.com

drm/i915/huc: update TGL HuC to v7.0.12

Update to the latest available TGL HuC, which includes changes required
by the media team.

Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Tony Ye <tony.ye@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200229012042.27487-1-daniele.ceraolospurio@intel.com

drm/i915/execlists: Check the sentinel is alone in the ELSP

We only use sentinel requests for "preempt-to-idle" passes, so assert
that they are the only request in a new submission.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-12-chris@chris-wilson.co.uk

drm/i915/perf: Reintroduce wait on OA configuration completion

We still need to wait for the initial OA configuration to happen
before we enable OA report writes to the OA buffer.

Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1356
Testcase: igt/perf/stream-open-close
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-7-chris@chris-wilson.co.uk

drm/i915/tgl: Add Wa number to WaAllowPMDepthAndInvocationCountAccessFromUMD

Just to make easier to check that the Wa was implemetend when
comparing to the number in BSpec.

BSpec: 52890
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-10-jose.souza@intel.com

drm/i915/tgl: Add note about Wa_1409142259

Different issues with the same fix, so justing adding
Wa_1409142259, Wa_1409252684, Wa_1409217633, Wa_1409207793,
Wa_1409178076 and 1408979724 to the comment so other devs can check if
this Was were implemetend with a simple grep.

Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-8-jose.souza@intel.com

drm/i915/tgl: Fix the Wa number of a fix

The Wa number for this fix is Wa_1607087056 the BSpec bug id is
1607087056, just updating to match BSpec.

BSpec: 52890
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-7-jose.souza@intel.com

drm/i915/tgl: Add note about Wa_1607063988

This issue workaround in Wa_1607063988 has the same fix as
Wa_1607138336, so just adding a note in the code.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-6-jose.souza@intel.com

drm/i915/tgl: Add note to Wa_1607297627

Add note about the confliting information in BSpec about this WA.

BSpec: 52890
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-5-jose.souza@intel.com

drm/i915/tgl: Extend Wa_1606931601 for all steppings

According to BSpec. Wa_1606931601 applies for all TGL steppings.
This patch moves the WA implementation out of A0 only block of
rcs_engine_wa_init().

The WA is has also been referred to by an alternate name
Wa_1607090982.

Bspec: 46045, 52890

Fixes: 3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982")
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-4-jose.souza@intel.com

drm/i915/tgl: Add Wa_1409085225, Wa_14010229206

Disable Push Constant buffer addition for TGL.

v2: typos, add additional Wa reference
v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit
message.

Bspec: 52890
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-3-jose.souza@intel.com

drm/i915/tgl: Implement Wa_1806527549

This will whitelist the HIZ_CHICKEN register so mesa can disable the
optimizations and avoid hang when using D16_UNORM.

v2: moved to the right place and used the right function() (Chris)

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-2-jose.souza@intel.com

drm/i915/tgl: Implement Wa_1409804808

This workaround the CS not done issue on PIPE_CONTROL.

v2:
- replaced BIT() by REG_BIT() in all GEN7_ROW_CHICKEN2() bits
- shortened the name of the new bit

BSpec: 52890
BSpec: 46218
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-1-jose.souza@intel.com

drm/i915: Unify the DPLL ref clock frequency tracking

All platforms using the shared DPLL framework use 3 reference clocks for
their DPLLs: SSC, non-SSC and DSI. For a more unified way across
platforms store the frequency of these ref clocks as part of the DPLL
global state. This also allows us to keep the HW access reading out the
ref clock value separate from the DPLL frequency calculation that
depends on the ref clock.

For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code
has its own logic for calculating DPLL parameters instead of the shared
DPLL framework.

v2:
- Apply the ICL combo PHY PLL ref_clock/2 adjustment during the
  frequency->PLL param conversion direction as well. (CI shards)
- s/kHZ/kHz/ (Ville)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228153328.17842-1-imre.deak@intel.com

drm/i915/hsw: Use the read-out WRPLL/SPLL state instead of reading out again

Instead of reading out the WRPLL/SPLL control values from HW, we can use
the DPLL state that was already read out, or swapped-to.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-13-imre.deak@intel.com

drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculation

Split out the PLL parameter->frequency conversion logic for each type of
PLL for symmetry with their corresponding inverse conversion functions.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-12-imre.deak@intel.com

drm/i915/hsw: Split out the WRPLL, LCPLL, SPLL frequency calculation

Split out the PLL parameter->frequency conversion logic for each type of
PLL for symmetry with their corresponding inverse conversion functions.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-11-imre.deak@intel.com

drm/i915/hsw: Split out the SPLL parameter calculation

For consistency with the WRPLL/LCPLL parameter calculation functions,
split out the SPLL specific logic to its own function.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-10-imre.deak@intel.com

drm/i915/hsw: Rename the get HDMI/DP DPLL funcs to get WRPLL/LCPLL

The types of PLLs used for HDMI/DP on HSW are WRPLL/LCPLL accordingly,
so use these names to align better with the rest of WRPLL/LCPLL function
names elsewhere.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-9-imre.deak@intel.com