- 16 May, 2024 6 commits
-
-
Michal Wajdeczko authored
When thresholds used to monitor VFs activities are configured, then GuC may send GUC2PF_ADVERSE_EVENT messages informing the PF driver about exceeded thresholds. Add necessary definitions to our GuC firmware ABI header. Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240514190015.2172-7-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Initial values of all thresholds used by the GuC to monitor VF's activity is zero (disabled) and we need to explicitly configure them per each VF. Expose additional attributes over debugfs. Definitions of all attributes are generated so we will not need to make any changes if new thresholds would be added to the set. Reviewed-by:
-
Michal Wajdeczko authored
The GuC firmware monitors VF's activity and notifies the PF driver once any configured threshold related to such activity is exceeded. Add functions to allow configuration of these thresholds per VF. Reviewed-by:
-
Michal Wajdeczko authored
Use MAKE_XE_GUC_KLV_THRESHOLDS_SET to generate missing conversion of threshold KLV keys to string. Reviewed-by:
-
Michal Wajdeczko authored
The GuC firmware monitors VF's activity and notifies the PF driver once any configured threshold related to such activity is exceeded. The available thresholds are defined in the GuC ABI as part of the GuC VF Configuration KLVs. Threshold configurations performed by the PF driver and notifications sent by the GuC rely on the KLV keys, which are not zero-based and might not guarantee continuity. To simplify the driver code and eliminate the need to repeat very similar code for each threshold, introduce the threshold set macro that allows to generate required code based on unique threshold tag. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240514190015.2172-3-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
In upcoming patches we will want to generate some of the KLV keys from other macros. Add MAKE_GUC_KLV_{KEY|LEN} macros for that and make sure they will correctly expand provided TAG parameter. Also fix PREP_GUC_KLV_TAG to also work correctly within other macros. Reviewed-by:
-
- 15 May, 2024 3 commits
-
-
Michal Wajdeczko authored
The PCI subsystem already exposes the "sriov_numvfs" attribute that users can use to enable or disable SR-IOV VFs. Add custom implementation of the .sriov_configure callback defined by the pci_driver to perform additional steps, including fair VFs provisioning with the resources, as required by our platforms. Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506184121.2615-1-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Even if we have not enabled SR-IOV support using the platform specific has_sriov flag, the hardware may still report SR-IOV capability and the PCI layer may wrongly advertise driver support to enable VFs. Explicitly reset the number of supported VFs to zero to avoid confusion. Applications may read the /sys/bus/pci/devices/.../sriov_totalvfs prior to enabling VFs using the sriov_numvfs to check if such an operation is possible. Signed-off-by:
-
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 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:
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 5 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:
-
