linux.git/drivers/gpu/drm/xe, branch v6.8-rc7

drm/xe/xe_trace: Add move_lacks_source detail to xe_bo_move trace

2024-02-29T11:32:15+00:00

Add move_lacks_source detail to xe_bo_move trace to make it readable
that is to check if it is migrate clear or migrate copy.

Cc: Thomas Hellström 
Signed-off-by: Priyanka Dandamudi 
Reviewed-by: Thomas Hellström 
Fixes: a09946a9a903 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace")
Signed-off-by: Thomas Hellström 
Link: https://patchwork.freedesktop.org/patch/msgid/20240221101950.1019312-1-priyanka.dandamudi@intel.com
(cherry picked from commit 8034f6b070cc3716e81b1846f8a4ca5339c3f29b)
Signed-off-by: Thomas Hellström

drm/xe: Deny unbinds if uapi ufence pending

2024-02-29T09:39:03+00:00

If user fence was provided for MAP in vm_bind_ioctl
and it has still not been signalled, deny UNMAP of said
vma with EBUSY as long as unsignalled fence exists.

This guarantees that MAP vs UNMAP sequences won't
escape under the radar if we ever want to track the
client's state wrt to completed and accessible MAPs.
By means of intercepting the ufence release signalling.

v2: find ufence with num_fences > 1 (Matt)
v3: careful on clearing vma ufence (Matt)

Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1159
Cc: Thomas Hellström 
Cc: Matthew Brost 
Cc: Joonas Lahtinen 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Matthew Brost 
Signed-off-by: Thomas Hellström 
Link: https://patchwork.freedesktop.org/patch/msgid/20240215181152.450082-3-mika.kuoppala@linux.intel.com
(cherry picked from commit 158900ade92cce5ab85a06d618eb51e6c7ffb28a)
Signed-off-by: Thomas Hellström

drm/xe: Expose user fence from xe_sync_entry

2024-02-29T09:39:02+00:00

By allowing getting reference to user fence, we can
control the lifetime outside of sync entries.

This is needed to allow vma to track the associated
user fence that was provided with bind ioctl.

v2: xe_user_fence can be kept opaque (Jani, Matt)
v3: indent fix (Matt)

Cc: Thomas Hellström 
Cc: Matthew Brost 
Cc: Jani Nikula 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Matthew Brost 
Signed-off-by: Thomas Hellström 
Link: https://patchwork.freedesktop.org/patch/msgid/20240215181152.450082-2-mika.kuoppala@linux.intel.com
(cherry picked from commit 977e5b82e0901480bc201342d39f855fc0a2ef47)
Signed-off-by: Thomas Hellström

drm/xe: Use pointers in trace events

2024-02-29T09:39:02+00:00

