- 19 Dec, 2023 40 commits
-
-
Thomas Hellström authored
It appears we don't hold a memory access reference for the accesses in this test, which may results in printed warnings and possibly the GT not woken up for the memory accesses. Add a memory access reference around the test. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Thomas Hellström authored
We currently don't have any tests that explicitly depends on this config option, so remove that build dependency. Signed-off-by:
-
Lucas De Marchi authored
When this register was added in xe for some workarounds, it was copied from i915 before the registers got changed to add the MCR annotation. The register 0xe4f4 is MCR since gen8, long before any GPU supported by the xe driver. Replace all occurrences with the right register. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230306165757.633796-1-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
The following warning shows up for TGL: [drm:xe_reg_sr_add [xe]] *ERROR* Discarding save-restore reg 6604 (clear: 00ff0000, set: 00040000, masked: no): ret=-22 [drm:xe_reg_sr_add [xe]] *ERROR* Discarding save-restore reg 6604 (clear: 00ff0000, set: 00040000, masked: no): ret=-22 That is because the same register is being set both by the WAs and the tunings. Like was done in i915, prefer the tuning over the workaround since that is applicable for more platforms. Also fix the tuning: it was incorrectly using the MCR version of the register, but that only became true in XEHP. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/233Reported-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
José Roberto de Souza authored
XE_MAX_DSS_FUSE_REGS was being used to calculate the size of xe_eu_mask_t while it should use XE_MAX_EU_FUSE_REGS. There are no know issues about this but fixing it anyways. Reviewed-by:
-
Lucas De Marchi authored
Fix typo as noticed by Matt Roper: git grep -l persitent | xargs sed -i 's/persitent/persistent/g' ... and then fix coding style issues. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://lore.kernel.org/r/20230302013411.3262608-2-lucas.demarchi@intel.comSigned-off-by:
-
Lucas De Marchi authored
There's inconsistent use of mutex_init(), in xe_device_create(), with several of them never calling mutex_destroy() in xe_device_destroy(). Migrate all of them to drmm_mutex_init(), so the destroy part is automatically called. Signed-off-by:
-
Matthew Auld authored
In the depths of ttm, when allocating the vma node this should result in -ENOSPC it seems. However we should probably rather reject as part of our own ioctl sanity checking, and then treat as programmer error in the lower levels. Signed-off-by:
-
Matthew Auld authored
With small-bar we likely want to annotate all the kernel users that require CPU access with vram. If xe_bo_create_pin_map() is the central place for that then we should have a central place to annotate. This also simplifies the code and fixes what appears to be a double xe_bo_put(hwe->hwsp) in the error handling. Signed-off-by:
-
Matt Roper authored
The HAS_RENDER_L3CC is set unconditionally so there's no need to keep it as a dedicated flag. For error checking purposes, we can just make sure the 'table' field is initialized properly. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Suggested-by:
-
Matt Roper authored
Reprogramming the LNCF MOCS registers on render domain reset is not intended to be regular driver programming, but rather the implementation of a specific workaround (Wa_1607983814). This workaround no longer applies on Xe_HP any beyond, so we can expect that these registers, like the rest of the LNCF/LBCF registers, will maintain their values through all engine resets. We should only add these registers to the GuC's save/restore list on platforms that need the workaround. Furthermore, xe_mocs_init_engine() appears to be another attempt to satisfy this same workaround. This is unnecessary on the Xe driver since even on platforms where the workaround is necessary, all single-engine resets are initiated by the GuC and thus the GuC will take care of saving/restoring these registers. The only host-initiated resets we have in Xe are full GT resets which will already (re)initialize these registers as part of the regular xe_mocs_init() flow. v2: - Add needs_wa_1607983814() so that calculate_regset_size() doesn't overallocate regset space when the workaround isn't needed. (Lucas) - On platforms affected by Wa_1607983814, only add the LNCF MOCS registers to the render engine's GuC save/restore list; resets of other engines don't need to save/restore these. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Philippe Lecluse authored
It was incorrectly using dg2_mocs for now. v2 (MattR): - Use REG_GENMASK/REG_FIELD_PREP for bitfields - Add bspec references Bspec: 45101, 45410, 63882 Signed-off-by:
Philippe Lecluse <philippe.lecluse@intel.com> Signed-off-by:
-
Matt Roper authored
The DG1 branch needlessly assigns uc_index twice. Drop the second instance. Signed-off-by:
-
Matt Roper authored
The values in the xe_mocs_info_index enum only match old pre-gen12 hardware not supported by the Xe driver. The only usage of this enum was to set a default value for info->unused_entries_index, but this is unnecessary since every platform in the subsequent switch statement sets a proper platform-specific value (and the XE_MOCS_PTE default doesn't even make sense since the hardware dropped the "use PAT settings" capability in gen12). v2: - Add a check that unusued_entries_index is non-zero; even for platforms where this is a valid table entry, it's never the one we want this value assigned to. (Lucas) Signed-off-by:
-
Matt Roper authored
RKL should use the same "gen12" MOCS handling as TGL/ADL-S/ADL-P. Bspec: 45101 Signed-off-by:
-
Matt Roper authored
TGL/RKL/ADLS/ADLP are all supposed to use the same MOCS table, with values defined in the bspec. Any entries listed in the bspec as reserved/error/undefined should always be initialized to the most cached and least coherent setting possible so that any userspace accidentally referencing those undefined entries will only experience an increase in coherency if spec updates down the road start defining real values. The TGL and gen12 table entries defined in the driver today are identical except that the TGL includes one additional (incorrect) setting for table index 1. Furthermore, the TGL-specific initialization does not define a dedicated value for info->unused_entries_index, so this incorrect table entry 1 also gets used to populate the MOCS registers for all reserved/unused table entries. This incorrect behavior is a holdover from i915 where the platform was enabled with an incorrect setting and by the time we noticed, it was too late to fix the table without breaking ABI compatibility (and on TGL we did indeed have some buggy userspace that was referencing the 'reserved' entry 1). Since the Xe driver starts fresh with a clean slate on ABI, there's no need to repeat the mistakes of i915 here. v2: - Reword/clarify commit message. (Lucas) Bspec: 45101 Signed-off-by:
-
Lucas De Marchi authored
Reduce the use of i915_reg_defs.h so it can be encapsulated in a single place. 1) If it was being included by mistake, remove 2) If it was included for FIELD_GET()/FIELD_PREP()/GENMASK() and the like, just include <linux/bitfield.h> 3) If it was included to be able to define additional registers, move the registers to the relavant headers (regs/xe_regs.h or regs/xe_gt_regs.h) v2: - Squash commit fixing i915_reg_defs.h include and with the one introducing regs/xe_reg_defs.h - Remove more cases of i915_reg_defs.h being used when all it was needed was linux/bitfield.h (Matt Roper) - Move some registers to the corresponding regs/*.h file (Matt Roper) Signed-off-by: -
Lucas De Marchi authored
Keep header guards consistent with regard to ifdef used. Prefer the more commonly used in the driver. $ git grep "ifndef __XE_" -- drivers/gpu/drm/xe | wc -l 8 $ git grep "ifndef _XE_" -- drivers/gpu/drm/xe | wc -l 112 Signed-off-by:
-
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 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:
-
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:
-
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:
-
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:
-
