- 19 Dec, 2023 40 commits
-
-
Lucas De Marchi authored
Just like there is support for multiple rules per entry in an rtp table, also support multiple actions. This makes it easier to add support for workarounds that need to change multiple registers. It also makes it slightly more readable as now the action part resembles the rule part. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Entry flags is meant for the whole entry, including the rule evaluation. Action flags are for flags applied to the register or action being taken. Since there's only one action per entry, the distinction was not important and a u8 was spared. However more and more workarounds are needing multiple actions. This prepares for multiple action support. Right now there are these action flags: - XE_RTP_ACTION_FLAG_MASKED_REG: register in the action is a masked register - XE_RTP_ACTION_FLAG_ENGINE_BASE: the engine base should be added to the register in order to form the real address And this entry flag: - XE_RTP_ENTRY_FLAG_FOREACH_ENGINE: the rules should be evaluated for each engine on the gt. It also automatically implies XE_RTP_ACTION_FLAG_ENGINE_BASE. Since there are likely not that many rules, reduce n_rules to u8 so the overall entry size doesn't increase more than needed. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Lucas De Marchi authored
It's true that the struct records the register and the value (in form of 2 masks) to restore, but it also records more fields important to the application of workarounds/tuning, etc. One important part is what is the macro used to record these fields: SET/CLR/WR/FIELD_SET/etc. Thinking of the table as a set of rules + actions is more intuitive than rules + regval. Signed-off-by:
-
Lucas De Marchi authored
Like detailed in commit 927dfdd0 ("drm/i915/dg2: Add SQIDI steering"), some registers are expected to have the selector initialized just once and never set to anything else. For xe, the registers with SQIDI replication type (SF and MCFG) were missing, resulting in warnings like: [ 410.685565] xe 0000:03:00.0: Did not find MCR register 0x8724 in any MCR steering table While adding these registers, abstract the handling for "dg2_gam_ranges", moving them together with SF/MCFG to a dedicated table. This also avoids that range to be checked for platforms other than DG2. For DG2, this is the new steering output: # cat /sys/kernel/debug/dri/0/gt0/steering ... IMPLICIT steering: group=0x0, instance=0x0 0x000b00 - 0x000bff 0x001000 - 0x001fff 0x004000 - 0x004aff 0x008700 - 0x0087ff 0x00c800 - 0x00cfff 0x00f000 - 0x00ffff Signed-off-by:
-
Lucas De Marchi authored
There is already a BUILD_BUG_ON() check to make sure the size follow the number of steering types. Also make sure the right index is being used for each steering type. Signed-off-by:
-
Lucas De Marchi authored
LRC workarounds are already implemented: remove leftover TODO. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
-
Lucas De Marchi authored
The function pointer is already present as match_func, inside struct xe_rtp_rule and handled as so instead of inside rtp_regval as originally thought out when this was written. Signed-off-by:
-
Lucas De Marchi authored
xe_tuning.c should include xe_tuning.h, not xe_wa.h Signed-off-by:
-
Lucas De Marchi authored
Add missing "multicast" word and adapt/wrap the rest of the sentence. Signed-off-by:
-
Maarten Lankhorst authored
Adding a debugfs dump of GGTT was useful for some debugging I did, and easy to add. Might be useful for others too. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Matthew Brost authored
Now that we issue TLB invalidations on unbinds and rebind from execs we no longer need to issue TLB invalidations from the ring operations. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
-
Matthew Brost authored
If we add an TLB invalidation fence for rebinds issued from execs we should be able to drop the TLB invalidation from the ring operations. Signed-off-by:
-
Matthew Brost authored
Rather than alias supports_usm to ASIS support, add an explicit variable to indicate ASID support. Signed-off-by:
-
Matthew Brost authored
This means we are in the middle of a GT reset and no need to do TLB invalidation so just signal invalidation fence immediately. Signed-off-by:
-
Matthew Brost authored
If a VM unbind hits an error, do not issue a TLB invalidation and propagate the error the invalidation fence. Signed-off-by:
-
Matthew Brost authored
Make lockdep happy as we required to hold the GGTT when calling xe_ggtt_map_bo. Signed-off-by:
-
Matthew Brost authored
Only the GuC should be issuing TLB invalidations if it is enabled. Part of this patch is sanitize the device on driver unload to ensure we do not send GuC based TLB invalidations during driver unload. Signed-off-by:
-
Matthew Brost authored
If an bind operation fails we need to report it via the async fence. Signed-off-by:
-
Matthew Brost authored
If the platform supports range based TLB invalidations use them. Hide these details in the xe_gt_tlb_invalidation layer. Signed-off-by:
-
Matthew Brost authored
This will help implementing range based TLB invalidations. Signed-off-by:
-
Matthew Brost authored
Not used, let's remove this. Signed-off-by:
-
Matthew Brost authored
This will help with TLB invalidation as the ASID in TLB invalidate should be zero for platforms that do not support a ASID. Signed-off-by:
-
Matthew Brost authored
Endless fences are not good, add a TDR to cleanup any invalidation fences which have not received an invalidation message within a timeout period. Signed-off-by:
-
Matthew Brost authored
This will help debug issues with TLB invalidation fences. Signed-off-by:
-
Matthew Brost authored
Document all exported functions. Signed-off-by:
-
Matthew Brost authored
This gets tricky as we can't do the TLB invalidation until the unbind operation is done on the hardware and we can't signal the unbind as complete until the TLB invalidation is done. To work around this we create an unbind fence which does a TLB invalidation after unbind is done on the hardware, signals on TLB invalidation completion, and this fence is installed in the BO dma-resv slot and installed in out-syncs for the unbind operation. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
-
Matthew Brost authored
Fence will be signaled when TLB invalidation completion. Signed-off-by:
-
Matthew Brost authored
TLB invalidations no longer just restricted to USM, move the variables to own sub-structure. Signed-off-by:
-
Matthew Brost authored
TLB invalidation is used by more than USM (page faults) so break this code out into its own file. Signed-off-by:
-
Matthew Brost authored
We can't currently do this due to TLB invalidation done handler expecting the seqno being received in-order, with the fast-path a TLB invalidation done could pass one being processed in the slow-path in an extreme corner case. Remove TLB invalidation done from the fast-path for now and in a follow up reenable this once the TLB invalidation done handler can deal with out of order seqno. Signed-off-by:
-
Matthew Brost authored
emit_pte assumes the size argument is 4k aligned, this may not be true for the PTEs emitted for CSS as seen by below call stack: [ 56.734228] xe_migrate_copy:585: size=327680, ccs_start=327680, css_size=1280,4096 [ 56.734250] xe_migrate_copy:643: size=262144 [ 56.734252] emit_pte:404: ptes=64 [ 56.734255] emit_pte:418: chunk=64 [ 56.734257] xe_migrate_copy:650: size=1024 @ CCS emit PTE [ 56.734259] emit_pte:404: ptes=1 [ 56.734261] emit_pte:418: chunk=1 [ 56.734339] xe_migrate_copy:643: size=65536 [ 56.734342] emit_pte:404: ptes=16 [ 56.734344] emit_pte:418: chunk=16 [ 56.734346] xe_migrate_copy:650: size=256 # CCS emit PTE [ 56.734348] emit_pte:404: ptes=1 [ 56.734350] emit_pte:418: chunk=1 [ 56.734352] xe_res_next:174: size=4096, remaining=0 Update emit_pte to handle sizes less than 4k. Signed-off-by:
-
Matthew Auld authored
Scratch page is in VRAM, and therefore requires 64K GTT layout. In GGTT world this just means having 16 consecutive entries, with 64K GTT alignment for the GTT address of the first entry (also matching physical alignment). However to keep things simple just dump it into system memory, like we already do for ppGTT. While we are here, also give it known default value. Signed-off-by:
-
Matthew Auld authored
Spec says we need to use 64K VRAM pages for GGTT on platforms like DG2. In GGTT this just means aligning the GTT address to 64K and ensuring that we have 16 consecutive entries each pointing to the respective 4K entry. We already ensure we have 64K pages underneath, so it's just a case of forcing the GTT alignment. Signed-off-by:
-
Matthew Auld authored
On DG2 when running the xe_vm IGT, the kernel generates loads of CAT errors and GT resets (sometimes at least). On small-bar systems seems to trigger a lot more easily (maybe due to difference in allocation strategy). Appears to be related to scratch, since we seem to use the 64K TLB hint on scratch entries, even though the scratch page is a 4K vram page. Bumping the scratch page size and physical alignment seems to fix it. Or at least we no longer hit: [ 148.872683] xe 0000:03:00.0: [drm] Engine memory cat error: guc_id=0 [ 148.872701] xe 0000:03:00.0: [drm] Engine memory cat error: guc_id=0 [ 148.875108] WARNING: CPU: 0 PID: 953 at drivers/gpu/drm/xe/xe_guc_submit.c:797 However to keep things simple, so we don't have to deal with 64K TLB hints, just move the scratch page into system memory on platforms that require 64K VRAM pages. Signed-off-by:
-
Matthew Auld authored
We need to ensure we don't leak the contents to userspace. Signed-off-by:
-
Matthew Auld authored
On DGFX this blows up if can call this with a system memory object: XE_BUG_ON(!mem_type_is_vram(place->mem_type) && place->mem_type != XE_PL_STOLEN); If we consider dpt it looks like we can already in theory hit this, if we run out of vram and stolen vram. It at least seems reasonable to allow calling this on any object which supports CPU access. Note this also changes the behaviour with stolen VRAM and suspend, such that we no longer attempt to migrate stolen objects into system memory. However nothing in stolen should ever need to be restored (same on integrated), so should be fine. Also on small-bar systems the stolen portion is pretty much always non-CPU accessible, and currently pinned objects use plain memcpy when being moved, which doesn't play nicely. Signed-off-by:
-
Maarten Lankhorst authored
I saw a flicker when booting xe, and it's very likely that the original FB was not mapped at the same place when inheriting, fix it. Signed-off-by:
-
Maarten Lankhorst authored
The comparison with < 0 suggests that the memory device access should be signed to handle underflow. This makes it work more reliably. As a result, the max refcount is now S32_MAX instead. Signed-off-by:
-
José Roberto de Souza authored
This is intended to get some properties that are of interest of UMDs like the ban state. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
Engine property get uAPI will be added, so to avoid ambiguity here renaming XE_ENGINE_PROPERTY_X to XE_ENGINE_SET_PROPERTY_X. No changes in behavior. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
