- 21 Dec, 2023 40 commits
-
-
Thomas Hellström authored
xe_bo_lock() was, although it only grabbed a single lock, unnecessarily using ttm_eu_reserve_buffers(). Simplify and document the interface. v2: - Update also the xe_display subsystem. v4: - Reinstate a lost dma_resv_reserve_fences(). - Improve on xe_bo_lock() documentation (Matthew Brost) Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230908091716.36984-2-thomas.hellstrom@linux.intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Change xe_mmio_in_range() to use the same logic to account for the GT's adj_offset as the read and write functions. This is needed when checking ranges for the MCR registers if the GT has an offset to adjust. Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230908225227.1276610-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
The min_page_size is useful information to ensure alignment and it is an API actually in use. However max_page_size doesn't bring any useful information to the userspace hence being not used at all. So, let's remove and only bring it back if that ever gets used. Suggested-by:
Francois Dugast <francois.dugast@intel.com>
-
Rodrigo Vivi authored
Fix typos, lingo and other small things identified during uapi review. v2: Also fix ALIGNMENT typo at xe_query.c v3: Do not touch property to get/set. (Francois) Link: https://lore.kernel.org/all/863bebd0c624d6fc2b38c0a06b63e468b4185128.camel@linux.intel.com/Suggested-by:
-
Lucas De Marchi authored
Fix 2 issues when writing LRC workarounds by copying the same handling done when processing other RTP entries: For masked registers, it was not correctly setting the upper 16bits. Differently than i915, the entry itself doesn't set the upper bits for masked registers: this is done when applying them. Testing on ADL-P: Before: [drm:xe_gt_record_default_lrcs [xe]] LRC WA rcs0 save-restore MMIOs [drm:xe_gt_record_default_lrcs [xe]] REG[0x2580] = 0x00000002 ... [drm:xe_gt_record_default_lrcs [xe]] REG[0x7018] = 0x00002000 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7300] = 0x00000040 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7304] = 0x00000200 After: [drm:xe_gt_record_default_lrcs [xe]] LRC WA rcs0 save-restore MMIOs [drm:xe_gt_record_default_lrcs [xe]] REG[0x2580] = 0x00060002 ... [drm:xe_gt_record_default_lrcs [xe]] REG[0x7018] = 0x20002000 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7300] = 0x00400040 [drm:xe_gt_record_default_lrcs [xe]] REG[0x7304] = 0x02000200 All of these registers are masked registers, so writing to them without the relevant bits in the upper 16b doesn't have any effect. Also, this adds support to regular registers; previously it was assumed that LRC entries would only contain masked registers. However this is not true. 0x6604 is not a masked register, but used in workarounds for e.g. ADL-P. See commit 28cf243a ("drm/i915/gt: Fix context workarounds with non-masked regs"). In the same test with ADL-P as above: Before: [drm:xe_gt_record_default_lrcs [xe]] REG[0x6604] = 0xe0000000 After: [drm:xe_gt_record_default_lrcs [xe]] REG[0x6604] = 0xe0efef6f As can be seen, now it will read what was in the register rather than completely overwrite the other bits. Reviewed-by:
-
Lucas De Marchi authored
Just like the GT and engine workarounds, add debug message with the final value being written to the register for easy debugging. Reviewed-by:
-
Lucas De Marchi authored
Use xe_gt_dbg() instead of drm_dbg() so the GT is added to the log for easy identification. Reviewed-by:
-
Lucas De Marchi authored
For all RTP actions, clr_bits is a superset of the bits being modified. That's also why the check for "changing all bits" can be done with `clr_bits + 1`. So always use clr_bits for setting the upper bits of a masked register. Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://lore.kernel.org/r/20230906012053.1733755-2-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
Use 0 in format string instead of space so it shows as [drm] *ERROR* Missing PAT table for platform with graphics version 20.04! instead of [drm] *ERROR* Missing PAT table for platform with graphics version 20. 4! Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://lore.kernel.org/r/20230906193009.1912129-1-lucas.demarchi@intel.comSigned-off-by:
-
Matthew Auld authored
The concern here is that we may have platforms with dedicated media GT, and we anyway allocate the object on the tile, which just means running the same test twice (i.e primary vs media GT). Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@intel.com> Signed-off-by:
-
Matthew Auld authored
We need to sanitize and reset each GT, since xe_bo_evict_all() will evict everything regardless of GT, which can leave other GTs in a broken state. Signed-off-by:
-
Francois Dugast authored
This fixes the build without CONFIG_PM_SLEEP such as for riscv. Signed-off-by:
-
Matthew Brost authored
If multiple bind ops in an array of binds touch the same address range invalid GPUVA operations are generated as each GPUVA operation is generated based on the orignal GPUVA state. To fix this, after each GPUVA operations is generated, commit the GPUVA operation updating the GPUVA state so subsequent bind ops can see a current GPUVA state. Reviewed-by:
-
Matthew Brost authored
Add a helper to walk op list in reverse. Xe will make use of this when unwinding GPUVA operations. v2: (Rodrigo) reword commit message Reviewed-by:
-
Matthew Brost authored
Remap ops have 3 parts: unmap, prev, and next. The commit step can fail on any of these. Add a flag for each to these so the unwind is only done the steps that have been committed. v2: (Rodrigo) Use bit macros Reviewed-by:
-
Matthew Brost authored
Rather than open code the shift for values, use BIT macros. Reviewed-by:
-
Matthew Auld authored
Matches i915. Assumption going forward is that non-llc + igpu is only a thing on MTL+ which should have explicit coherency pat_index settings for COH_NONE, 1WAY and 2WAY. Signed-off-by:
Pallavi Mishra <pallavi.mishra@intel.com> Signed-off-by:
-
Matthew Auld authored
On PVC unloading followed by reloading the module often results in a completely dead machine (seems to be plaguing CI). Resetting the GuC like we do at load seems to cure it at least when locally testing this. v2: - Move pc_fini into guc_fini. We want to do the GuC reset just after calling pc_fini, otherwise we encounter communication failures. It also seems like a good idea to do the reset before we start releasing the various other GuC resources. In the case of pc_fini there is an explicit stop, but for other stuff like logs, ads, ctb there is not. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/542 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/597Signed-off-by: -
Pallavi Mishra authored
Reorder vm_id check after the one for VISIBLE_VRAM. This should prevent returning with locked vm in error scenario. Signed-off-by:
-
Zhanjun Dong authored
Add patch version info on GuC firmware init. This is required info for GuC log decoder. Signed-off-by:
Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20230817213028.838531-1-zhanjun.dong@intel.comSigned-off-by:
-
Niranjana Vishwanathapura authored
Some copy hardware engine instances are faster than others on PVC. Use a virtual engine of these plus the reserved instance for the migrate engine on PVC. The idea being if a fast instance is available it will be used and the throughput of kernel copies, clears, and pagefault servicing will be higher. v2: Use OOB WA, use all copy engines if no WA is required Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Wa_16017236439 requires that we update BCS_SWCTRL (via indirect context batch buffer) to set 64B transfers when running on an even-numbered BCS engine and 256B on an odd-numbered BCS engine. v2: Move WA from engine_was[] to lrc_was[] Reviewed-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Signed-off-by:
-
Niranjana Vishwanathapura authored
Wa_16017236439 requires the BCS_SWCTRL to be privileged. v2: Define and use BCS_SWCTRL() Reviewed-by:
-
Matthew Auld authored
Actually print the info.resv_space. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The current only submission in the driver that doesn't use a vm is the WA setup. We still pass a vm structure (the migration one), but we don't actually use it at submission time and we instead have an hack to use GGTT for this particular engine. Instead of special-casing the WA engine, we can skip providing a VM and use that as selector for whether to use GGTT or PPGTT. As part of this change, we can drop the special engine flag for the WA engine and switch the WA submission to use the standard job functions instead of dedicated ones. v2: rebased on s/engine/exec_queue Signed-off-by:
-
Daniele Ceraolo Spurio authored
If an engine is only destroyed on driver unload, we can skip its clean-up steps with the GuC because the GuC is going to be tuned off as well, so it doesn't matter if we're in sync with it or not. Currently, we apply this optimization to all engines marked as kernel, but this stops us to supporting kernel engines that don't stick around until unload. To remove this limitation, add a separate flag to indicate if the engine is expected to only be destryed on driver unload and use that to trigger the optimzation. While at it, add a small comment to explain what each engine flag represents. v2: s/XE_BUG_ON/XE_WARN_ON, s/ENGINE/EXEC_QUEUE v3: rebased Signed-off-by:
-
Daniele Ceraolo Spurio authored
Kernel queues can submit privileged batches directly in GGTT, so they don't always need a vm. The submission front-end already supports creating and submitting jobs without a vm, but some parts of the back-end assume the vm is always there. Fix this by handling a lack of vm in the back-end as well. v2: s/XE_BUG_ON/XE_WARN_ON, s/engine/exec_queue Signed-off-by:
-
Matt Roper authored
The only possible 64-bit register writes in the driver come from the highly questionable MMIO ioctl. That ioctl's register write support only operates for userspace running as root and cannot be used by any real userspace; it exists solely to support the "xe_reg" debug tool in IGT. Since the spec indicates that hardware does not officially support 64-bit register accesses, there's no reason to allow such 64-bit writes, even for debugging. Bspec: 60027 Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-4-matthew.d.roper@intel.comSigned-off-by:
-
Matt Roper authored
Intel hardware officially only supports GTTMMADR register accesses of 32-bits or less (although 64-bit accesses to device memory and PTEs in the GSM are fine). Even though we do usually seem to get back reasonable values when performing readq() operations on registers in BAR0, we shouldn't rely on this violation of the spec working consistently. It's likely that even when we do get proper register values back the hardware is internally satisfying the request via a non-atomic sequence of two 32-bit reads, which can be problematic for timestamps and counters if rollover of the lower bits is not considered. Replace xe_mmio_read64() with xe_mmio_read64_2x32() that implements 64-bit register reads as two 32-bit reads and attempts to ensure that the upper dword has stabilized to avoid problematic rollovers for counter and timestamp registers. v2: - Move function from xe_mmio.h to xe_mmio.c. (Lucas) - Convert comment to kerneldoc and note that it shouldn't be used on registers where reads may trigger side effects. (Lucas) Bspec: 60027 Reviewed-by:
-
Balasubramani Vivekanandan authored
LNL uses the Xe2 MOCS table introduced in an earlier patch. Bspec: 71582 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
-
Matt Roper authored
Define the GuC firmware to load on the platform. Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
-
Matt Roper authored
LNL is an integrated GPU based on the Xe2 architecture. Bspec: 70821 Signed-off-by:
-
Matt Roper authored
As with PVC, Xe2 platforms require that the index of an uncached MOCS entry be programmed into the GUC_SHIM_CONTROL register. This will likely be needed on future platforms as well. Xe2 also extends the size of the MOCS index register field from two bits to four bits. Since these extra bits were unused on PVC, it should be safe to just increase the size of the mask. Bspec: 60592 Cc: Haridhar Kalvala <haridhar.kalvala@intel.com> Signed-off-by:
-
Balasubramani Vivekanandan authored
Additional minor change to remove L4_2_RESERVED, which will never be required. v2: Make L3/L4 names consistent for GLOB_MOCS defines (Matt Roper) Bspec: 71582 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Matt Roper authored
Starting with Xe2, a 5-level page table is always used, regardless of the actual virtual address range supported by the platform. The two values need to be tracked separately in the device descriptor since Xe2 platforms only have a 48 bit virtual address range. Bspec: 59505, 65637, 70817 Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
-
Matt Roper authored
Xe2_LPM media is represented by GMD_ID value 20.00. It provides 1 VD + 1 VE + 1 SFC. Bspec: 70821, 70819 Signed-off-by:
-
Matt Roper authored
Define a common set of Xe2 graphics feature flags and definitions that will be used for all platforms in this family. Several of the feature flags are inherited unchanged from Xe_HP and/or Xe_HPC platforms: - dma_mask_size remains 46 (Bspec 70817) - supports_usm=1 (Bspec 59651) - has_flatccs=1 (Bspec 58797) - has_asid=1 (Bspec 59654, 59265, 60288) - has_range_tlb_invalidate=1 (Bspec 71126) However some of them still need proper implementation in the driver to be used, so they are disabled. Notable Xe2-specific changes: - All Xe2 platforms use a five-level page table, regardless of the virtual address space for the platform. (Bspec 59505) The graphics engine mask represents the Xe2 architecture engines (Bspec 60149), but individual platforms may have a reduced set of usable engines, as reflected by their fusing. Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
-
Matt Roper authored
Starting with Xe2, all platforms (including igpu platforms) use FlatCCS compression rather than AuxCCS. Similar to PVC, any future platforms that don't support FlatCCS should not attempt to fall back to AuxCCS programming. Signed-off-by:
-
Matt Roper authored
On Xe2 platforms, availability of the CCS engines is reflected in the FUSE4 register. Bspec: 62483 Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
Matt Roper authored
Engine register state layout has changed a bit on Xe2. We'll also explicitly define a BCS layout to ensure BLIT_SWCTL and BLIT_CCTL are included. Bspec: 65182, 60184, 55793 Signed-off-by:
-
