- 19 Dec, 2023 40 commits
-
-
Lucas De Marchi authored
The only thing really needed is the base offset, MCHBAR_MIRROR_BASE_SNB. Remove the include and just define it inplace. 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
Move a few defines from xe_guc_pc.c to the right register, now that there is one: xe_gt_regs.h. Signed-off-by:
-
Lucas De Marchi authored
Copy the macros used by xe in i915_reg.h to regs/xe_regs.h. A minimal cleanup is done while copying so they adhere minimally to the coding style. Further reordering and cleaning is left for later. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Copy the macros used by xe in intel_gpu_commands.h to regs/xe_gpu_commands.h. PIPE_CONTROL_3D_ENGINE_FLAGS and PIPE_CONTROL_3D_ARCH_FLAGS were already defined in drivers/gpu/drm/xe/xe_ring_ops.c and only used there. So let that define to be used instead of also adding to the new header. v2: Let PIPE_CONTROL_3D_ENGINE_FLAGS/PIPE_CONTROL_3D_ARCH_FLAGS in the only .c that uses it instead of redefining (Matt Roper) Signed-off-by: -
Lucas De Marchi authored
Create regs/xe_lrc_layout.h file with all the offsets used by the xe driver. Eventually the xe driver may use a different way to define them since it doesn't supported below gen12. v2: Rename file to intel_lrc_layout.h since it's not really about registers (Matt Roper) Signed-off-by: -
Lucas De Marchi authored
Create regs/xe_gt_regs.h file with all the registers and bit definitions used by the xe driver. Eventually the registers may be defined in a different way and since xe doesn't supported below gen12, the number of registers touched is much smaller, so create a new header. The definitions themselves are direct copy from the gt/intel_gt_regs.h file, just sorting the registers by address. Cleaning those up and adhering to a common coding style is left for later. v2: Make the change to MCR_REG location in a separate patch to go through the i915 branch (Matt Roper / Rodrigo) Signed-off-by: -
Lucas De Marchi authored
Create regs/xe_engine_regs.h file with all the registers and bit definitions used by the xe driver. Eventually the registers may be defined in a different way and since xe doesn't supported below gen12, the number of registers touched is much smaller, so create a new header. The definitions themselves are direct copy from the gt/intel_engine_regs.h file, just sorting the registers by address. Cleaning those up and adhering to a common coding style is left for later. Signed-off-by:
-
Lucas De Marchi authored
Sort includes and split them in blocks: 1) .h corresponding to the .c. Example: xe_bb.c should have a "#include "xe_bb.h" first. 2) #include <linux/...> 3) #include <drm/...> 4) local includes 5) i915 includes This is accomplished by running `clang-format --style=file -i --sort-includes drivers/gpu/drm/xe/*.[ch]` and ignoring all the changes after the includes. There are also some manual tweaks to split the blocks. v2: Also sort includes in headers Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Matt Roper authored
Starting with MTL, the GT forcewake ack register moved from 0x130044 to 0xDFC. We expect this change to carry forward to future platforms as well, so forcewake initialization should use an IP version check instead of matching the MTL platform specifically. The (re)definition of FORCEWAKE_ACK_GT_MTL in the forcewake file is also unnecessary; we can take the definition that already exists in the dedicated register header. Bspec: 65031, 64629 Signed-off-by:
-
Matt Roper authored
During early generations of Intel GPUs, hardware engines would sometimes move to new MMIO offsets from one platform/generation to the next. These days engines the hardware teams put more effort into ensuring that engines stay at consistent locations; even major design changes (like the introduction of standalone media) keep the MMIO locations of the engines constant. Since all platforms supported by the Xe driver are new enough to have a single MMIO offset for each engine (and since our crystal ball says that these offsets are very unlikely to change again in the foreseeable future), we can simplify the driver's engine definitions and remove the gen-based MMIO bases. Signed-off-by:
-
Lucas De Marchi authored
In order to avoid -Werror=missing-prototypes, add the prototypes in a separate tests/<test-name>_test.h file that is included by both the implementation (tests/xe_<testname>.c, injected in xe.ko) and the kunit module (tests/xe_<testname>_test.c -> xe-<testname>-test.ko). v2: Add header and don't add ifdef to files that are already not built when not using kunit (Matt Auld) Signed-off-by:
-
Matthew Auld authored
In local_pci_probe() the core kernel increments the rpm for the device, just before calling into the probe hook. If the driver/device supports runtime pm it is then meant to put this ref during probe (like we do in xe_pm_runtime_init()). However when removing the device we then also need to take the reference back, otherwise the ref that is put in pci_device_remove() will be unbalanced when for example unloading the driver, leading to warnings like: [ 3808.596345] xe 0000:03:00.0: Runtime PM usage count underflow! Fix this by incrementing the rpm ref when removing the device. v2: - Improve the terminology in the commit message; s/drop/put/ etc (Lucas & Rodrigo) - Also call pm_runtime_forbid(dev) (Rodrigo) Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/193Signed-off-by: -
Lucas De Marchi authored
i915_regs.h is not needed, particularly in a header file. What is needed is i915_reg_defs.h for use of _MMIO() and similar macros. Signed-off-by:
-
Lucas De Marchi authored
Use the more common "call cc-disable-warning" way to disable warnings. Signed-off-by:
-
Lucas De Marchi authored
media_verx100 supersedes the info from media_ver. Leave media_ver in the struct xe_device_desc, used in xe_pci.c since it's easier to define common parts of the platforms like that. However all the rest of the driver should be using media_verx100 that is more future proof. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/216Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Make xe_wait_user_fence.c include xe_wait_user_fence.h so it doesn't rely on indirect includes and also doesn't fail the build due to missing prototype for xe_wait_user_fence_ioctl(). Signed-off-by:
-
Lucas De Marchi authored
Fix the following warning: ../drivers/gpu/drm/xe/xe_ttm_stolen_mgr.c:55: warning: Function parameter or member 'xe' not described in 'xe_ttm_stolen_cpu_inaccessible' Signed-off-by:
-
Lucas De Marchi authored
xe_gt_topology_dss_group_mask and xe_gt_topology_count_dss are probably leftover from initial implementation - they are not called from anywhere. Remove those functions. Signed-off-by:
-
Lucas De Marchi authored
LRC tunings were added after the gt ones and didn't add the call in xe_gt_record_default_lrcs() to process them like is done for workarounds. Add such a function and call it from xe_gt_record_default_lrcs(). Signed-off-by:
-
Lucas De Marchi authored
A few static functions not being declared like that break the build with W=1, like e.g. cc1: all warnings being treated as errors make[2]: *** [../scripts/Makefile.build:250: drivers/gpu/drm/xe/xe_gt.o] Error 1 ../drivers/gpu/drm/xe/xe_guc.c:240:6: error: no previous prototype for ‘guc_write_params’ [-Werror=missing-prototypes] 240 | void guc_write_params(struct xe_guc *guc) | ^~~~~~~~~~~~~~~~ Make them static. Signed-off-by:
-
Matthew Auld authored
There are also some reserved fields in here which are not currently cleared when handing back to userspace. Otherwise we might run into issues if we later wish to use them. Signed-off-by:
-
Matthew Auld authored
The driver should still be functional with small-bar, just that the vram size is clamped to the BAR size (until we add proper support for tiered vram). For stolen vram we shouldn't iomap anything if the BAR size doesn't also contain the stolen portion, since on discrete the stolen portion is always at the end of normal vram. Stolen should still be functional, just that allocating CPU visible io memory will always return an error. v2 (Lucas) - Mention in the commit message that stolen vram is always as the end of normal vram, which is why stolen in not mappable on small-bar systems. - Just make xe_ttm_stolen_inaccessible() return true for such cases. Also rename to xe_ttm_stolen_cpu_inaccessible to better describe that we are talking about direct CPU access. Plus add some kernel-doc. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/209Reported-by: -
Matthew Auld authored
Make sure we properly release the forcewake ref on all error paths. v2(Lucas): - Make it less verbose and just fold the unimplemented options into the default. The exact return value doesn't seem to matter for the corresponding IGT. - Replace the user triggerable WARN() with drm_dbg(). Signed-off-by: -
Rodrigo Vivi authored
(!(gt->info.engine_mask & BIT(i))) cases are already handled in the init function. And these masks are not modified between the init and the prune. Suggested-by:
-
Carlos Santa authored
The list of GTs got splitted a while back between GT1 and GT2 on TGL. References: https://patchwork.freedesktop.org/patch/388414/ CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Carlos Santa <carlos.santa@intel.com> Reviewed-by:
-
José Roberto de Souza authored
ret is not initialized in mcr_lock() when running in platforms with graphics IP version < 1270, this could cause drm_WARN_ON_ONCE() to hit eventually(what just happened to me). Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Reviewed-by:
-
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 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:
-
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:
-
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 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:
-