Commit a0df2cc858c3 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace")
inadvertently reverted commit 8d038f49c1f3 ("drm/xe: Fix cast on trace
variable"), breaking the build on 32bits.

As noted by Ville, there's no point in converting the pointers to u64
and add casts everywhere. In fact, it's better to just use %p and let
the address be hashed. Convert all the cases in xe_trace.h to use
pointers.

Cc: Ville Syrjälä 
Cc: Matt Roper 
Cc: Priyanka Dandamudi 
Cc: Oak Zeng 
Cc: Thomas Hellström 
Signed-off-by: Lucas De Marchi 
Reviewed-by: Thomas Hellström 
Link: https://patchwork.freedesktop.org/patch/msgid/20240222144125.2862546-1-lucas.demarchi@intel.com
(cherry picked from commit 7a975748d4dc0a524c99a390c6f74b7097ef8cf7)
Signed-off-by: Thomas Hellström

drm/xe/xe_bo_move: Enhance xe_bo_move trace

2024-02-29T09:39:02+00:00

Enhanced xe_bo_move trace to be more readable.
It will help to show the migration details.
Src and dst details.

v2: Modify trace_xe_bo_move(), it takes the integer mem_type
rather than a string.
Make mem_type_to_name() extern, it will be used by trace.(Thomas)

v3: Move mem_type_to_name() to xe_bo.[ch] (Thomas, Matt)

v4: Add device details to reduce ambiquity related to vram0/vram1. (Oak)

v5: Rename mem_type_to_name to xe_mem_type_to_name. (Thomas)

v6: Optimised code to use xe_bo_device(__entry->bo). (Thomas)

Cc: Thomas Hellström 
Cc: Oak Zeng 
Cc: Kempczynski Zbigniew 
Cc: Matthew Brost 
Cc: Brian Welty 
Signed-off-by: Priyanka Dandamudi 
Reviewed-by: Oak Zeng 
Reviewed-by: Thomas Hellström 
Signed-off-by: Thomas Hellström 
Link: https://patchwork.freedesktop.org/patch/msgid/20240220044748.948496-1-priyanka.dandamudi@intel.com
(cherry picked from commit a0df2cc858c309a8bc2e87b4274772587aa25e05)
Signed-off-by: Thomas Hellström

drm/xe/mmio: fix build warning for BAR resize on 32-bit

2024-02-29T09:39:02+00:00

clang complains about a nonsensical test on builds with a 32-bit phys_addr_t,
which means resizing will always fail:

drivers/gpu/drm/xe/xe_mmio.c:109:23: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
  109 |                     root_res->start > 0x100000000ull)
      |                     ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~

Previously, BAR resize was always disallowed on 32-bit kernels, but
this apparently changed recently. Since 32-bit machines can in theory
support PAE/LPAE for large address spaces, this may end up useful,
so change the driver to shut up the warning but still work when
phys_addr_t/resource_size_t is 64 bit wide.

Fixes: 9a6e6c14bfde ("drm/xe/mmio: Use non-atomic writeq/readq variant for 32b")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Lucas De Marchi 
Acked-by: Lucas De Marchi 
Link: https://patchwork.freedesktop.org/patch/msgid/20240226124736.1272949-2-arnd@kernel.org
Signed-off-by: Lucas De Marchi 
(cherry picked from commit f5d3983366c0b88ec388b3407b29c1c0862ee2b8)
Signed-off-by: Thomas Hellström

drm/xe: get rid of MAX_BINDS

2024-02-29T09:39:02+00:00

Mesa has been issuing a single bind operation per ioctl since xe.ko
changed to GPUVA due xe.ko bug #746. If I change Mesa to try again to
issue every single bind operation it can in the same ioctl, it hits
the MAX_BINDS assertion when running Vulkan conformance tests.

Test dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8
issues 960 bind operations in a single ioctl, it's the most I could
find in the conformance suite.

I don't see a reason to keep the MAX_BINDS restriction: it doesn't
seem to be preventing any specific issue. If the number is too big for
the memory allocations, then those will fail. Nothing related to
num_binds seems to be using the stack. Let's just get rid of it.

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Testcase: dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8
References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/746
Cc: Matthew Brost 
Signed-off-by: Paulo Zanoni 
Reviewed-by: Matthew Brost 
Signed-off-by: Matthew Brost 
Link: https://patchwork.freedesktop.org/patch/msgid/20240215005353.1295420-1-paulo.r.zanoni@intel.com
(cherry picked from commit ba6bbdc6eaef92998ec7f323c9e1211d344d2556)
Signed-off-by: Thomas Hellström

drm/xe: Use vmalloc for array of bind allocation in bind IOCTL

2024-02-29T09:39:02+00:00

Use vmalloc in effort to allow a user pass in a large number of binds in
an IOCTL (mesa use case). Also use array allocations rather open coding
the size calculation.

v2: Use __GFP_ACCOUNT for allocations (Thomas)

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Signed-off-by: Matthew Brost 
Reviewed-by: Thomas Hellström 
Link: https://patchwork.freedesktop.org/patch/msgid/20240226155554.103384-1-matthew.brost@intel.com
(cherry picked from commit 35ed1d2bfff7b1969e7f99f3641a83ea54f037e2)
Signed-off-by: Thomas Hellström

