- 20 Mar, 2024 8 commits
-
-
Luca Coelho authored
Some of the backported intel_uncore_read*() functions used the wrong types. Change the function declarations accordingly. Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240314065221.1181158-1-luciano.coelho@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Maarten Lankhorst authored
Considering the caller of the GGTT functions should keep the backing storage alive before the function completes, it's not necessary to invalidate with the GGTT lock held. This just adds latency for every user of the GGTT. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matthew Brost authored
Add XE_BO_GGTT_INVALIDATE flag which indicates the GGTT should be invalidated when a BO is added / removed from the GGTT. This is typically set when a BO is used by the GuC as the GuC has GGTT TLBs. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Matthew Brost authored
Only buffers mapped in the GGTT used by the GuC require an invalidation. Display buffers do not require an invalidation. Delete the invalidatio from display code and make invalidation a static function in xe_ggtt.c. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Nirmoy Das authored
Add an explicit check to ensure that the mgr is not NULL. Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Use xe_exec_queue_user_extension_fn type for exec_queue_user_extension_funcs.` Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Ensure exec queue freeing happens at one place, that is in __xe_exec_queue_free(). It releases q->vm reference also. Set q->vm before handling extensions as they can potentially reference it. Signed-off-by:
-
Niranjana Vishwanathapura authored
Abstract out the core part of sched_done and deregister_done handlers to separate functions to decouple them from any protocol error handling part and make them more readable. Signed-off-by:
-
- 19 Mar, 2024 15 commits
-
-
Daniele Ceraolo Spurio authored
Supporting older GuC versions comes with baggage, both on the coding side (due to interfaces only being available from a certain version onwards) and on the testing side (due to having to make sure the driver works as expected with older GuCs). Since all of our Xe platform are still under force probe, we haven't committed to support any specific GuC version and we therefore don't need to support the older once, which means that we can force a bottom limit to what GuC we accept. This allows us to remove any conditional statements based on older GuC versions and also to approach newer additions knowing that we'll never attempt to load something older than our minimum requirement. As an initial value, the minimum expected version is set to 70.19, which is the version currently in the firmware table, but the expectation is that this will be bumbed every time we update the table, until we remove the force probe. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240304162616.824884-1-daniele.ceraolospurio@intel.com
-
Rodrigo Vivi authored
In case of the suspend/resume flow getting locked up we can get reports with some useful hints on where it might get locked and if that has failed. Reviewed-by:
-
Rodrigo Vivi authored
Let's be quieter on production configuration and let's also print the entry point of the gt suspend when debug messages are enabled. Reviewed-by:
-
Himal Prasad Ghimiray authored
vm->flags are already assigned with passed flags. Remove the redundant assignment. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240307065213.1968688-1-himal.prasad.ghimiray@intel.comSigned-off-by:
-
Juha-Pekka Heikkila authored
Mark dpt and related vma as uncached to avoid pipe faults on some devices. Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
-
Matthew Auld authored
Otherwise in the case where we use normal system memory, the CPU access will always be cached, like when filling the DPT PTEs, which is likely not what we want since HW access could be incoherent on platforms like LNL. Marking as XE_BO_PAGETABLE will force wc/uc underneath on such platforms. Signed-off-by:
-
Nirmoy Das authored
Remove usage of unsafe strcpy with a helper function to convert engine class to string. Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Nirmoy Das authored
The vma pointer can't be NULL here. Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Matthew Auld authored
Here XE_MAX_TILES_PER_DEVICE is the gt array size, therefore the gt index should always be less than. v2 (Lucas): - Add fixes tag. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
Matthew Auld authored
Here XE_MAX_GT_PER_TILE is the total, therefore the gt index should always be less than. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
Matthew Auld authored
The engine_class is the index into the user_to_xe_engine_class, therefore it needs to be less than. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
-
Nirmoy Das authored
Explicitly cast tbo->page_alignment to u64 before bit-shifting to prevent overflow when assigning to min_page_size. Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Matthew Auld authored
The region can be used an index into the region_to_mem_type, so we should be asserting that it is less than the ARRAY_SIZE here. Signed-off-by:
-
Matthew Auld authored
If we fished it out the list then it can't be null; the list entry is embedded in the bo. Signed-off-by:
-
Matthew Auld authored
We use plain spinlock to protect readers and writers, so there is no actual RCU here. Rather use the more appropriate non-rcu list based API. Signed-off-by:
-
- 15 Mar, 2024 9 commits
-
-
Michal Wajdeczko authored
The Multi-Level LMTT variant is not specific only to the PVC. Change logic to select it for all new platforms beyond 12.60. Bspec: 52404, 67468 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com>
-
Michal Wajdeczko authored
The LMTT Page Directory, as well as the directory entries, must be aligned on a 64KB boundary in VRAM. Use explicit alignment flag to match hardware requirement. Bspec: 52404, 67468 Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
While today we are getting VRAM allocations aligned to 64K as the XE_VRAM_FLAGS_NEED64K flag could be set, we shouldn't only rely on that flag and we should also allow caller to specify required 64K alignment explicitly. Define new XE_BO_NEEDS_64K flag for that. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
Shortly we will updating xe_mmio_read|write() functions with SR-IOV specific features making those functions less suitable for inline. Convert now those functions into regular ones, lowering driver footprint, according to scripts/bloat-o-meter, by 6% add/remove: 18/18 grow/shrink: 31/603 up/down: 2719/-79663 (-76944) Function old new delta Total: Before=1276633, After=1199689, chg -6.03% add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) Data old new delta Total: Before=48990, After=48990, chg +0.00% add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) RO Data old new delta Total: Before=115680, After=115680, chg +0.00% Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Interrupt registers 1900xx are VF accessible but only until version 12.50 as on newer platforms VFs are using memory-based interrupts. To avoid complexity, we mark those registers with XE_REG_OPTION_VF unconditionally, as IRQ handling on newer VFs is different anyway. Signed-off-by:
-
Michal Wajdeczko authored
Only selected registers are available for Virtual Functions. Reviewed-by:
-
Michal Wajdeczko authored
Only selected registers are available for Virtual Functions. Reviewed-by:
-
Michal Wajdeczko authored
We will tag registers that SR-IOV Virtual Functions can access. This will help us catch any invalid usage and/or provide custom replacement if available. Reviewed-by:
-
Michal Wajdeczko authored
We want to keep the struct xe_reg as small as possible. Make sure we don't accidentally change its size. Reviewed-by:
-
- 14 Mar, 2024 6 commits
-
-
Zhanjun Dong authored
Add helper macro to loop each DSS. This is a precursor patch to allow for easier iteration through MCR registers and other per-DSS uses. Signed-off-by:
Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by:
-
Matt Roper authored
Switch the MOCS-related debug messages to use a GT-specific logging function and add ID/type output to the beginning of the MOCS kunit test to assist with debug when problems arise. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
Although MOCS registers became multicast in graphics version 12.50 on the primary GT, this transition did not happen until version 20 on the media GT. Considering each GT independently is mostly important for MTL/ARL where the Xe_LPM+ IP has non-MCR MOCS registers, even though Xe_LPG IP has MCR registers. Bspec: 67789, 71186 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Starting on Xe2, the GSCCS engine reset is a 2-step process. When the driver or the GuC hits the GDRST register, the CS is immediately reset and a success is reported, but the GSC shim continues its reset in the background. While the shim reset is ongoing, the CS is able to accept new context submission, but any commands that require the shim will be stalled until the reset is completed. This means that we can keep submitting to the GSCCS as long as we make sure that the preemption timeout is big enough to cover any delay introduced by the reset; since the GSC preempt timeout is not tunable at runtime, we only need to check that the value set in kconfig is big enough (and increase it if it isn't). When the shim reset completes, a specific CS interrupt is triggered, in response to which we need to check the GSCI_TIMER_STATUS register to see if the reset was successful or not. Note that the GSCI_TIMER_STATUS register is not power save/restored, so it gets reset on MC6 entry. However, a reset failure stops MC6, so in that scenario we're always guaranteed to find the correct value. Since we can't check the register within interrupt context, the existing GSC worker has been updated to handle it. The expected action to take on ER failure is to trigger a driver FLR, but we still don't support that, so for now we just print an error. A comment has been added to the code to keep track of the FLR requirement. v2: Add a check for the initial timeout value (Alan) Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240304145634.820684-1-daniele.ceraolospurio@intel.com
-
Matthew Auld authored
drm_sched_init() expects jiffies for the timeout, but here we are passing the timeout in ms. Convert to jiffies instead. Fixes: eef55700 ("drm/xe: Add sysfs for default engine scheduler properties") Signed-off-by:
-
Nirmoy Das authored
Property struct is not being used so remove it and related dead code. Fixes: ddfa2d6a ("drm/xe/uapi: Kill VM_MADVISE IOCTL") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: intel-xe@lists.freedesktop.org Signed-off-by:
-
- 13 Mar, 2024 2 commits
-
-
José Roberto de Souza authored
Doing a XE_EXEC with num_batch_buffer == 0 makes signals passed as argument to be signaled when the last real XE_EXEC is completed. But to do that it was first pinning all VMAs in drm_gpuvm_exec_lock(), this patch remove this pinning as it is not required. This change also help Mesa implementing memory over-commiting recovery as it needs to unbind not needed VMAs when the whole VM can't fit in GPU memory but it can only do the unbiding when the last XE_EXEC is completed. So with this change Mesa can get the signal it want without getting out-of-memory errors. Fixes: eb9702ad ("drm/xe: Allow num_batch_buffer / num_binds == 0 in IOCTLs") Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Co-developed-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Matthew Brost authored
The implementation of xe_device_assert_mem_access has a non-zero cost. Use xe_assert rather than XE_WARN_ON so it will compile out in non-debug kernel builds (Kconfig CONFIG_DRM_XE_DEBUG=n). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
