- 21 May, 2024 1 commit
-
-
Lucas De Marchi authored
Move it out of the sysfs compilation unit so it can be re-used in other places. Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Oak Zeng <oak.zeng@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517204310.88854-2-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
- 17 May, 2024 1 commit
-
-
José Roberto de Souza authored
Other u64 registers are printed in a single line so RING_START needs to follow that too. As there is no upstream decoder tool parsing RING_START this will not break any decoder application. Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240510150108.80679-1-jose.souza@intel.com
-
- 16 May, 2024 14 commits
-
-
Michal Wajdeczko authored
For debug purposes we might want to view actual VF configuration (including GGTT range, LMEM size, number of GuC contexts IDs or doorbells) and the negotiated ABI versions (with GuC and PF). 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/20240516110546.2216-7-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
The VF drivers may immediately communicate with the GuC to obtain the hardware config since the firmware shall already be running. With the GuC communication established, VFs can also obtain the values of the runtime registers (fuses) from the PF driver. Reviewed-by:
-
Michal Wajdeczko authored
The VF driver doesn't know which GuC firmware was loaded by the PF driver and must perform GuC ABI version handshake prior to sending any other H2G actions to the GuC to submit workloads. The VF driver also doesn't have access to the fuse registers and must rely on the runtime info, which includes values of the fuse registers, that the PF driver is exposing to the VFs. Add functions to cover that functionality. We will use these functions in upcoming patches. Signed-off-by:
-
Michal Wajdeczko authored
In upcoming patches we will add support to the VF driver to read its configuration from the GuC using special H2G actions. Add necessary definitions to our GuC firmware ABI header. Reviewed-by:
-
Michal Wajdeczko authored
The version negotiation between the VF driver and the GuC firmware must start with explicit soft reset of the GuC state initiated by the VF driver. Add VF2GUC action definitions to the ABI header. Reviewed-by:
-
Michal Wajdeczko authored
In upcoming patches we will add a version negotiation between the VF driver and the GuC firmware. Add necessary definitions to our GuC firmware ABI header. Reviewed-by:
-
Michal Wajdeczko authored
For debug purposes we might want to view statistics maintained by the PF driver about VFs activity. Reviewed-by:
-
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. Start handling such messages. Reviewed-by:
-
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:
-
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:
-
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:
-
