- 21 May, 2024 5 commits
-
-
Umesh Nerlige Ramappa authored
Add a helper to accumulate per-client runtime of all its exec queues. This is called every time a sched job is finished. v2: - Use guc_exec_queue_free_job() and execlist_job_free() to accumulate runtime when job is finished since xe_sched_job_completed() is not a notification that job finished. - Stop trying to update runtime from xe_exec_queue_fini() - that is redundant and may happen after xef is closed, leading to a use-after-free - Do not special case the first timestamp read: the default LRC sets CTX_TIMESTAMP to zero, so even the first sample should be a valid one. - Handle the parallel submission case by multiplying the runtime by width. v3: Update comments Signed-off-by:Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517204310.88854-6-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Lucas De Marchi authored
Just like CTX_TIMESTAMP is used to calculate runtime, add a helper to get the timestamp for the engine so it can be used to calculate the "engine time" with the same unit as the runtime is recorded. Reviewed-by:
-
Umesh Nerlige Ramappa authored
Add a helper to capture CTX_TIMESTAMP from the context image so it can be used to calculate the runtime. v2: Add kernel-doc to clarify expectation from caller Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517204310.88854-4-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
XE_ENGINE_CLASS_OTHER was missing from the str conversion. Add it and remove the default handling so it's protected by -Wswitch. Currently the only user is xe_hw_engine_class_sysfs_init(), which already skips XE_ENGINE_CLASS_OTHER, so there's no change in behavior. Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517204310.88854-3-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
Move it out of the sysfs compilation unit so it can be re-used in other places. Reviewed-by:
Oak Zeng <oak.zeng@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517204310.88854-2-lucas.demarchi@intel.comSigned-off-by:
-
- 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:
-