drm/xe: Don't support execlists in xe_gt_tlb_invalidation layer

2024-02-29T09:39:02+00:00

The xe_gt_tlb_invalidation layer implements TLB invalidations for a GuC
backend. Simply return if in execlists mode. A follow up may properly
implement the xe_gt_tlb_invalidation layer for both GuC and execlists.

Fixes: a9351846d945 ("drm/xe: Break of TLB invalidation into its own file")
Cc: Rodrigo Vivi 
Signed-off-by: Matthew Brost 
Reviewed-by: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20240222232021.3911545-4-matthew.brost@intel.com
(cherry picked from commit a9e483dda3efa5b9aae5d9eef94d2c3a878d9bea)
Signed-off-by: Thomas Hellström

drm/xe: Fix execlist splat

2024-02-29T09:39:02+00:00

Although execlist submission is not supported it should be kept in a
basic working state as it can be used for very early hardware bring up.
Fix the below splat.

WARNING: CPU: 3 PID: 11 at drivers/gpu/drm/xe/xe_execlist.c:217 execlist_run_job+0x1c2/0x220 [xe]
Modules linked in: xe drm_kunit_helpers drm_gpuvm drm_ttm_helper ttm drm_exec drm_suballoc_helper drm_buddy gpu_sched mei_pxp mei_hdcp wmi_bmof x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core video snd_pcm mei_me mei wmi fuse e1000e i2c_i801 ptp i2c_smbus pps_core intel_lpss_pci
CPU: 3 PID: 11 Comm: kworker/u16:0 Tainted: G     U             6.8.0-rc3-guc+ #1046
Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020
Workqueue: rcs0 drm_sched_run_job_work [gpu_sched]
RIP: 0010:execlist_run_job+0x1c2/0x220 [xe]
Code: 8b f8 03 00 00 4c 89 39 e9 e2 fe ff ff 49 8d 7d 20 be ff ff ff ff e8 ed fd a6 e1 85 c0 0f 85 e1 fe ff ff 0f 0b e9 da fe ff ff <0f> 0b 0f 0b 41 83 fc 03 0f 86 8a fe ff ff 0f 0b e9 83 fe ff ff be
RSP: 0018:ffffc9000013bdb8 EFLAGS: 00010246
RAX: ffff888105021a00 RBX: ffff888105078400 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffffc9000013bd14 RDI: ffffc90001609090
RBP: ffff88811e3f0040 R08: 0000000000000088 R09: 00000000ffffff81
R10: 0000000000000001 R11: ffff88810c10c000 R12: 00000000fffffffe
R13: ffff888109b72c28 R14: ffff8881050784a0 R15: ffff888105078408
FS:  0000000000000000(0000) GS:ffff88849f980000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000563459d130f8 CR3: 000000000563a001 CR4: 0000000000f70ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 
 ? __warn+0x7f/0x170
 ? execlist_run_job+0x1c2/0x220 [xe]
 ? report_bug+0x1c7/0x1d0
 ? handle_bug+0x3c/0x70
 ? exc_invalid_op+0x18/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? execlist_run_job+0x1c2/0x220 [xe]
 ? execlist_run_job+0x2c/0x220 [xe]
 drm_sched_run_job_work+0x246/0x3f0 [gpu_sched]
 ? process_one_work+0x18d/0x4e0
 process_one_work+0x1f7/0x4e0
 worker_thread+0x1da/0x3e0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xfe/0x130
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 

Fixes: 9b9529ce379a ("drm/xe: Rename engine to exec_queue")
Signed-off-by: Matthew Brost 
Reviewed-by: Rodrigo Vivi 
Link: https://patchwork.freedesktop.org/patch/msgid/20240222232021.3911545-2-matthew.brost@intel.com
(cherry picked from commit ddadc7120d4be7a40a9745924339c472c5850d14)
Signed-off-by: Thomas Hellström