- 21 Dec, 2023 12 commits
-
-
Matthew Brost authored
Add uAPI and implementation for NULL bindings. A NULL binding is defined as writes dropped and read zero. A single bit in the uAPI has been added which results in a single bit in the PTEs being set. NULL bindings are intendedd to be used to implement VK sparse bindings, in particular residencyNonResidentStrict property. v2: Fix BUG_ON shown in VK testing, fix check patch warning, fix xe_pt_scan_64K, update __gen8_pte_encode to understand NULL bindings, remove else if vma_addr Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Suggested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Janga Rahul Kumar authored
ENOTSUPP is not a standard Unix error should use EOPNOTSUPP instead. v2: Update commit description (Aravind) Reviewed-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Signed-off-by:
Janga Rahul Kumar <janga.rahul.kumar@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
The GuC can't access addresses above GUC_GGTT_TOP, so any GuC-accessible objects can't be mapped above that offset. Instead of checking each object to see if GuC may access it or not before mapping it, we just limit the GGTT size to GUC_GGTT_TOP. This wastes a bit of address space (about ~18 MBs, which is in addition to what already removed at the bottom of the GGTT), but it is a good tradeoff to keep the code simple. The in-code comment has also been updated to explain the limitation. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20230615002521.2587250-1-daniele.ceraolospurio@intel.com/Signed-off-by:
-
Matt Roper authored
This adds a handful of workarounds that apply to production steppings of MTL: - Wa_14018575942 - Wa_22016670082 - Wa_14017856879 - Wa_18019271663 Wa_22016670082 is currently only applied to the primary GT at the moment, but may need to be extended to the media GT in the future if a pending update to the workaround database gets finalized. OOB workarounds will need to be implemented separately in future patches for Wa_14016712196, Wa_16018063123, and Wa_18013179988. Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://lore.kernel.org/r/20230608181217.2385932-1-matthew.d.roper@intel.comSigned-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Michał Winiarski authored
It's not possible for the condition checking if we're running on platform without geometry pipeline to ever be true, since gt->fuse_topo.g_dss_mask is an array. It also breaks the build: ../drivers/gpu/drm/xe/xe_rtp.c:183:50: error: address of array 'gt->fuse_topo.g_dss_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Michał Winiarski authored
Using uninitialized variables leads to undefined behavior. Moreover, it causes the compiler to complain with: ../drivers/gpu/drm/xe/xe_vm.c:3265:40: error: variable 'vma' is uninitialized when used here [-Werror,-Wuninitialized] ../drivers/gpu/drm/xe/xe_rtp.c:118:36: error: variable 'i' is uninitialized when used here [-Werror,-Wuninitialized] ../drivers/gpu/drm/xe/xe_mocs.c:449:3: error: variable 'flags' is uninitialized when used here [-Werror,-Wuninitialized] Signed-off-by:
-
Riana Tauro authored
gt_count is only being incremented when initializing the primary GT; since the media GT sets the ID directly, gt_count is not incremented again, resulting in an incorrect count on MTL. Use autoincrement while assigning the media GTs ID to ensure gt_count is correct on MTL and other future platforms with standalone media. Signed-off-by:
Riana Tauro <riana.tauro@intel.com> Link: https://lore.kernel.org/r/20230613094232.3703549-1-riana.tauro@intel.com [mattrope: Tweaked commit message to focus on gt_count importance] Signed-off-by:
-
Badal Nilawar authored
RPSTAT1 is an sgunit register and thus doesn't need forcewake. MTL_MIRROR_TARGET_WP1 is within an "always on" power domain and thus doesn't require any forcewake to ensure the register is powered up and usable. When GT is RC6 the actual frequency reported will be 0. v2: - Add bspec index (Anshuman) - %s/GEN12_RPSTAT1/GT_PERF_STATUS as per bspec v3: Update Fixes tag Bspec: 51837, 67651 Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Reviewed-by:
-
Lucas De Marchi authored
One of the messages was printed without 0x prefix, so it was not clear if it was decimal or hex: make sure to add the prefix by using %#x. While at it, normalize the other messages in the same function to follow the same pattern. Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20230611222447.2837573-3-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Fix the log message when it fails to enable CT. Reviewed-by:
-
Lucas De Marchi authored
Remove the leftover TODO by renameing the functions to use xe prefix. Since the static __gen8_pte_encode() already has a double score, just remove the prefix. Reviewed-by:
-
Matthew Brost authored
XE_PTE_FLAG_READ_ONLY is specific to struct xe_vma, move it from xe_bo.h to xe_vm_types.h to reflect that. Reviewed-by:
Francois Dugast <francois.dugast@intel.com> Signed-off-by:
-
- 19 Dec, 2023 28 commits
-
-
Matthew Brost authored
This define is for internal PTE flags rather than fields in the hardware PTEs, rename as such. This will help in an upcoming patch to avoid further confusion. Reviewed-by:
-
Matthew Brost authored
A mix of the system unbound wq and Xe ordered wq was used for the rebind, only use the Xe ordered wq. This will ensure only 1 rebind is occuring at a time providing a somewhat clunky work around for short comings in TTM wrt to memory contention. Once the TTM memory contention is resolved we should be able to use a dedicated non-ordered workqueue. Also add helper to queue rebind worker to avoid using wrong workqueue going forward. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Matthew Brost authored
A corner exists where a userptr may have no mapping when analyze VM is called, handle this case. Reviewed-by:
-
Thomas Hellström authored
We need to flush render caches before fence signalling, where we might release the memory for reuse. We can't rely on userspace doing this, so flush render caches after the batch, but before user fence- and dma_fence signalling. Copy the cache flush from i915, but omit PIPE_CONTROL_FLUSH_L3, since it should be implied by the other flushes. Also omit PIPE_CONTROL_TLB_INVALIDATE since there should be no apparent need to invalidate TLB after batch completion. v2: - Update Makefile for OOB WA. Signed-off-by:
-
Thomas Hellström authored
For scratch table mode we need to cover the case where a scratch PTE might have been pre-fetched and cached and used instead of that of the newly bound vma. For compute vms, invalidate TLB globally using GuC before signalling bind complete. For !long-running vms, invalidate TLB at batch start. Also document how TLB invalidation works. v2: - Fix a pointer to the comment about TLB invalidation (Jose Souza). - Add a bool to the vm whether we want to invalidate TLB at batch start. - Invalidate TLB also on BCS- and video engines at batch start where needed. - Use BIT() macro instead of explicit shift. Signed-off-by:
-
Gustavo Sousa authored
If RING_MAX_NONPRIV_SLOTS denotes the maximum number of whitelisting slots, then it makes sense to refuse going above it. v2: - Use xe_gt_err() instead of drm_err() for more detailed info in the error message. (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: -
Gustavo Sousa authored
All other parameters can be extracted from a single struct xe_hw_engine reference. This removes redundancy and simplifies the code. Reviewed-by:
-
Matthew Brost authored
The HXG fields are DW1 not DW0, fix this. Reviewed-by:
-
Francois Dugast authored
Fix spacing, alignment, and repeated words in the documentation. Reported-by:
Oded Gabbay <ogabbay@kernel.org> Signed-off-by:
-
Francois Dugast authored
Move the definition of drm_xe_engine_class_instance to group it with other engine related structs and to follow the ioctls order. Reported-by:
-
Francois Dugast authored
Replace the license text with its SPDX-License-Identifier for quick identification of the license and consistency with the rest of the driver. Reported-by:
-
Matt Roper authored
Wa_14015795083 was already implemented for DG2 and PVC, but the workaround database has been updated to extend it to more platforms. It should now apply to all platforms with graphics versions 12.00 - 12.60, as well as A-step of Xe_LPG (12.70 / 12.71). Reviewed-by:
-
Michael J. Ruhl authored
The resizing of the PCI BAR is a best effort feature. If it is not available, it should not fail the driver probe. Rework the resize to not exit on failure. Fixes: 7f075300 ("drm/xe: Simplify rebar sizing") Acked-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
-
Matt Roper authored
Although PVC is currently the only platform that needs us to program a GuC register with the index of an uncached MOCS entry, it's likely other platforms will need this in the future. Rather than hardcoding PVC's index into the register header, we should just pull the appropriate index from gt->mocs.uc_index to future-proof the code. Reviewed-by:
-
Matt Roper authored
xe_mocs_init_early doesn't touch the hardware, it just sets up internal software state. There's no need to perform this step in the "forcewake held" region. Moving the init earlier will also make the uc_index values available earlier which will be important for an upcoming GuC init patch. Reviewed-by:
-
Matt Roper authored
Reformat the GuC register header according to the same rules used by other register headers: - Register definitions are ordered by offset - Value of #define's start on column 49 - Lowercase used for hex values No functional change. This header has some things that aren't directly related to register definitions (e.g., number of doorbells, doorbell info structure, GuC interrupt vector layout, etc. These items have been moved to the bottom of the header. Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
Gustavo Sousa authored
DRM_ERROR() has been deprecated in favor of pr_err(). However, we should prefer to use xe_gt_err() or drm_err() whenever possible so we get gt- or device-specific output with the error message. v2: - Prefer drm_err() over pr_err(). (Matt, Jani) v3: - Prefer xe_gt_err() over drm_err() when possible. (Matt) v4: - Use the already available dev variable instead of xe->drm as parameter to drm_err(). (Matt) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by: -
Matt Roper authored
v2: - Fix doubled word. (Lucas) Reviewed-by:
-
Matt Roper authored
Now that tiles and GTs are handled separately and other prerequisite changes are in place, we're ready to re-enable the media GT. Reviewed-by:
-
Matt Roper authored
Now that a higher GT count can result from either multiple tiles (with one GT each) or an extra media GT within the root tile, we need to update the query code slightly to stop looking at tile_count. FIXME: As noted previously, we need to decide on a formal direction for exposing tiles and/or GTs to userspace. v2: - Drop num_gt() function in favor of stored xe->info.gt_count. (Brian) v3: - Keep XE_QUERY_GT_TYPE_REMOTE around for now. Userspace probably doesn't actually need this, and we may remove it in the future, but for now let's avoid changing uapi. (Brian) Cc: Brian Welty <brian.welty@intel.com> Reviewed-by:
Brian Welty <brian.welty@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-30-matthew.d.roper@intel.comSigned-off-by:
-
Matt Roper authored
Allow xe_device_get_gt() and for_each_gt() to operate as expected on platforms with standalone media. FIXME: We need to figure out a consistent ID scheme for GTs. This patch keeps the pre-existing behavior of 0/1 being the GT IDs for both PVC (multi-tile) and MTL (multi-GT), but depending on the direction we decide to go with uapi, we may change this in the future (e.g., to return 0/1 on PVC and 0/2 on MTL). Or if we decide we only need to expose tiles to userspace and not GTs, we may not even need ID numbers for the GTs anymore. v2: - Restructure a bit to make the assertions more clear. - Clarify in commit message that the goal here is to preserve existing behavior; UAPI-visible changes may be introduced in the future once we settle on what we really want. v3: - Store total GT count in xe_device for ease of lookup. (Brian) - s/(id__++)/(id__)++/ (Gustavo) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Cc: Brian Welty <brian.welty@intel.com> Acked-by:
-
Matt Roper authored
Updates to the GGTT can happen when there are no in-flight jobs keeping the hardware awake. If the GT is powered down when invalidation is requested, we will not be able to communicate with the GuC (or MMIO) and the invalidation request will go missing. Explicitly grab GT forcewake to ensure the GT and GuC are powered up during the TLB invalidation. Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-28-matthew.d.roper@intel.comSigned-off-by:
-
Matt Roper authored
The GGTT is part of the tile and is shared by the primary and media GTs on platforms with a standalone media architecture. However each of these GTs has its own TLBs caching the page table lookups, and each needs to be invalidated separately. Reviewed-by:
-
Matt Roper authored
The majority of xe_gt_irq_postinstall() is really focused on the hardware engine interrupts; other GT-related interrupts such as the GuC are enabled/disabled independently. Renaming the function and making it truly GT-specific will make it more clear what the intended focus is. Disabling/masking of other interrupts (such as GuC interrupts) is unnecessary since that has already happened during the irq_reset stage, and doing so will become harmful once the media GT is re-enabled since calls to xe_gt_irq_postinstall during media GT initialization would incorrectly disable the primary GT's GuC interrupts. Also, since this function is called from gt_fw_domain_init(), it's not necessary to also call it earlier during xe_irq_postinstall; just xe_irq_resume to handle runtime resume should be sufficient. v2: - Drop unnecessary !gt check. (Lucas) - Reword some comments about enable/unmask for clarity. (Lucas) Reviewed-by:
-
Matt Roper authored
The xe_irq_postinstall() never actually gets called after installing the interrupt handler. This oversight seems to get papered over due to the fact that the (misnamed) xe_gt_irq_postinstall does more than it really should and gets called in the middle of the GT initialization. The callstack for postinstall is also a bit muddled with top-level device interrupt enablement happening within platform-specific functions called from the per-tile xe_gt_irq_postinstall() function. Clean this all up by adding the missing call to xe_irq_postinstall() after installing the interrupt handler and pull top-level irq enablement up to xe_irq_postinstall where we'd expect it to be. The xe_gt_irq_postinstall() function is still a bit misnamed here; an upcoming patch will refocus its purpose and rename it. v2: - Squash in patch to actually call xe_irq_postinstall() after installing the interrupt handler. Reviewed-by:
-
Matt Roper authored
Although primary and media GuC share a single interrupt enable bit, they each have distinct bits in the mask register. Although we always enable interrupts for the primary GuC before the media GuC today (and never disable either of them), this might not always be the case in the future, so use a RMW when updating the mask register to ensure the other GuC's mask doesn't get clobbered. Reviewed-by:
-
Matt Roper authored
Our only use of GUnit interrupts is to handle ASLE backlight operations that are reported as GUnit GSE interrupts. Move the enable/disable of these interrupts to a more sensible place, in the same area where we expect display interrupt code to be added by future patches. Reviewed-by:
-
Matt Roper authored
IRQ delivery and handling needs to be handled on a per-tile basis. Note that this is true even for the "GT interrupts" relating to engines and GuCs --- the interrupts relating to both GTs get raised through a single set of registers in the tile's sgunit range. On true multi-tile platforms, interrupts on remote tiles are internally forwarded to the root tile; the first thing the top-level interrupt handler should do is consult the root tile's instance of DG1_MSTR_TILE_INTR to determine which tile(s) had interrupts. This register is also responsible for enabling/disabling top-level reporting of any interrupts to the OS. Although this register technically exists on all tiles, it should only be used on the root tile. The (mis)use of struct xe_gt as a target for MMIO operations in the driver makes the code somewhat confusing since we wind up needing a GT pointer to handle programming that's unrelated to the GT. To mitigate this confusion, all of the xe_gt structures used solely as an MMIO target in interrupt code are renamed to 'mmio' so that it's clear that the structure being passed does not necessarily relate to any specific GT (primary or media) that we might be dealing with interrupts for. Reworking the driver's MMIO handling to not be dependent on xe_gt is planned as a future patch series. Note that GT initialization code currently calls xe_gt_irq_postinstall() in an attempt to enable the HWE interrupts for the GT being initialized. Unfortunately xe_gt_irq_postinstall() doesn't really match its name and does a bunch of other stuff unrelated to the GT interrupts (such as enabling the top-level device interrupts). That will be addressed in future patches. v2: - Clarify commit message with explanation of why DG1_MSTR_TILE_INTR is only used on the root tile, even though it's an sgunit register that is technically present in each tile's MMIO space. (Aravind) - Also clarify that the xe_gt used as a target for MMIO operations may or may not relate to the GT we're dealing with for interrupts. (Lucas) Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reviewed-by:
-
