- 08 Apr, 2024 6 commits
-
-
Michal Wajdeczko authored
On current platforms supported firmwares, like GuC and HuC, must be loaded by the PF driver. Mark those firmwares as 'preloaded' so we will skip fetching and loading them on the VF drivers but still correctly report them as 'running'. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404173814.715-1-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
Legacy SOFT_SCRATCH registers are not accessible from the VF. Any G2H notification posted there will be handled by the PF driver. Signed-off-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405133936.891-4-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
VFs drivers don't have access to MOCS registers. It is a PF driver responsibility to program MOCS according to the HW team guidelines. Signed-off-by:
-
Michal Wajdeczko authored
VFs can't access Global HWSP, don't emit questionable MI_FLUSH_DW while processing a migration job. Bspec: 52398 Signed-off-by:
-
Michal Wajdeczko authored
The GuC submission cleanup code may depend on the GuC ID manager, thus we can't initialize it after registering a submission cleanup action, as reverse cleanup sequence will destroy GuC ID manager prior to a call to guc_submit_fini(). Move GuC ID manager initialization up, right after managed mutex initialization, to have it available during guc_submit_fini(). Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240406143946.979-2-michal.wajdeczko@intel.com
-
Michal Wajdeczko authored
This is safer approach and will help resolve a cleanup ordering conflict related to the GuC ID manager. Signed-off-by:
-
- 05 Apr, 2024 5 commits
-
-
Michal Wajdeczko authored
It is already defined in xe_vm.h and shouldn't be duplicated. Signed-off-by:
-
Michal Wajdeczko authored
We already have dedicated header for GGTT/PPGTT definitions. It's also cleaner to separate them from implementation macros. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Andrzej Hajda authored
Xe_LP has six sublices per slice. v2: fixed commit message and subject (Matt) Bspec: 66696 Fixes: bde5d767 ("drm/xe: Add helper macro to loop each DSS") Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405-mcr_adlp-v2-1-2fd1e4325ef2@intel.comSigned-off-by:
-
Michal Wajdeczko authored
There is no need to duplicate code to print GuC parameters. Reviewed-by:
-
Michal Wajdeczko authored
A platform can have more than one GuC, so we should use GT-oriented logs to correctly identify the source of the message. Reviewed-by:
-
- 04 Apr, 2024 3 commits
-
-
Bommu Krishnaiah authored
sprintf() is deprecated for sysfs, use preferred sysfs_emit() instead. v2: used sysfs_emit instand of sprintf Signed-off-by:
Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Bommu Krishnaiah authored
since the sprintf() function lacks built-in protection against buffer overflows using the snprintf() function. v2: Removed hard coded values and used sizeof() Signed-off-by:
-
Rodrigo Vivi authored
While we don't have the full flow protection when devcoredump is accessed after device unbind. Let's at least for now protect against null dereference: [ 422.766508] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 423.119584] RIP: 0010:xe_vm_snapshot_free+0x30/0x180 [xe] While at it, I also fixed a non-standard code-declaration block on the similar function of xe_guc_submit. v2: - Use IS_ERR_OR_NULL (Nirmoy) - Expand to other functions Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240403195044.239766-1-rodrigo.vivi@intel.comSigned-off-by:
-
- 03 Apr, 2024 2 commits
-
-
Himal Prasad Ghimiray authored
Addressing potential overflow in result of multiplication of two lower precision (u32) operands before widening it to higher precision (u64). -v2 Fix commit message and description. (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matthew Brost authored
Preempt fences can sleep waiting for an exec queue suspend operation to complete. If the system_unbound_wq is used for waiting and the number of waiters exceeds max_active this will result in other users of the system_unbound_wq getting starved. Use a device private work queue for preempt fences to avoid starvation of the system_unbound_wq. Even though suspend operations can complete out-of-order, all suspend operations within a VM need to complete before the preempt rebind worker can start. With that, use a device private ordered wq for preempt fence waiting. v2: - Add comment about cleanup on failure (Matt R) - Update commit message (Lucas) Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
- 02 Apr, 2024 3 commits
-
-
Himal Prasad Ghimiray authored
This workaround applies to RCS engine's context, hence added as LRC workaround. v2 - Fix commit description as lrc workaround instead of engine.(Lucas) v3 - COMMON_SLICE_CHICKEN1 is a masked register, add XE_REG_OPTION_MASKED flag. (Matt) BSPEC: 55899 Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Lucas De Marchi authored
The flags stored in the BO grew over time without following much a naming pattern. First of all, get rid of the _BIT suffix that was banned from everywhere else due to the guideline in drivers/gpu/drm/i915/i915_reg.h that xe kind of follows: Define bits using ``REG_BIT(N)``. Do **not** add ``_BIT`` suffix to the name. Here the flags aren't for a register, but it's good practice to keep it consistent. Second divergence on names is the use or not of "CREATE". This is because most of the flags are passed to xe_bo_create*() family of functions, changing its behavior. However, since the flags are also stored in the bo itself and checked elsewhere in the code, it seems better to just omit the CREATE part. With those 2 guidelines, all the flags are given the form XE_BO_FLAG_<FLAG_NAME> with the following commands: git grep -le "XE_BO_" -- drivers/gpu/drm/xe | xargs sed -i \ -e "s/XE_BO_\([_A-Z0-9]*\)_BIT/XE_BO_\1/g" \ -e 's/XE_BO_CREATE_/XE_BO_FLAG_/g' git grep -le "XE_BO_" -- drivers/gpu/drm/xe | xargs sed -i -r \ -e 's/XE_BO_(DEFER_BACKING|SCANOUT|FIXED_PLACEMENT|PAGETABLE|NEEDS_CPU_ACCESS|NEEDS_UC|INTERNAL_TEST|INTERNAL_64K|GGTT_INVALIDATE)/XE_BO_FLAG_\1/g' And then the defines in drivers/gpu/drm/xe/xe_bo.h are adjusted to follow the coding style. Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322142702.186529-3-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
It's quite redundant to pass XE_BO_CREATE_USER_BIT to xe_bo_create_user() since the only difference of that function is to force that flag. Stop passing the flag in the few cases that were explicitly doing so. Reviewed-by:
-
- 29 Mar, 2024 5 commits
-
-
Himal Prasad Ghimiray authored
Assign 'xe_devcoredump_snapshot *' and 'xe_device *' only if 'coredump' is not NULL. v2 - Fix commit messages. v3 - Define variables before code.(Ashutosh/Jose) v4 - Drop return check for coredump_to_xe. (Jose/Rodrigo) v5 - Modify misleading commit message. (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Karthik Poosa authored
Add infra to support card power and energy attributes through channel 0. Package attributes will be now exposed through channel 1 rather than channel 0 as shown below. Channel 0 i.e power1/energy1_xxx used for card and channel 1 i.e power2/energy2_xxx used for package power,energy attributes. power1/curr1_crit and in0_input are moved to channel 1, i.e. power2/curr2_crit and in1_input as these are available for package only. This would be needed for future platforms where they might be separate registers for package and card power and energy. Each discrete GPU supported by Xe driver, would have a directory in /sys/class/hwmon/ with multiple channels under it. Each channel would have attributes for power, energy etc. Ex: /sys/class/hwmon/hwmon2/power1_max /power1_label /energy1_input /energy1_label Attributes will have a label to get more description of it. Labelling is as below. power1_label/energy1_label - "card", power2_label/energy2_label - "pkg". v2: Fix checkpatch errors. v3: - Update intel-xe-hwmon documentation. (Riana, Badal) - Rename hwmon card channel enum from CHANNEL_PLATFORM to CHANNEL_CARD. (Riana) v4: - Remove unrelated changes from patch. (Anshuman) - Fix typo in commit msg. v5: - Update commit message and intel-xe-hwmon documentation with "Xe" instead of xe when using it as a name. (Rodrigo) Signed-off-by:Karthik Poosa <karthik.poosa@intel.com> Reviewed-by:
Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240328175435.3870957-1-karthik.poosa@intel.comSigned-off-by:
-
Michal Wajdeczko authored
We are abusing struct drm_info_list.data by storing there pointer to the xe_gt, while it shouldn't be used for any device specific data. Use recently introduced xe_gt_debugfs_simple_show() that hides all details how to obtain the xe_gt pointer. This will also remove the need for making copies of the struct drm_info_list to get GT specific definitions. Reviewed-by:
-
Michal Wajdeczko authored
Many of our debugfs files are GT specific and require a pointer to struct xe_gt to correctly show its content. Our initial approach to use drm_info_list.data field to pass pointer not only requires extra steps (like copying template per each GT) but also abuses the rule that this data field should not be device specific. Introduce helper function that will use xe_gt pointer stored at parent directory level and use .data only to pass actual print function that would expects xe_gt pointer as a parameter. Reviewed-by:
-
Michal Wajdeczko authored
Attributes added under 'gt/' directories may wish to use that in case they can't obtain it from elsewhere. Reviewed-by:
-
- 28 Mar, 2024 11 commits
-
-
Francois Dugast authored
The topology type is an index (not a mask) so define the values like other indexes instead of using powers of 2. This is also to make clear that the next type can use value 3. This commit does not change the existing values so it does not break compatibility. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by:
Francois Dugast <francois.dugast@intel.com> Link: https://lore.kernel.org/intel-xe/20240327232317.GI718896@mdroper-desk1.amr.corp.intel.com/Reviewed-by:
-
Daniele Ceraolo Spurio authored
The WA states that we need to keep the primary GT powered up during GSC load to allow the GSC FW to access its registers. We also need to make sure that one of the registers is locked before starting the load. v2: fix location of register def (Matt) Bspec: 55928 Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
GuC will use VF_STATE_NOTIFY events to notify the PF about changes of the VF state, in particular when a VF FLR was requested. Add very minimal support for such events to avoid reporting errors due to unexpected G2H. We will improve handling of these messages later. While around also add few basic functions to control the VF state (pause, resume, stop) as we will also exercise them soon. Signed-off-by:
-
Michal Wajdeczko authored
In upcoming patches the PF driver will add support to handle the GUC2PF_VF_STATE_NOTIFY events and to send PF2GUC_VF_CONTROL request messages. Add necessary definitions to our GuC firmware ABI header. Signed-off-by:
-
Michal Wajdeczko authored
SR-IOV VF mode detection is based on testing VF capability bit on the register that is accessible from both the PF and enabled VFs. Bspec: 49904, 53227 Signed-off-by:
-
Michal Wajdeczko authored
SR-IOV mode detection requires access to the MMIO register and this can be done now in xe_device_probe_early(). We can also drop explicit has_sriov parameter as this flag is now already available from xe->info. Signed-off-by:
-
Michal Wajdeczko authored
We can setup root tile registers mapping at the same time as we do early mapping of the entire MMIO BAR and keep mandatory VRAM checkout as a separate step. This will allow us to perform SR-IOV VF mode detection between those two steps using regular MMIO regs access functions. Signed-off-by:
-
Thomas Hellström authored
Rebinding might allocate page-table bos, causing evictions. To support blocking locking during these evictions, perform the rebinding in the drm_exec locking loop. Also Reserve fence slots where actually needed rather than trying to predict how many fence slots will be needed over a complete wound-wait transaction. v2: - Remove a leftover call to xe_vm_rebind() (Matt Brost) - Add a helper function xe_vm_validate_rebind() (Matt Brost) v3: - Add comments and squash with previous patch (Matt Brost) Fixes: 24f947d5 ("drm/xe: Use DRM GPUVM helpers for external- and evicted objects") Fixes: 29f424eb ("drm/xe/exec: move fence reservation") Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
-
Thomas Hellström authored
They can actually complete out-of-order, so allocate a unique fence context for each fence. Fixes: 5387e865 ("drm/xe: Add TLB invalidation fence after rebinds issued from execs") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
-
Thomas Hellström authored
Instead of handling the vm's rebind fence separately, which is error prone if they are not strictly ordered, attach rebind fences as kernel fences to the vm's resv. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
-
Thomas Hellström authored
For each rebind we insert a GuC TLB invalidation and add a corresponding unordered TLB invalidation fence. This might add a huge number of TLB invalidation fences to wait for so rather than doing that, defer the TLB invalidation to the next ring ops for each affected exec queue. Since the TLB is invalidated on exec_queue switch, we need to invalidate once for each affected exec_queue. v2: - Simplify if-statements around the tlb_flush_seqno. (Matthew Brost) - Add some comments and asserts. Fixes: 5387e865 ("drm/xe: Add TLB invalidation fence after rebinds issued from execs") Cc: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
-
- 27 Mar, 2024 5 commits
-
-
Michal Wajdeczko authored
We are ready to replace private guc_ids management code with separate GuC ID Manager that can be shared with upcoming SR-IOV PF provisioning code. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Before we switch-over submission code to use new GuC context ID Manager, lets add some kunit tests to make sure that ID manager works as expected. Signed-off-by:
-
Michal Wajdeczko authored
While we are already managing GuC IDs directly in GuC submission code, using bitmap() for MLRC and ida() for SLRC, this code can't be easily extended to meet additional requirements for SR-IOV use cases, like limited number of IDs available on VFs, or ID range reservation for provisioning VFs by the PF. Add a separate component for managing GuC IDs, that will replace existing ID management. Start with bitmap() based implementation that could be optimized later based on perf data. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
This macro represents GuC firmware capability and shall be defined in the firmware ABI header. Move it to xe_guc_fwif.h file. Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Use include guard macro name that follows naming used by the other GuC ABI files. Signed-off-by:
-
