- 15 May, 2024 1 commit
-
-
Matthew Brost authored
If PTEs are already invalidated no need to invalidate again. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240514232325.84508-1-matthew.brost@intel.com
-
- 14 May, 2024 13 commits
-
-
Jonathan Cavitt authored
Add an additional condition to the reset_status guc_exec_queue_op that returns true if the exec queue has been banned or killed or wedged. The reset_status op is only used for exiting any xe_wait_user_fence_ioctl that waits on an exec queue without timing out, so doing this will exit the ioctl early in cases where the exec queue can no longer function, such as after a GuC stop during a reset. Suggested-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
-
Jonathan Cavitt authored
LR queues currently don't get banned during a GT/GuC reset because they lack a job. Though they don't have a job to detect the reset status of, it's still possible to tell when they should be banned by looking at the LRC: if the LRC head and tail don't match, then the exec queue should be banned and cleaned up. This also requires swapping the usage of xe_sched_tdr_queue_imm with xe_guc_exec_queue_trigger_cleanup, as the former is specific to non-lr exec queues. Suggested-by:
-
Jonathan Cavitt authored
Reorder the xe_sched_tdr_queue_imm and set_exec_queue_banned calls in guc_exec_queue_stop. This prevents a possible race condition between the two events in which it's possible for xe_sched_tdr_queue_imm to wake the ufence waiter before the exec queue is banned, causing the ufence waiter to miss the banned state. Suggested-by:
-
Michal Wajdeczko authored
We shouldn't need anything from the GuC submission code until we finish GuC initialization in post hwconfig step. While around add diagnostic message if we fail uC init. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
We want to move the GuC submission initialization to the post hwconfig step, but now this step is done too late as migration initialization uses exec_queue that would crash due to a unset exec_queue_ops. We can easily fix that by small function reorder. Signed-off-by:
-
Matthew Brost authored
The GuC context scheduling queue is 2 entires deep, thus it is possible for a migration job to be stuck behind a fault if migration exec queue shares engines with user jobs. This can deadlock as the migrate exec queue is required to service page faults. Avoid deadlock by only using reserved BCS instances for usm migrate exec queue. Fixes: a043fbab ("drm/xe/pvc: Use fast copy engines as migrate engine on PVC") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
Brian Welty <brian.welty@intel.com>
-
Himal Prasad Ghimiray authored
The maximum timeout display uses in xe_pcode_request is 3 msec, add the warning in cases the function is misused with higher timeouts. Add a warning if pcode_try_request is not passed the timeout parameter greater than 0. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240508152216.3263109-3-himal.prasad.ghimiray@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Himal Prasad Ghimiray authored
Polling is initially attempted with timeout_base_ms enabled for preemption, and if it exceeds this timeframe, another attempt is made without preemption, allowing an additional 50 ms before timing out. v2 - Rebase v3 - Move warnings to separate patch (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Move it to xe_gt_init_early() that initializes the sw-only part for each gt. Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240513213751.1017791-5-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
xe_force_wake_init_gt() is a software-only initialization and doesn't need to be called from xe_device_probe(). Move it to initialize together with the gt. Reviewed-by:
-
Lucas De Marchi authored
Early shall be early enough, stop doing other things with gt before it. Now that xe_gt_init_early() doesn't need forcewake and doesn't depend on the fake engine_mask initialization, move it where it belongs: it doesn't need to be after hwconfig config anymore. Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240513213751.1017791-3-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
Forcewake used to be needed in xe_gt_init_early() since it was calling xe_gt_topology_init(). That call was dropped in commit 4c47049d ("drm/xe/guc: Fix missing topology init"), but the forcewake calls were left behind. Remove them. Cc: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by:
Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Not really used, it's just a copy of engine_mask, which already reads the fuses to mark engines as available/not-available. Reviewed-by:
-
- 13 May, 2024 4 commits
-
-
Michal Wajdeczko authored
Prefer forward declarations over #include xe_reg_sr_types.h Signed-off-by:
-
Michal Wajdeczko authored
Prefer forward declarations over #include xe_lrc_types.h Signed-off-by:
-
Michal Wajdeczko authored
We don't need to include xe_guc_ads_types.h here. Use forward declaration instead. Signed-off-by:
-
Michal Wajdeczko authored
We don't need to include drm/drm_managed.h here. We don't need to comment final #endif. Also remove empty line at the end. Signed-off-by:
-
- 09 May, 2024 4 commits
-
-
Michal Wajdeczko authored
To minimize the risk of future name collisions, rename macros to always include the ARG or ARGS tag: DROP_FIRST to DROP_FIRST_ARG PICK_FIRST to FIRST_ARG PICK_LAST to LAST_ARG Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Michal Wajdeczko authored
All other files with commands definitions are in instructions/ folder. Move xe_gpu_commands.h also there. Signed-off-by:
-
Karthik Poosa authored
Change umode of currN_label from 0644 to 0444 as write permission not needed for label. Signed-off-by:
Karthik Poosa <karthik.poosa@intel.com> Reviewed-by:
Riana Tauro <riana.tauro@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240419125945.4085629-1-karthik.poosa@intel.comSigned-off-by:
-
Shuicheng Lin authored
Here is the failure stack: [ 12.988209] ------------[ cut here ]------------ [ 12.988216] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 12.988232] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 12.988235] CPU: 4 PID: 1310 Comm: gnome-shell Tainted: G U 6.9.0-rc6+prerelease1158+ #19 [ 12.988237] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.3301.A02.2208050712 08/05/2022 [ 12.988239] Call Trace: [ 12.988240] <TASK> [ 12.988242] dump_stack_lvl+0xd7/0xf0 [ 12.988248] dump_stack+0x10/0x20 [ 12.988250] ubsan_epilogue+0x9/0x40 [ 12.988253] __ubsan_handle_shift_out_of_bounds+0x10e/0x170 [ 12.988260] dma_resv_reserve_fences.cold+0x2b/0x48 [ 12.988262] ? ww_mutex_lock_interruptible+0x3c/0x110 [ 12.988267] drm_exec_prepare_obj+0x45/0x60 [drm_exec] [ 12.988271] ? vm_bind_ioctl_ops_execute+0x5b/0x740 [xe] [ 12.988345] vm_bind_ioctl_ops_execute+0x78/0x740 [xe] It is caused by the value 0 of parameter num_fences in function drm_exec_prepare_obj. And lead to in function __rounddown_pow_of_two, "0 - 1" causes the shift-out-of-bounds. By design drm_exec_prepare_obj() should be called only when there are fences to be reserved. If num_fences is 0, calling drm_exec_lock_obj() is sufficient as was done in commit 9377de4c ("drm/xe/vm: Avoid reserving zero fences") Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/all/24d4a9a9-c622-4f56-8672-21f4c6785476@amd.com Link: https://patchwork.freedesktop.org/patch/msgid/20240507130411.630361-1-shuicheng.lin@intel.comSigned-off-by:
-
- 08 May, 2024 5 commits
-
-
Niranjana Vishwanathapura authored
Indirect Ring State is the recommended mode for Xe2 platforms, enable it by default. v2: Set has_indirect_ring_state to '1' instead of 'true' Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Dump INDIRECT_RING_STATE and RING_START_UDW registers. v2: Add bspec reference Bspec: 67137, 67138 Signed-off-by:
-
Niranjana Vishwanathapura authored
When Indirect Ring State is enabled, the Ring Buffer state and Batch Buffer state are context save/restored to/from Indirect Ring State instead of the LRC. The Indirect Ring State is a 4K page mapped in global GTT at a 4K aligned address. This address is programmed in the INDIRECT_RING_STATE register of the corresponding context's LRC. v2: Fix kernel-doc, add bspec reference v3: Fix typo in commit text Bspec: 67296, 67139 Signed-off-by:
-
Niranjana Vishwanathapura authored
Properly define register fields and remove redundant lower_32_bits(). Signed-off-by:
-
Bommu Krishnaiah authored
This workaround applies to Graphics 20.01 as RCS engine workaround Signed-off-by:
Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by:
-
- 07 May, 2024 7 commits
-
-
Lucas De Marchi authored
Zero-length arrays are deprecated and flexible arrays should be used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arraysReported-by:
kernel test robot <lkp@intel.com> Reported-by:
Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202405051824.AmjAI5Pg-lkp@intel.com/ Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Some explicit includes are needed only from the xe_device.c. And there is no need for redundant forward declarations. Signed-off-by:
-
Michal Wajdeczko authored
While xe_force_wake.h is now included from the xe_device.h, we want to drop that include as we don't need it there. Explicitly include xe_force_wake.h where needed. Signed-off-by:
-
Michal Wajdeczko authored
While xe_assert.h is now included and used by the xe_force_wake.h, we want to stop include xe_force_wake.h from xe_device.h as it's not needed there. Explicitly include xe_assert.h where needed. Signed-off-by:
-
Tejas Upadhyay authored
When user closes exec queue soon after job submission, we are generating error coredump. Instead check if exec queue is killed during job timeout then skip error coredump capture. V2: - Just skip error capture - MattB Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
-
Francois Dugast authored
Fix some typos and add / remove / change a few words to improve readability and prevent some ambiguities. Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
We don't need to include <linux/types.h>. We don't use struct xe_exec_queue here. We should sort forward declarations. Signed-off-by:
-
- 06 May, 2024 6 commits
-
-
Matthew Brost authored
System work queues are shared, use a dedicated work queue for G2H processing to avoid G2H processing getting block behind system tasks. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Janga Rahul Kumar authored
This is useful to check mocs configuration. Tests/Tools can use this debugfs entry to get mocs info. v2: Address review comments. Change debugfs output style similar to pat debugfs. (Lucas De Marchi) v3: rebase. v4: Address review comments. Use function pointer inside ops struct. Update Test-with links. Remove usage of flags wherever not required. (Lucas De Marchi) v5: Address review comments. Move register defines. Modify mocs info struct to avoid holes. (Luca De Marchi) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Janga Rahul Kumar <janga.rahul.kumar@intel.com> Reviewed-by:
-
Janga Rahul Kumar authored
Relocate regs_are_mcr funciton to a higher position in the file for improved visibility. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Nirmoy Das authored
The default behavior of device atomics depends on the VM type and buffer allocation types. Device atomics are expected to function with all types of allocations for traditional applications/APIs. Additionally, in compute/SVM API scenarios with fault mode or LR mode VMs, device atomics must work with single-region allocations. In all other cases device atomics should be disabled by default also on platforms where we know device atomics doesn't on work on particular allocations types. v3: fault mode requires LR mode so only check for LR mode to determine compute API(Jose). Handle SMEM+LMEM BO's migration to LMEM where device atomics is expected to work. (Brian). v2: Fix platform checks to correct atomics behaviour on PVC. Acked-by:Michal Mrozek <michal.mrozek@intel.com> Reviewed-by:
Oak Zeng <oak.zeng@intel.com> Acked-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240430162529.21588-6-nirmoy.das@intel.comSigned-off-by:
-
Nirmoy Das authored
A new helper function xe_bo_has_single_placement() to check if a BO has single placement. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
-
Nirmoy Das authored
Add has_device_atomics_on_smem to specify that a device supports device atomics on system memory. Currently XE2 supports this so set this for XE2. v2: Set has_device_atomics_on_smem for all platform but PVC. Reviewed-by:
-
