- 09 Mar, 2020 16 commits
-
-
Ville Syrjälä authored
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.comReviewed-by:
Swati Sharma <swati2.sharma@intel.com>
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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:
-
Chris Wilson authored
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
-
Chris Wilson authored
[ 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 authored
[ 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 authored
[ 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 authored
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 authored
[ 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 authored
[ 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 authored
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:
-
Matt Roper authored
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: 50148a25 ("drm/i915/tgl: Move and restrict Wa_1408615072") Fixes: 3551ff92 ("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:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306171139.1414649-1-matthew.d.roper@intel.com
-
Imre Deak authored
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:
-
- 07 Mar, 2020 5 commits
-
-
Chris Wilson authored
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: ee2413ee ("drm/i915: Add mechanism to submit a context WA on ring submission") Signed-off-by:
-
Chris Wilson authored
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: ebece753 ("drm/i915: Keep timeline HWSP allocated until idle across the system") Signed-off-by:
-
Chris Wilson authored
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: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by:
-
Chris Wilson authored
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 authored
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:
-
- 06 Mar, 2020 12 commits
-
-
Swathi Dhanavanthri authored
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:
-
Vivek Kasireddy authored
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:
-
Matthew Auld authored
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/1310Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Matthew Auld authored
Be careful not to mark an already free node as free again. Signed-off-by:
-
Matthew Auld authored
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: 0b537272 ("drm/i915/cmdparser: Use cached vmappings") Signed-off-by:
-
Chris Wilson authored
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: 003d8b91 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl") Signed-off-by:
-
Chris Wilson authored
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/1318Signed-off-by:
-
Chris Wilson authored
Check the flow of requests into the hardware to verify that are submitted in order along their timeline. Signed-off-by:
-
Matthew Auld authored
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:
-
Abdiel Janulgue authored
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:
-
Prathap Kumar Valsan authored
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:
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:
-
Mika Kuoppala authored
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 "f2161379" v3-v4: none Signed-off-by:
-
- 05 Mar, 2020 7 commits
-
-
Chris Wilson authored
Show the timeslicing priority hint in engine dumps to aide debugging. Signed-off-by:
-
Chris Wilson authored
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: 6a79d848 ("drm/i915: Lock signaler timeline while navigating") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200305134822.2750496-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Fix the inverted test to emit the wait on the end of the previous request if we /haven't/ already. Fixes: 6a79d848 ("drm/i915: Lock signaler timeline while navigating") Signed-off-by:
-
Swati Sharma authored
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:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228203552.30273-4-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
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ä authored
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:
-
