- 19 Dec, 2023 35 commits
-
-
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 <matthew.brost@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
-
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 <matthew.auld@intel.com> Reviewed-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 <maarten.lankhorst@linux.intel.com> Reviewed-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 <jose.souza@intel.com> Reviewed-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:
-
Francois Dugast authored
This aligns with other drivers and fixes build failure when CONFIG_PM_SLEEP is not set, such as on RISC-V. Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
-
Mauro Carvalho Chehab authored
Some tests are meant to run only on real hardware. Skip those, if no device was found. Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
When adding the frequency management, Meteor Lake platform was left behind. Handling it properly now. Signed-off-by:
-
Philippe Lecluse authored
[ 117.901473] xe 0000:00:02.0: [drm] GuC load failed: status = 0x400000A0 [ 117.901506] xe 0000:00:02.0: [drm] GuC load failed: status: Reset = 0, BootROM = 0x50, UKernel = 0x00, MIA = 0x00, Auth = 0x01 Signed-off-by:
Philippe Lecluse <philippe.lecluse@intel.com> Reviewed-by:
-
Balasubramani Vivekanandan authored
At present the interrupts are enabled while initializing the last GT. But this is incorrect for a Multi-GT platform, as root GT initialization will fail with interrupt disabled. Interrupts are required for the GuC submission triggered during initialization. Enable the interrupt during the root GT initialization. Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
-
Mauro Carvalho Chehab authored
ERROR:root:../drivers/gpu/drm/xe/display/intel_fbdev.c:585:5: error: redefinition of ‘intel_fbdev_init’ 585 | int intel_fbdev_init(struct drm_device *dev) | ^~~~~~~~~~~~~~~~ In file included from ../drivers/gpu/drm/xe/display/intel_fbdev.c:55: ../drivers/gpu/drm/xe/display/intel_fbdev.h:26:19: note: previous definition of ‘intel_fbdev_init’ with type ‘int(struct drm_device *)’ 26 | static inline int intel_fbdev_init(struct drm_device *dev) | ^~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.c:626:6: error: redefinition of ‘intel_fbdev_initial_config_async’ 626 | void intel_fbdev_initial_config_async(struct drm_device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.h:31:20: note: previous definition of ‘intel_fbdev_initial_config_async’ with type ‘void(struct drm_device *)’ 31 | static inline void intel_fbdev_initial_config_async(struct drm_device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.c:646:6: error: redefinition of ‘intel_fbdev_unregister’ 646 | void intel_fbdev_unregister(struct drm_i915_private *dev_priv) | ^~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.h:35:20: note: previous definition of ‘intel_fbdev_unregister’ with type ‘void(struct xe_device *)’ 35 | static inline void intel_fbdev_unregister(struct drm_i915_private *dev_priv) | ^~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.c:661:6: error: redefinition of ‘intel_fbdev_fini’ 661 | void intel_fbdev_fini(struct drm_i915_private *dev_priv) | ^~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.h:39:20: note: previous definition of ‘intel_fbdev_fini’ with type ‘void(struct xe_device *)’ 39 | static inline void intel_fbdev_fini(struct drm_i915_private *dev_priv) | ^~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.c:692:6: error: redefinition of ‘intel_fbdev_set_suspend’ 692 | void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool synchronous) | ^~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.h:43:20: note: previous definition of ‘intel_fbdev_set_suspend’ with type ‘void(struct drm_device *, int, bool)’ {aka ‘void(struct drm_device *, int, _Bool)’} 43 | static inline void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool synchronous) | ^~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.c:751:6: error: redefinition of ‘intel_fbdev_output_poll_changed’ 751 | void intel_fbdev_output_poll_changed(struct drm_device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.h:47:20: note: previous definition of ‘intel_fbdev_output_poll_changed’ with type ‘void(struct drm_device *)’ 47 | static inline void intel_fbdev_output_poll_changed(struct drm_device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.c:770:6: error: redefinition of ‘intel_fbdev_restore_mode’ 770 | void intel_fbdev_restore_mode(struct drm_device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.h:51:20: note: previous definition of ‘intel_fbdev_restore_mode’ with type ‘void(struct drm_device *)’ 51 | static inline void intel_fbdev_restore_mode(struct drm_device *dev) | ^~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.c:785:27: error: redefinition of ‘intel_fbdev_framebuffer’ 785 | struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev *fbdev) | ^~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_fbdev.h:54:41: note: previous definition of ‘intel_fbdev_framebuffer’ with type ‘struct intel_framebuffer *(struct intel_fbdev *)’ 54 | static inline struct intel_framebuffer *intel_fbdev_framebuffer(struct intel_fbdev *fbdev) | ^~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: -
Mauro Carvalho Chehab authored
KUnit reuquires debugfs, as otherwise, it won't build: $ make ARCH=x86_64 O=.kunit --jobs=8 ERROR:root:../drivers/gpu/drm/xe/display/intel_display_debugfs.c:1612:6: error: redefinition of ‘intel_display_debugfs_register’ 1612 | void intel_display_debugfs_register(struct drm_i915_private *i915) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ../drivers/gpu/drm/xe/display/intel_display_debugfs.c:18: ../drivers/gpu/drm/xe/display/intel_display_debugfs.h:18:20: note: previous definition of ‘intel_display_debugfs_register’ with type ‘void(struct xe_device *)’ 18 | static inline void intel_display_debugfs_register(struct drm_i915_private *i915) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_display_debugfs.c:1935:6: error: redefinition of ‘intel_connector_debugfs_add’ 1935 | void intel_connector_debugfs_add(struct intel_connector *intel_connector) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_display_debugfs.h:19:20: note: previous definition of ‘intel_connector_debugfs_add’ with type ‘void(struct intel_connector *)’ 19 | static inline void intel_connector_debugfs_add(struct intel_connector *connector) {} | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_display_debugfs.c:1993:6: error: redefinition of ‘intel_crtc_debugfs_add’ 1993 | void intel_crtc_debugfs_add(struct drm_crtc *crtc) | ^~~~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/xe/display/intel_display_debugfs.h:20:20: note: previous definition of ‘intel_crtc_debugfs_add’ with type ‘void(struct drm_crtc *)’ 20 | static inline void intel_crtc_debugfs_add(struct drm_crtc *crtc) {} | ^~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: -
Lucas De Marchi authored
Some of the tests may benefit from running with ARCH=um, forgoing any additional setup on the CI build side. Add min config for that. Tested with: ./tools/testing/kunit/kunit.py build \ --kunitconfig drivers/gpu/drm/xe/.kunitconfig \ --jobs $(nproc) \ --build_dir build_kunit Signed-off-by:
-
Lucas De Marchi authored
mem_type field was added in commit d8b52a02 ("drm/xe: Implement stolen memory.") to designate the TTM memory type for that mgr. Add kernel-doc with its description. Signed-off-by:
-
- 12 Dec, 2023 5 commits
-
-
Lucas De Marchi authored
Fix the following error while building for 32b: In file included from ../drivers/gpu/drm/xe/xe_gt.c:6: ../drivers/gpu/drm/xe/xe_gt.c: In function ‘gt_ttm_mgr_init’: ../include/linux/minmax.h:20:35: error: comparison of distinct pointer types lacks a cast [-Werror] 20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1))) | ^~ Cast it to u64 so size of the second operand matches the first one when building it for 32 bits. Signed-off-by:
-
Lucas De Marchi authored
Leave the types as u64, but cast the pointers to unsigned long before assigning so the compiler doesn't throw warning about casting a pointer to integer of different size. Also, size_t should use %zu, not %ld. Signed-off-by:
-
Lucas De Marchi authored
writeq() and readq() and other functions working on 64 bit variables are not provided by 32b arch. For that it's needed to choose between linux/io-64-nonatomic-hi-lo.h and linux/io-64-nonatomic-lo-hi.h, spliting the read/write in 2 accesses. For xe driver, it doesn't matter much, so just choose one and include in xe_mmio.h. This also removes some ifdef CONFIG_64BIT we had around because of the missing 64bit functions. Signed-off-by:
-
Lucas De Marchi authored
Either use the proper format or cast up to 64b depending on the case. Signed-off-by:
-
Lucas De Marchi authored
Make sure it's 64bit value in both 32b and 64b arch. Signed-off-by:
-
