Lucas De Marchi [Fri, 8 Sep 2023 22:52:27 +0000 (15:52 -0700)]
drm/xe/mmio: Account for GSI offset when checking ranges
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.
Rodrigo Vivi [Wed, 30 Aug 2023 21:47:15 +0000 (17:47 -0400)]
drm/xe/uapi: Remove useless max_page_size
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: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com>
Lucas De Marchi [Wed, 6 Sep 2023 01:20:53 +0000 (18:20 -0700)]
drm/xe: Fix LRC workarounds
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:
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 28cf243a341a ("drm/i915/gt: Fix context
workarounds with non-masked regs"). In the same test with ADL-P as
above:
Lucas De Marchi [Wed, 6 Sep 2023 01:20:50 +0000 (18:20 -0700)]
drm/xe/reg_sr: Simplify check for masked registers
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: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://lore.kernel.org/r/20230906012053.1733755-2-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Fri, 1 Sep 2023 14:28:26 +0000 (15:28 +0100)]
drm/xe/selftests: make eviction test tile centric
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Brost [Thu, 17 Aug 2023 03:15:38 +0000 (20:15 -0700)]
drm/xe: Fix array of binds
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.
Matthew Brost [Mon, 14 Aug 2023 03:19:20 +0000 (20:19 -0700)]
drm/xe: Fixup unwind on VM ops errors
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.
Matthew Auld [Tue, 29 Aug 2023 16:28:43 +0000 (17:28 +0100)]
drm/xe: fix has_llc on rkl
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: Matthew Auld <matthew.auld@intel.com> Cc: Pallavi Mishra <pallavi.mishra@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Pallavi Mishra <pallavi.mishra@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Thu, 24 Aug 2023 16:04:45 +0000 (17:04 +0100)]
drm/xe: nuke GuC on unload
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/597 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/xe/pvc: Use fast copy engines as migrate engine on PVC
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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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.
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.
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.
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.
Matt Roper [Wed, 23 Aug 2023 00:33:14 +0000 (17:33 -0700)]
drm/xe: Drop xe_mmio_write64()
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: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-4-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Wed, 23 Aug 2023 00:33:13 +0000 (17:33 -0700)]
drm/xe: Avoid 64-bit register reads
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: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://lore.kernel.org/r/20230823003312.1356779-3-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 11 Aug 2023 16:06:15 +0000 (09:06 -0700)]
drm/xe/xe2: Program GuC's MOCS on Xe2 and beyond
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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 11 Aug 2023 16:06:13 +0000 (09:06 -0700)]
drm/xe/xe2: Track VA bits independently of max page table level
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 <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 11 Aug 2023 16:06:11 +0000 (09:06 -0700)]
drm/xe/xe2: Define Xe2_LPG IP features
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 <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 11 Aug 2023 16:06:10 +0000 (09:06 -0700)]
drm/xe/xe2: AuxCCS is no longer used
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 <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 11 Aug 2023 16:06:07 +0000 (09:06 -0700)]
drm/xe/xe2: Add MCR register steering for media GT
Xe2 media has a few types of MCR registers, but all except for "GPMXMT"
can safely steer to instance 0,0. GPMXMT follows the same rules that
MTL's OADDRM ranges did, so it can re-use the same enum value.
Bspec: 71186 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 11 Aug 2023 16:06:06 +0000 (09:06 -0700)]
drm/xe/xe2: Add MCR register steering for primary GT
Xe2 uses the same steering control register and steering semaphore
register as MTL. As with recent platforms, group/instance 0,0 is
sufficient to target a non-terminated instance for most classes of MCR
registers; the only types of ranges that need to consider platform
fusing to find a non-terminated instance are SLICE/DSS ranges and a new
SQIDI_PSMI type of range.
Note that the range of valid bits in XE2_NODE_ENABLE_MASK may be reduced
for some Xe2 SKUs. However the lowest bits are always valid and only
the lowest instance is obtained via __ffs(), so there's no need to
complicate the masking with extra platform/subplatform checks.
Also note that Wa_14017387313 suggests skipping MCR lock acquisition
around GAM and GAMWKR registers to prevent MCR register accesses in an
interrupt handler from deadlocking when the steering semaphore is
already held outside the interrupt context. At this time Xe never
issues MCR accesses from within an interrupt handler so the workaround
is not currently needed.
v2:
- [0x008700-0x0087FF] range to extend up to 0x887F (Matt Attwood)
- [0x00EF00-0x00F4FF] -> [0x00F000, 0xFFFF] to follow latest
bspec version (Bala)
Bspec: 71185 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Thu, 17 Aug 2023 23:04:12 +0000 (16:04 -0700)]
drm/xe: Stop tracking 4-tile support
The choice of Y-major tiling format (either the legacy "TileY" or the
newer "Tile4") is based on graphics IP version (12.50 and beyond have
Tile4, earlier platforms have TileY). The tracking in xe was originally
added to allow re-using display from i915. However as of i915 commit 4ebf43d0488f ("drm/i915: Eliminate has_4tile feature flag"), the display
code determines TileY vs Tile4 itself, so this can be removed from xe.
drm/xe: enable idle msg and set hysteresis for GSCCS
On MTL (and only on MTL) the GSCCS defaults with idle messaging
disabled. This means that, once awoken, the GSCCS will never signal its
idleness to the GT. To allow the GT to enter the proper low-power state,
we need therefore to turn idle messaging on. As part of this, we also
need to set a proper hysteresis value for the engine.
v2: use MEDIA_VERSION() and CLR() for the RTP rule and action, add reg
bit define in descending order (Matt)
Like the BCS, the GSCCS doesn't have any special HW that needs handling
when emitting commands, so we can re-use the same emit_job code. To make
it clear that this is now a shared low-level function, it has been
renamed to use the "simple" postfix, instead of "copy", to indicate that
it applies to all engines that don't need any additional engine-specific
handling.
The queue name assignment is identical in both GuC and execlists
backends, so we can move it to a common function. This will make adding
a new entry in the next patch slightly cleaner.
Oak Zeng [Fri, 14 Jul 2023 14:42:07 +0000 (10:42 -0400)]
drm/xe: Improve vram info debug printing
Print both device physical address range and CPU io range
of vram. Also print vram's actual size, usable size excluding
stolen memory, and CPU io accessible size.
V1:
- Add back small BAR device info (Matt)
Signed-off-by: Oak Zeng <oak.zeng@intel.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Oak Zeng [Tue, 11 Jul 2023 21:46:09 +0000 (17:46 -0400)]
drm/xe: Make xe_mem_region struct
Make a xe_mem_region structure which will be used in the
coming patches. The new structure is used in both xe device
level (xe->mem.vram) and xe_tile level (tile->vram).
Make the definition of xe_mem_region.dpa_base to be the DPA
base of this memory region and change codes according to
this new definition.
v1:
- rename xe_mem_region.base to dpa_base per conversation with Mike
Ruhl
Signed-off-by: Oak Zeng <oak.zeng@intel.com> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Brost [Fri, 11 Aug 2023 13:27:34 +0000 (06:27 -0700)]
drm/xe: Call __guc_exec_queue_fini_async direct for KERNEL exec_queues
Usually we call __guc_exec_queue_fini_async via a worker as the
exec_queue fini can be done from within the GPU scheduler which creates
a circular dependency without a worker. Kernel exec_queues are fini'd at
driver unload (not from within the GPU scheduler) so it is safe to
directly call __guc_exec_queue_fini_async.
Matthew Auld [Tue, 8 Aug 2023 09:12:09 +0000 (10:12 +0100)]
drm/xe: skip rebind_list if vma destroyed
If we are closing a vm, mark each vma as XE_VMA_DESTROYED and skip
touching the rebind_list if this is seen on the eviction path. That way
we can safely drop the vm dma-resv lock on the close path without
needing to worry about racing with the eviction path trying to add stuff
to the rebind_list which can corrupt our contended list, since the
destroy and rebind links are the same list entry underneath.
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/514 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Auld [Wed, 9 Aug 2023 08:16:18 +0000 (09:16 +0100)]
drm/xe/guc_submit: fixup deregister in job timeout
Rather check if the engine is still registered before proceeding with
deregister steps. Also the engine being marked as disabled doesn't mean
the engine has been disabled or deregistered from GuC pov, and here we
are signalling fences so we need to be sure GuC is not still using this
context.
v2:
- Drop the read_stopped() for this path. Since we are signalling
fences on error here, best play it safe and wait for the GT reset to
mark the engine as disabled, rather than it just being queued.
v3 (Matt Brost):
- Keep the read_stopped() on the wait event, since there is no need to
wait for an already scheduled GT reset. If it is set we can then just
bail without signalling anything.
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Anshuman Gupta [Wed, 2 Aug 2023 07:04:49 +0000 (12:34 +0530)]
drm/xe/pm: Add vram_d3cold_threshold for d3cold capable device
Do not register vram_d3cold_threshold device sysfs universally
for each gfx device, only register sysfs and set the threshold
value for d3cold capable devices.
Matt Roper [Thu, 27 Jul 2023 22:09:21 +0000 (15:09 -0700)]
drm/xe: Add Wa_14015150844 for DG2 and Xe_LPG
The workaround database tells us to set this bit, even though the bspec
indicates the bit doesn't exist on these platforms. Since this is a
write-only register, we also can't read back its value to verify whether
it's actually working or not. For now we'll trust that the workaround
database knows what it's talking about; if not, the hardware will just
ignore the attempt to write to a non-existent bit and it shouldn't cause
any problems.
To workaround a HW bug on DG2, driver is required to map the whole
ppgtt virtual address space before GPU workload submission. Thus
set the XE_VM_FLAG_SCRATCH_PAGE flag during vm create so the whole
address space is mapped to point to scratch page.
v1:
- Move the workaround implementation from xe_vm_create to
xe_vm_create_ioctl - Brian
- Reorder error checking in xe_vm_create_ioctl - Jose
- Implement WA only for DG2-G10 and DG2-G12
Signed-off-by: Oak Zeng <oak.zeng@intel.com> Reviewed-by: Brian Welty <brian.welty@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matthew Brost [Thu, 3 Aug 2023 03:15:38 +0000 (20:15 -0700)]
drm/xe: Set max pte size when skipping rebinds
When a rebind is skipped, we must set the max pte size of the newly
created vma to value of the old vma as we do not pte walk for the new
vma. Without this future rebinds may be incorrectly skipped due to the
wrong max pte size. Null binds are more likely to expose this bug as
larger ptes are more frequently used compared to normal bindings.
Matthew Auld [Thu, 3 Aug 2023 17:38:50 +0000 (18:38 +0100)]
drm/xe/guc_submit: prevent repeated unregister
It seems that various things can trigger the lr cleanup worker,
including CAT error, engine reset and destroying the actual engine, so
seems plausible to end up triggering the worker more than once in some
cases. If that does happen we can race with an ongoing engine deregister
before it has completed, thus triggering it again and also changing the
state back into pending_disable. Checking if the engine has been marked
as destroyed looks like it should prevent this.
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tejas Upadhyay [Fri, 4 Aug 2023 06:24:23 +0000 (11:54 +0530)]
drm/xe: Add min/max cap for engine scheduler properties
Add sysfs entries for the min, max, and defaults for each of
engine scheduler controls for every hardware engine class.
Non-elevated user IOCTLs to set these controls must be within
the min-max ranges of the sysfs entries, elevated user can set
these controls to any value. However, introduced compile time
CONFIG min-max values which restricts elevated user to be in
compile time min-max range if at all sysfs min/max are violated.
V12:
- Rebase
V11:
- Make engine_get_prop_minmax and enforce_sched_limit static - Matt
- use enum in place of string in engine_get_prop_minmax - Matt
- no need to use enforce_sched_limit or no need to filter min/max
per user type in sysfs - Matt
V10:
- Add kernel doc for non-static func
- Make helper to get min/max for range validation - Matt
- Filter min/max per user type
V9 :
- Rebase to use s/xe_engine/xe_hw_engine/ - Matt
V8 :
- fix enforce_sched_limit and avoid code duplication - Niranjana
- Make sure min < max - Niranjana
V7 :
- Rebase to replace hw engine with eclass interface
- return EINVAL in place of EPERM
- Use some APIs to avoid code duplication
V6 :
- Rebase changes to reflect per engine class props interface - MattB
- Use #if ENABLED - MattB
- Remove MAX_SCHED_TIMEOUT check as range validation is enough
V5 :
- Rebase to resolve conflicts - CI
V4 :
- Rebase
- Update commit to reflect tile addition
- Use XE_HW macro directly as they are already filtered
for CONFIG checks - Niranjana
- Add CONFIG for enable/disable min/max limitation
on elevated user. Default is enable - Matt/Joonas
V3 :
- Resolve CI hooks warning for kernel-doc
V2 :
- Restric min/max setting to #define default min/max for
elevated user - Himal
- Remove unrelated changes from patch - Niranjana
V7:
- Rebase
V6:
- Rebase to use s/xe_engine/xe_hw_engine/ - Matt
V5:
- Remove timeout validation, not relevant - Niranjana
V4:
- Rebase to replace hw engine with eclass interface
V3:
- Rebase to per class engine props interface
V2:
- Rebase
- Update commit message to add tile
V8:
- Rebase
V7:
- Rebase to use s/xe_engine/xe_hw_engine/ - Matt
V6:
- Remove duration validation, not relevant - Niranjana
V5:
- Rebase to replace hw engine with eclass interface
V4:
- Rebase to per class engine props interface
V3:
- Rebase
- Update commit messge to add tile
V2:
- Rebase
V8:
- Rebase
V7:
- Rebase to use s/xe_engine/xe_hw_engine/ - Matt
V6:
- Remove timeout validation, not relevant - Niranjana
- Rebase to use common error path
V5:
- Rebase to use engine class interface instead of hw engine
V4:
- Rebase to per class engine props interface
V3:
- Rebase
- Update commit message to reflect tile update
V2:
- Use sysfs_create_files as part of this patch
Tejas Upadhyay [Fri, 4 Aug 2023 12:06:25 +0000 (17:36 +0530)]
drm/xe: Add sysfs for default engine scheduler properties
For each HW engine under GT we are adding defaults sysfs
entry to list all engine scheduler properties and its
default values. So that it will be easier for user to
fetch default values of these properties anytime to go
back to default.
For example,
DUT# cat /sys/class/drm/card1/device/tileN/gtN/engines/bcs/.defaults/
job_timeout_ms preempt_timeout_us timeslice_duration_us
where,
@job_timeout_ms: The time after which a job is removed from the scheduler.
@preempt_timeout_us: How long to wait (in microseconds) for a preemption
event to occur when submitting a new context.
@timeslice_duration_us: Each context is scheduled for execution for the
timeslice duration, before switching to the next
context.
V12:
- Add missing drmm_add_action_or_reset and remove sysfs files
V11:
- Rebase
V10:
- Remove xe_gt.h inclusion from .h - Matt
V9 :
- Remove jiffies for job_timeout_ms - Matt
V8 :
- replace xe_engine with xe_hw_engine - Matt
V7 :
- Push all errors to one error path at every places - Niranjana
- Describe struct member to resolve kernel doc err - CI hooks
V6 :
- Use engine class interface instead of hw engine
in sysfs for better interfacing readability - Niranjana
V5 :
- Scheduling props should apply per class engine not per hardware engine - Matt
- Do not record value of job_timeout_ms if changed based on dma_fence - Matt
V4 :
- Resolve merge conflicts - CI
V3 :
- Rearrange code in its own file
- Rebase
- Update commit message to reflect tile addition
V2 :
- Use sysfs_create_files in this patch - Niranjana
- Handle prototype error for xe_add_engine_defaults - CI hooks
- Remove unused member sysfs_hwe - Niranjana
Tejas Upadhyay [Fri, 4 Aug 2023 11:47:56 +0000 (17:17 +0530)]
drm/xe: Add sysfs entries for engines under its GT
Add engines sysfs directory under its GT and
create sub directory for all engine class
(note its not per instance) present on GT.
For example,
DUT# cat /sys/class/drm/cardX/device/tileN/gtN/engines/
bcs/ ccs/
V9 :
- Add missing drmm_add_action_or_reset
V8 :
- Rebase
V7 :
- Remove xe_gt.h from .h and include in .c - Matt
V6 :
- Add kernel doc and arrange file in make file by alphabet - Matt
V5 :
- replace xe_engine with xe_hw_engine - Matt
V4 :
- Rebase to resolve conflicts - CI
V3 :
- Move code in its own file
- Rename API name
V2 :
- Correct class mask logic - Himal
- Remove extra parenthesis
Engine was inappropriately used to refer to execution queues and it
also created some confusion with hardware engines. Where it applies
the exec_queue variable name is changed to q and comments are also
updated.
drm/xe: Prefer WARN() over BUG() to avoid crashing the kernel
Replace calls to XE_BUG_ON() with calls XE_WARN_ON() which in turn calls
WARN() instead of BUG(). BUG() crashes the kernel and should only be
used when it is absolutely unavoidable in case of catastrophic and
unrecoverable failures, which is not the case here.
Matthew Brost [Fri, 28 Jul 2023 02:00:14 +0000 (19:00 -0700)]
drm/xe: Remove XE_GUC_CT_SELFTEST
XE_GUC_CT_SELFTEST enabled a debugfs entry to which ran a very simple
selftest ensuring the GuC CT code worked. This was added before the
kunit framework was available and before submissions were working too.
This test isn't worth porting over to the kunit frame as if the GuC CT
didn't work, literally almost nothing would work so just remove this.
Suggested-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Matt Roper [Fri, 28 Jul 2023 17:56:02 +0000 (10:56 -0700)]
drm/xe/mtl: Reduce Wa_14018575942 scope to the CCS engine
The MTL version of Wa_14018575942 has been updated to suggest only
applying the register change on the CCS engine.
Note that DG2 and PVC have a functionally equivalent workaround with
Wa_18018781329; for now that one is still applying to all engines,
although we'll keep an eye on it in case it changes to be CCS-specific
too.
drm/xe: Fix the runtime_idle call and d3cold.allowed decision.
According to Documentation/power/runtime_pm.txt:
int pm_runtime_put(struct device *dev);
- decrement the device's usage counter; if the result is 0 then run
pm_request_idle(dev) and return its result
int pm_runtime_put_autosuspend(struct device *dev);
- decrement the device's usage counter; if the result is 0 then run
pm_request_autosuspend(dev) and return its result
We need to ensure that the idle function is called before suspending
so we take the right d3cold.allowed decision and respect the values
set on vram_d3cold_threshold sysfs. So we need pm_runtime_put()
instead of pm_runtime_put_autosuspend().
Send uevent in case of gt reset failure. This intimation can be used by
userspace monitoring tool to do the device level reset/reboot
when GT reset fails. udevadm can be used to monitor the uevents.
v2:
- Support only gt failure notification (Rodrigo)
v3
- Rectify the comments in header file.
v4
- Use pci kobj instead of drm kobj for notification.(Rodrigo)
- Cleanup (Badal)
v5
- Add tile id and gt id as additional info provided by uevent.
- Provide code documentation for the uevent. (Rodrigo)
The order: 'offset, mask, val'; is more common in other
drivers and in special in i915, where any dev could copy
a sequence and end up with unexpected behavior.
We cannot have spin locks around xe_irq_reset, since it will
call the intel_display_power_is_enabled() function, and
that needs a mutex lock. Hence causing the undesired
"[ BUG: Invalid wait context ]"
We cannot convert i915's power domain lock to spin lock
due to the nested dependency of non-atomic context waits.
So, let's move the xe_irq_reset functions from the
critical area, while still ensuring that we are protecting
the irq.enabled and ensuring the right serialization
in the irq handlers.
v2: On the first version, I had missed the fact that
irq.enabled is checked on the xe/display glue layer,
and that i915 display code is actually using the irq
spin lock properly. So, this got changed to a version
suggested by Matthew Auld.
v3: do not use lockdep_assert for display glue.
do not save restore irq from inside IRQ or we can
get bogus irq restore warnings
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/463 Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Lucas De Marchi [Wed, 26 Jul 2023 16:07:07 +0000 (09:07 -0700)]
drm/xe: Carve out top of DSM as reserved
Top of DSM contains the WOPCM where kernel driver shouldn't access as
it contains data from other HW agents. Carve it out from the stolen
memory. On a MTL system, the output now matches the expected values:
Lucas De Marchi [Wed, 26 Jul 2023 16:07:06 +0000 (09:07 -0700)]
drm/xe: Fix MTL+ stolen memory mapping
Based on commit 8d8d062be6b9 ("drm/i915/mtl: Fix MTL stolen memory GGTT
mapping"). For stolen on MTL and beyond, the address in the PTE is the
offset from DSM base. While at it, update the comments explaining each
part of the calculation.
Lucas De Marchi [Wed, 26 Jul 2023 16:07:04 +0000 (09:07 -0700)]
drm/xe: Set PTE_DM bit for stolen on MTL
Integrated graphics 1270 and beyond should set the PTE_LM bit in the PTE
when it's stolen memory. Add a new function, xe_bo_is_stolen_devmem(),
and use it when encoding the PTE.
In some places in the spec the PTE bit is called "Local Memory",
abbreviated as LM, and in others it's called "Device Memory" (DM). Since
we moved away from "Local Memory" and preferred the "vram" terminology,
also rename the macros as DM to follow the name of the new function.
Lucas De Marchi [Wed, 26 Jul 2023 16:07:03 +0000 (09:07 -0700)]
drm/xe: Decouple vram check from xe_bo_addr()
The output arg is_vram in xe_bo_addr() is unused by several callers.
It's also not what the function is mainly doing. Remove the argument and
let the interested callers to call xe_bo_is_vram().
in commit 81593af6c88d ("drm/xe: Convert xe_mmio_wait32 to us so we can
stop using wait_for_us.") the mcr semaphore register read was
accidentally switched from waiting for the register to go to 1 to
waiting for the register to go to 0, so we need to flip it back.
projects / mirror_ubuntu-kernels.git / log