* [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
@ 2026-03-17 23:21 fei.yang
2026-03-17 23:24 ` ✗ CI.checkpatch: warning for " Patchwork
` (4 more replies)
0 siblings, 5 replies; 21+ messages in thread
From: fei.yang @ 2026-03-17 23:21 UTC (permalink / raw)
To: intel-xe; +Cc: stuart.summers, matthew.brost, Fei Yang
From: Fei Yang <fei.yang@intel.com>
Hardware requires the software to poll the valid bit and make sure it's
cleared before issuing a new TLB invalidation request.
Signed-off-by: Fei Yang <fei.yang@intel.com>
---
drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
index ced58f46f846..4c2f87db3167 100644
--- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
+++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
@@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
struct xe_guc *guc = tlb_inval->private;
struct xe_gt *gt = guc_to_gt(guc);
struct xe_device *xe = guc_to_xe(guc);
+ int ret;
/*
* Returning -ECANCELED in this function is squashed at the caller and
@@ -85,11 +86,25 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe) >= 20) {
+ /* Wait 1-second for the valid bit to be cleared */
+ ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
+ 0, 1000 * USEC_PER_MSEC, NULL, false);
+ if (ret) {
+ pr_info("TLB INVAL cancelled due to uncleared valid bit\n");
+ return -ECANCELED;
+ }
xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
PVC_GUC_TLB_INV_DESC1_INVALIDATE);
xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
PVC_GUC_TLB_INV_DESC0_VALID);
} else {
+ /* Wait 1-second for the valid bit to be cleared */
+ ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE,
+ 0, 1000 * USEC_PER_MSEC, NULL, false);
+ if (ret) {
+ pr_info("TLB INVAL cancelled due to uncleared valid bit\n");
+ return -ECANCELED;
+ }
xe_mmio_write32(mmio, GUC_TLB_INV_CR,
GUC_TLB_INV_CR_INVALIDATE);
}
--
2.43.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* ✗ CI.checkpatch: warning for drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-17 23:21 [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval fei.yang
@ 2026-03-17 23:24 ` Patchwork
2026-03-17 23:25 ` ✓ CI.KUnit: success " Patchwork
` (3 subsequent siblings)
4 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2026-03-17 23:24 UTC (permalink / raw)
To: fei.yang; +Cc: intel-xe
== Series Details ==
Series: drm/xe: Wait for HW clearance before issuing the next TLB inval.
URL : https://patchwork.freedesktop.org/series/163417/
State : warning
== Summary ==
+ KERNEL=/kernel
+ git clone https://gitlab.freedesktop.org/drm/maintainer-tools mt
Cloning into 'mt'...
warning: redirecting to https://gitlab.freedesktop.org/drm/maintainer-tools.git/
+ git -C mt rev-list -n1 origin/master
1f57ba1afceae32108bd24770069f764d940a0e4
+ cd /kernel
+ git config --global --add safe.directory /kernel
+ git log -n1
commit c8107a615e011397c11a96cf80e6762cba7b88df
Author: Fei Yang <fei.yang@intel.com>
Date: Tue Mar 17 16:21:33 2026 -0700
drm/xe: Wait for HW clearance before issuing the next TLB inval.
Hardware requires the software to poll the valid bit and make sure it's
cleared before issuing a new TLB invalidation request.
Signed-off-by: Fei Yang <fei.yang@intel.com>
+ /mt/dim checkpatch c479cdf62a3f9a6101dd020abbc471f35142b3d1 drm-intel
c8107a615e01 drm/xe: Wait for HW clearance before issuing the next TLB inval.
-:29: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#29: FILE: drivers/gpu/drm/xe/xe_guc_tlb_inval.c:90:
+ ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
total: 0 errors, 1 warnings, 0 checks, 32 lines checked
^ permalink raw reply [flat|nested] 21+ messages in thread
* ✓ CI.KUnit: success for drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-17 23:21 [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval fei.yang
2026-03-17 23:24 ` ✗ CI.checkpatch: warning for " Patchwork
@ 2026-03-17 23:25 ` Patchwork
2026-03-17 23:28 ` [PATCH] " Summers, Stuart
` (2 subsequent siblings)
4 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2026-03-17 23:25 UTC (permalink / raw)
To: fei.yang; +Cc: intel-xe
== Series Details ==
Series: drm/xe: Wait for HW clearance before issuing the next TLB inval.
URL : https://patchwork.freedesktop.org/series/163417/
State : success
== Summary ==
+ trap cleanup EXIT
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/xe/.kunitconfig
[23:24:42] Configuring KUnit Kernel ...
Generating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[23:24:46] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[23:25:16] Starting KUnit Kernel (1/1)...
[23:25:16] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[23:25:17] ================== guc_buf (11 subtests) ===================
[23:25:17] [PASSED] test_smallest
[23:25:17] [PASSED] test_largest
[23:25:17] [PASSED] test_granular
[23:25:17] [PASSED] test_unique
[23:25:17] [PASSED] test_overlap
[23:25:17] [PASSED] test_reusable
[23:25:17] [PASSED] test_too_big
[23:25:17] [PASSED] test_flush
[23:25:17] [PASSED] test_lookup
[23:25:17] [PASSED] test_data
[23:25:17] [PASSED] test_class
[23:25:17] ===================== [PASSED] guc_buf =====================
[23:25:17] =================== guc_dbm (7 subtests) ===================
[23:25:17] [PASSED] test_empty
[23:25:17] [PASSED] test_default
[23:25:17] ======================== test_size ========================
[23:25:17] [PASSED] 4
[23:25:17] [PASSED] 8
[23:25:17] [PASSED] 32
[23:25:17] [PASSED] 256
[23:25:17] ==================== [PASSED] test_size ====================
[23:25:17] ======================= test_reuse ========================
[23:25:17] [PASSED] 4
[23:25:17] [PASSED] 8
[23:25:17] [PASSED] 32
[23:25:17] [PASSED] 256
[23:25:17] =================== [PASSED] test_reuse ====================
[23:25:17] =================== test_range_overlap ====================
[23:25:17] [PASSED] 4
[23:25:17] [PASSED] 8
[23:25:17] [PASSED] 32
[23:25:17] [PASSED] 256
[23:25:17] =============== [PASSED] test_range_overlap ================
[23:25:17] =================== test_range_compact ====================
[23:25:17] [PASSED] 4
[23:25:17] [PASSED] 8
[23:25:17] [PASSED] 32
[23:25:17] [PASSED] 256
[23:25:17] =============== [PASSED] test_range_compact ================
[23:25:17] ==================== test_range_spare =====================
[23:25:17] [PASSED] 4
[23:25:17] [PASSED] 8
[23:25:17] [PASSED] 32
[23:25:17] [PASSED] 256
[23:25:17] ================ [PASSED] test_range_spare =================
[23:25:17] ===================== [PASSED] guc_dbm =====================
[23:25:17] =================== guc_idm (6 subtests) ===================
[23:25:17] [PASSED] bad_init
[23:25:17] [PASSED] no_init
[23:25:17] [PASSED] init_fini
[23:25:17] [PASSED] check_used
[23:25:17] [PASSED] check_quota
[23:25:17] [PASSED] check_all
[23:25:17] ===================== [PASSED] guc_idm =====================
[23:25:17] ================== no_relay (3 subtests) ===================
[23:25:17] [PASSED] xe_drops_guc2pf_if_not_ready
[23:25:17] [PASSED] xe_drops_guc2vf_if_not_ready
[23:25:17] [PASSED] xe_rejects_send_if_not_ready
[23:25:17] ==================== [PASSED] no_relay =====================
[23:25:17] ================== pf_relay (14 subtests) ==================
[23:25:17] [PASSED] pf_rejects_guc2pf_too_short
[23:25:17] [PASSED] pf_rejects_guc2pf_too_long
[23:25:17] [PASSED] pf_rejects_guc2pf_no_payload
[23:25:17] [PASSED] pf_fails_no_payload
[23:25:17] [PASSED] pf_fails_bad_origin
[23:25:17] [PASSED] pf_fails_bad_type
[23:25:17] [PASSED] pf_txn_reports_error
[23:25:17] [PASSED] pf_txn_sends_pf2guc
[23:25:17] [PASSED] pf_sends_pf2guc
[23:25:17] [SKIPPED] pf_loopback_nop
[23:25:17] [SKIPPED] pf_loopback_echo
[23:25:17] [SKIPPED] pf_loopback_fail
[23:25:17] [SKIPPED] pf_loopback_busy
[23:25:17] [SKIPPED] pf_loopback_retry
[23:25:17] ==================== [PASSED] pf_relay =====================
[23:25:17] ================== vf_relay (3 subtests) ===================
[23:25:17] [PASSED] vf_rejects_guc2vf_too_short
[23:25:17] [PASSED] vf_rejects_guc2vf_too_long
[23:25:17] [PASSED] vf_rejects_guc2vf_no_payload
[23:25:17] ==================== [PASSED] vf_relay =====================
[23:25:17] ================ pf_gt_config (9 subtests) =================
[23:25:17] [PASSED] fair_contexts_1vf
[23:25:17] [PASSED] fair_doorbells_1vf
[23:25:17] [PASSED] fair_ggtt_1vf
[23:25:17] ====================== fair_vram_1vf ======================
[23:25:17] [PASSED] 3.50 GiB
[23:25:17] [PASSED] 11.5 GiB
[23:25:17] [PASSED] 15.5 GiB
[23:25:17] [PASSED] 31.5 GiB
[23:25:17] [PASSED] 63.5 GiB
[23:25:17] [PASSED] 1.91 GiB
[23:25:17] ================== [PASSED] fair_vram_1vf ==================
[23:25:17] ================ fair_vram_1vf_admin_only =================
[23:25:17] [PASSED] 3.50 GiB
[23:25:17] [PASSED] 11.5 GiB
[23:25:17] [PASSED] 15.5 GiB
[23:25:17] [PASSED] 31.5 GiB
[23:25:17] [PASSED] 63.5 GiB
[23:25:17] [PASSED] 1.91 GiB
[23:25:17] ============ [PASSED] fair_vram_1vf_admin_only =============
[23:25:17] ====================== fair_contexts ======================
[23:25:17] [PASSED] 1 VF
[23:25:17] [PASSED] 2 VFs
[23:25:17] [PASSED] 3 VFs
[23:25:17] [PASSED] 4 VFs
[23:25:17] [PASSED] 5 VFs
[23:25:17] [PASSED] 6 VFs
[23:25:17] [PASSED] 7 VFs
[23:25:17] [PASSED] 8 VFs
[23:25:17] [PASSED] 9 VFs
[23:25:17] [PASSED] 10 VFs
[23:25:17] [PASSED] 11 VFs
[23:25:17] [PASSED] 12 VFs
[23:25:17] [PASSED] 13 VFs
[23:25:17] [PASSED] 14 VFs
[23:25:17] [PASSED] 15 VFs
[23:25:17] [PASSED] 16 VFs
[23:25:17] [PASSED] 17 VFs
[23:25:17] [PASSED] 18 VFs
[23:25:17] [PASSED] 19 VFs
[23:25:17] [PASSED] 20 VFs
[23:25:17] [PASSED] 21 VFs
[23:25:17] [PASSED] 22 VFs
[23:25:17] [PASSED] 23 VFs
[23:25:17] [PASSED] 24 VFs
[23:25:17] [PASSED] 25 VFs
[23:25:17] [PASSED] 26 VFs
[23:25:17] [PASSED] 27 VFs
[23:25:17] [PASSED] 28 VFs
[23:25:17] [PASSED] 29 VFs
[23:25:17] [PASSED] 30 VFs
[23:25:17] [PASSED] 31 VFs
[23:25:17] [PASSED] 32 VFs
[23:25:17] [PASSED] 33 VFs
[23:25:17] [PASSED] 34 VFs
[23:25:17] [PASSED] 35 VFs
[23:25:17] [PASSED] 36 VFs
[23:25:17] [PASSED] 37 VFs
[23:25:17] [PASSED] 38 VFs
[23:25:17] [PASSED] 39 VFs
[23:25:17] [PASSED] 40 VFs
[23:25:17] [PASSED] 41 VFs
[23:25:17] [PASSED] 42 VFs
[23:25:17] [PASSED] 43 VFs
[23:25:17] [PASSED] 44 VFs
[23:25:17] [PASSED] 45 VFs
[23:25:17] [PASSED] 46 VFs
[23:25:17] [PASSED] 47 VFs
[23:25:17] [PASSED] 48 VFs
[23:25:17] [PASSED] 49 VFs
[23:25:17] [PASSED] 50 VFs
[23:25:17] [PASSED] 51 VFs
[23:25:17] [PASSED] 52 VFs
[23:25:17] [PASSED] 53 VFs
[23:25:17] [PASSED] 54 VFs
[23:25:17] [PASSED] 55 VFs
[23:25:17] [PASSED] 56 VFs
[23:25:17] [PASSED] 57 VFs
[23:25:17] [PASSED] 58 VFs
[23:25:17] [PASSED] 59 VFs
[23:25:17] [PASSED] 60 VFs
[23:25:17] [PASSED] 61 VFs
[23:25:17] [PASSED] 62 VFs
[23:25:17] [PASSED] 63 VFs
[23:25:17] ================== [PASSED] fair_contexts ==================
[23:25:17] ===================== fair_doorbells ======================
[23:25:17] [PASSED] 1 VF
[23:25:17] [PASSED] 2 VFs
[23:25:17] [PASSED] 3 VFs
[23:25:17] [PASSED] 4 VFs
[23:25:17] [PASSED] 5 VFs
[23:25:17] [PASSED] 6 VFs
[23:25:17] [PASSED] 7 VFs
[23:25:17] [PASSED] 8 VFs
[23:25:17] [PASSED] 9 VFs
[23:25:17] [PASSED] 10 VFs
[23:25:17] [PASSED] 11 VFs
[23:25:17] [PASSED] 12 VFs
[23:25:17] [PASSED] 13 VFs
[23:25:17] [PASSED] 14 VFs
[23:25:17] [PASSED] 15 VFs
[23:25:17] [PASSED] 16 VFs
[23:25:17] [PASSED] 17 VFs
[23:25:17] [PASSED] 18 VFs
[23:25:17] [PASSED] 19 VFs
[23:25:17] [PASSED] 20 VFs
[23:25:17] [PASSED] 21 VFs
[23:25:17] [PASSED] 22 VFs
[23:25:17] [PASSED] 23 VFs
[23:25:17] [PASSED] 24 VFs
[23:25:17] [PASSED] 25 VFs
[23:25:17] [PASSED] 26 VFs
[23:25:17] [PASSED] 27 VFs
[23:25:17] [PASSED] 28 VFs
[23:25:17] [PASSED] 29 VFs
[23:25:17] [PASSED] 30 VFs
[23:25:17] [PASSED] 31 VFs
[23:25:17] [PASSED] 32 VFs
[23:25:17] [PASSED] 33 VFs
[23:25:17] [PASSED] 34 VFs
[23:25:17] [PASSED] 35 VFs
[23:25:17] [PASSED] 36 VFs
[23:25:17] [PASSED] 37 VFs
[23:25:17] [PASSED] 38 VFs
[23:25:17] [PASSED] 39 VFs
[23:25:17] [PASSED] 40 VFs
[23:25:17] [PASSED] 41 VFs
[23:25:17] [PASSED] 42 VFs
[23:25:17] [PASSED] 43 VFs
[23:25:17] [PASSED] 44 VFs
[23:25:17] [PASSED] 45 VFs
[23:25:17] [PASSED] 46 VFs
[23:25:17] [PASSED] 47 VFs
[23:25:17] [PASSED] 48 VFs
[23:25:17] [PASSED] 49 VFs
[23:25:17] [PASSED] 50 VFs
[23:25:17] [PASSED] 51 VFs
[23:25:17] [PASSED] 52 VFs
[23:25:17] [PASSED] 53 VFs
[23:25:17] [PASSED] 54 VFs
[23:25:17] [PASSED] 55 VFs
[23:25:17] [PASSED] 56 VFs
[23:25:17] [PASSED] 57 VFs
[23:25:17] [PASSED] 58 VFs
[23:25:17] [PASSED] 59 VFs
[23:25:17] [PASSED] 60 VFs
[23:25:17] [PASSED] 61 VFs
[23:25:17] [PASSED] 62 VFs
[23:25:17] [PASSED] 63 VFs
[23:25:17] ================= [PASSED] fair_doorbells ==================
[23:25:17] ======================== fair_ggtt ========================
[23:25:17] [PASSED] 1 VF
[23:25:17] [PASSED] 2 VFs
[23:25:17] [PASSED] 3 VFs
[23:25:17] [PASSED] 4 VFs
[23:25:17] [PASSED] 5 VFs
[23:25:17] [PASSED] 6 VFs
[23:25:17] [PASSED] 7 VFs
[23:25:17] [PASSED] 8 VFs
[23:25:17] [PASSED] 9 VFs
[23:25:17] [PASSED] 10 VFs
[23:25:17] [PASSED] 11 VFs
[23:25:17] [PASSED] 12 VFs
[23:25:17] [PASSED] 13 VFs
[23:25:17] [PASSED] 14 VFs
[23:25:17] [PASSED] 15 VFs
[23:25:17] [PASSED] 16 VFs
[23:25:17] [PASSED] 17 VFs
[23:25:17] [PASSED] 18 VFs
[23:25:17] [PASSED] 19 VFs
[23:25:17] [PASSED] 20 VFs
[23:25:17] [PASSED] 21 VFs
[23:25:17] [PASSED] 22 VFs
[23:25:17] [PASSED] 23 VFs
[23:25:17] [PASSED] 24 VFs
[23:25:17] [PASSED] 25 VFs
[23:25:17] [PASSED] 26 VFs
[23:25:17] [PASSED] 27 VFs
[23:25:17] [PASSED] 28 VFs
[23:25:17] [PASSED] 29 VFs
[23:25:17] [PASSED] 30 VFs
[23:25:17] [PASSED] 31 VFs
[23:25:17] [PASSED] 32 VFs
[23:25:17] [PASSED] 33 VFs
[23:25:17] [PASSED] 34 VFs
[23:25:17] [PASSED] 35 VFs
[23:25:17] [PASSED] 36 VFs
[23:25:17] [PASSED] 37 VFs
[23:25:17] [PASSED] 38 VFs
[23:25:17] [PASSED] 39 VFs
[23:25:17] [PASSED] 40 VFs
[23:25:17] [PASSED] 41 VFs
[23:25:17] [PASSED] 42 VFs
[23:25:17] [PASSED] 43 VFs
[23:25:17] [PASSED] 44 VFs
[23:25:17] [PASSED] 45 VFs
[23:25:17] [PASSED] 46 VFs
[23:25:17] [PASSED] 47 VFs
[23:25:17] [PASSED] 48 VFs
[23:25:17] [PASSED] 49 VFs
[23:25:17] [PASSED] 50 VFs
[23:25:17] [PASSED] 51 VFs
[23:25:17] [PASSED] 52 VFs
[23:25:17] [PASSED] 53 VFs
[23:25:17] [PASSED] 54 VFs
[23:25:17] [PASSED] 55 VFs
[23:25:17] [PASSED] 56 VFs
[23:25:17] [PASSED] 57 VFs
[23:25:17] [PASSED] 58 VFs
[23:25:17] [PASSED] 59 VFs
[23:25:17] [PASSED] 60 VFs
[23:25:17] [PASSED] 61 VFs
[23:25:17] [PASSED] 62 VFs
[23:25:17] [PASSED] 63 VFs
[23:25:17] ==================== [PASSED] fair_ggtt ====================
[23:25:17] ======================== fair_vram ========================
[23:25:17] [PASSED] 1 VF
[23:25:17] [PASSED] 2 VFs
[23:25:17] [PASSED] 3 VFs
[23:25:17] [PASSED] 4 VFs
[23:25:17] [PASSED] 5 VFs
[23:25:17] [PASSED] 6 VFs
[23:25:17] [PASSED] 7 VFs
[23:25:17] [PASSED] 8 VFs
[23:25:17] [PASSED] 9 VFs
[23:25:17] [PASSED] 10 VFs
[23:25:17] [PASSED] 11 VFs
[23:25:17] [PASSED] 12 VFs
[23:25:17] [PASSED] 13 VFs
[23:25:17] [PASSED] 14 VFs
[23:25:17] [PASSED] 15 VFs
[23:25:17] [PASSED] 16 VFs
[23:25:17] [PASSED] 17 VFs
[23:25:17] [PASSED] 18 VFs
[23:25:17] [PASSED] 19 VFs
[23:25:17] [PASSED] 20 VFs
[23:25:17] [PASSED] 21 VFs
[23:25:17] [PASSED] 22 VFs
[23:25:17] [PASSED] 23 VFs
[23:25:17] [PASSED] 24 VFs
[23:25:17] [PASSED] 25 VFs
[23:25:17] [PASSED] 26 VFs
[23:25:17] [PASSED] 27 VFs
[23:25:17] [PASSED] 28 VFs
[23:25:17] [PASSED] 29 VFs
[23:25:17] [PASSED] 30 VFs
[23:25:17] [PASSED] 31 VFs
[23:25:17] [PASSED] 32 VFs
[23:25:17] [PASSED] 33 VFs
[23:25:17] [PASSED] 34 VFs
[23:25:17] [PASSED] 35 VFs
[23:25:17] [PASSED] 36 VFs
[23:25:17] [PASSED] 37 VFs
[23:25:17] [PASSED] 38 VFs
[23:25:17] [PASSED] 39 VFs
[23:25:17] [PASSED] 40 VFs
[23:25:17] [PASSED] 41 VFs
[23:25:17] [PASSED] 42 VFs
[23:25:17] [PASSED] 43 VFs
[23:25:17] [PASSED] 44 VFs
[23:25:17] [PASSED] 45 VFs
[23:25:17] [PASSED] 46 VFs
[23:25:17] [PASSED] 47 VFs
[23:25:17] [PASSED] 48 VFs
[23:25:17] [PASSED] 49 VFs
[23:25:17] [PASSED] 50 VFs
[23:25:17] [PASSED] 51 VFs
[23:25:17] [PASSED] 52 VFs
[23:25:17] [PASSED] 53 VFs
[23:25:17] [PASSED] 54 VFs
[23:25:17] [PASSED] 55 VFs
[23:25:17] [PASSED] 56 VFs
[23:25:17] [PASSED] 57 VFs
[23:25:17] [PASSED] 58 VFs
[23:25:17] [PASSED] 59 VFs
[23:25:17] [PASSED] 60 VFs
[23:25:17] [PASSED] 61 VFs
[23:25:17] [PASSED] 62 VFs
[23:25:17] [PASSED] 63 VFs
[23:25:17] ==================== [PASSED] fair_vram ====================
[23:25:17] ================== [PASSED] pf_gt_config ===================
[23:25:17] ===================== lmtt (1 subtest) =====================
[23:25:17] ======================== test_ops =========================
[23:25:17] [PASSED] 2-level
[23:25:17] [PASSED] multi-level
[23:25:17] ==================== [PASSED] test_ops =====================
[23:25:17] ====================== [PASSED] lmtt =======================
[23:25:17] ================= pf_service (11 subtests) =================
[23:25:17] [PASSED] pf_negotiate_any
[23:25:17] [PASSED] pf_negotiate_base_match
[23:25:17] [PASSED] pf_negotiate_base_newer
[23:25:17] [PASSED] pf_negotiate_base_next
[23:25:17] [SKIPPED] pf_negotiate_base_older
[23:25:17] [PASSED] pf_negotiate_base_prev
[23:25:17] [PASSED] pf_negotiate_latest_match
[23:25:17] [PASSED] pf_negotiate_latest_newer
[23:25:17] [PASSED] pf_negotiate_latest_next
[23:25:17] [SKIPPED] pf_negotiate_latest_older
[23:25:17] [SKIPPED] pf_negotiate_latest_prev
[23:25:17] =================== [PASSED] pf_service ====================
[23:25:17] ================= xe_guc_g2g (2 subtests) ==================
[23:25:17] ============== xe_live_guc_g2g_kunit_default ==============
[23:25:17] ========= [SKIPPED] xe_live_guc_g2g_kunit_default ==========
[23:25:17] ============== xe_live_guc_g2g_kunit_allmem ===============
[23:25:17] ========== [SKIPPED] xe_live_guc_g2g_kunit_allmem ==========
[23:25:17] =================== [SKIPPED] xe_guc_g2g ===================
[23:25:17] =================== xe_mocs (2 subtests) ===================
[23:25:17] ================ xe_live_mocs_kernel_kunit ================
[23:25:17] =========== [SKIPPED] xe_live_mocs_kernel_kunit ============
[23:25:17] ================ xe_live_mocs_reset_kunit =================
[23:25:17] ============ [SKIPPED] xe_live_mocs_reset_kunit ============
[23:25:17] ==================== [SKIPPED] xe_mocs =====================
[23:25:17] ================= xe_migrate (2 subtests) ==================
[23:25:17] ================= xe_migrate_sanity_kunit =================
[23:25:17] ============ [SKIPPED] xe_migrate_sanity_kunit =============
[23:25:17] ================== xe_validate_ccs_kunit ==================
[23:25:17] ============= [SKIPPED] xe_validate_ccs_kunit ==============
[23:25:17] =================== [SKIPPED] xe_migrate ===================
[23:25:17] ================== xe_dma_buf (1 subtest) ==================
[23:25:17] ==================== xe_dma_buf_kunit =====================
[23:25:17] ================ [SKIPPED] xe_dma_buf_kunit ================
[23:25:17] =================== [SKIPPED] xe_dma_buf ===================
[23:25:17] ================= xe_bo_shrink (1 subtest) =================
[23:25:17] =================== xe_bo_shrink_kunit ====================
[23:25:17] =============== [SKIPPED] xe_bo_shrink_kunit ===============
[23:25:17] ================== [SKIPPED] xe_bo_shrink ==================
[23:25:17] ==================== xe_bo (2 subtests) ====================
[23:25:17] ================== xe_ccs_migrate_kunit ===================
[23:25:17] ============== [SKIPPED] xe_ccs_migrate_kunit ==============
[23:25:17] ==================== xe_bo_evict_kunit ====================
[23:25:17] =============== [SKIPPED] xe_bo_evict_kunit ================
[23:25:17] ===================== [SKIPPED] xe_bo ======================
[23:25:17] ==================== args (13 subtests) ====================
[23:25:17] [PASSED] count_args_test
[23:25:17] [PASSED] call_args_example
[23:25:17] [PASSED] call_args_test
[23:25:17] [PASSED] drop_first_arg_example
[23:25:17] [PASSED] drop_first_arg_test
[23:25:17] [PASSED] first_arg_example
[23:25:17] [PASSED] first_arg_test
[23:25:17] [PASSED] last_arg_example
[23:25:17] [PASSED] last_arg_test
[23:25:17] [PASSED] pick_arg_example
[23:25:17] [PASSED] if_args_example
[23:25:17] [PASSED] if_args_test
[23:25:17] [PASSED] sep_comma_example
[23:25:17] ====================== [PASSED] args =======================
[23:25:17] =================== xe_pci (3 subtests) ====================
[23:25:17] ==================== check_graphics_ip ====================
[23:25:17] [PASSED] 12.00 Xe_LP
[23:25:17] [PASSED] 12.10 Xe_LP+
[23:25:17] [PASSED] 12.55 Xe_HPG
[23:25:17] [PASSED] 12.60 Xe_HPC
[23:25:17] [PASSED] 12.70 Xe_LPG
[23:25:17] [PASSED] 12.71 Xe_LPG
[23:25:17] [PASSED] 12.74 Xe_LPG+
[23:25:17] [PASSED] 20.01 Xe2_HPG
[23:25:17] [PASSED] 20.02 Xe2_HPG
[23:25:17] [PASSED] 20.04 Xe2_LPG
[23:25:17] [PASSED] 30.00 Xe3_LPG
[23:25:17] [PASSED] 30.01 Xe3_LPG
[23:25:17] [PASSED] 30.03 Xe3_LPG
[23:25:17] [PASSED] 30.04 Xe3_LPG
[23:25:17] [PASSED] 30.05 Xe3_LPG
[23:25:17] [PASSED] 35.10 Xe3p_LPG
[23:25:17] [PASSED] 35.11 Xe3p_XPC
[23:25:17] ================ [PASSED] check_graphics_ip ================
[23:25:17] ===================== check_media_ip ======================
[23:25:17] [PASSED] 12.00 Xe_M
[23:25:17] [PASSED] 12.55 Xe_HPM
[23:25:17] [PASSED] 13.00 Xe_LPM+
[23:25:17] [PASSED] 13.01 Xe2_HPM
[23:25:17] [PASSED] 20.00 Xe2_LPM
[23:25:17] [PASSED] 30.00 Xe3_LPM
[23:25:17] [PASSED] 30.02 Xe3_LPM
[23:25:17] [PASSED] 35.00 Xe3p_LPM
[23:25:17] [PASSED] 35.03 Xe3p_HPM
[23:25:17] ================= [PASSED] check_media_ip ==================
[23:25:17] =================== check_platform_desc ===================
[23:25:17] [PASSED] 0x9A60 (TIGERLAKE)
[23:25:17] [PASSED] 0x9A68 (TIGERLAKE)
[23:25:17] [PASSED] 0x9A70 (TIGERLAKE)
[23:25:17] [PASSED] 0x9A40 (TIGERLAKE)
[23:25:17] [PASSED] 0x9A49 (TIGERLAKE)
[23:25:17] [PASSED] 0x9A59 (TIGERLAKE)
[23:25:17] [PASSED] 0x9A78 (TIGERLAKE)
[23:25:17] [PASSED] 0x9AC0 (TIGERLAKE)
[23:25:17] [PASSED] 0x9AC9 (TIGERLAKE)
[23:25:17] [PASSED] 0x9AD9 (TIGERLAKE)
[23:25:17] [PASSED] 0x9AF8 (TIGERLAKE)
[23:25:17] [PASSED] 0x4C80 (ROCKETLAKE)
[23:25:17] [PASSED] 0x4C8A (ROCKETLAKE)
[23:25:17] [PASSED] 0x4C8B (ROCKETLAKE)
[23:25:17] [PASSED] 0x4C8C (ROCKETLAKE)
[23:25:17] [PASSED] 0x4C90 (ROCKETLAKE)
[23:25:17] [PASSED] 0x4C9A (ROCKETLAKE)
[23:25:17] [PASSED] 0x4680 (ALDERLAKE_S)
[23:25:17] [PASSED] 0x4682 (ALDERLAKE_S)
[23:25:17] [PASSED] 0x4688 (ALDERLAKE_S)
[23:25:17] [PASSED] 0x468A (ALDERLAKE_S)
[23:25:17] [PASSED] 0x468B (ALDERLAKE_S)
[23:25:17] [PASSED] 0x4690 (ALDERLAKE_S)
[23:25:17] [PASSED] 0x4692 (ALDERLAKE_S)
[23:25:17] [PASSED] 0x4693 (ALDERLAKE_S)
[23:25:17] [PASSED] 0x46A0 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46A1 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46A2 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46A3 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46A6 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46A8 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46AA (ALDERLAKE_P)
[23:25:17] [PASSED] 0x462A (ALDERLAKE_P)
[23:25:17] [PASSED] 0x4626 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x4628 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46B0 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46B1 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46B2 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46B3 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46C0 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46C1 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46C2 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46C3 (ALDERLAKE_P)
[23:25:17] [PASSED] 0x46D0 (ALDERLAKE_N)
[23:25:17] [PASSED] 0x46D1 (ALDERLAKE_N)
[23:25:17] [PASSED] 0x46D2 (ALDERLAKE_N)
[23:25:17] [PASSED] 0x46D3 (ALDERLAKE_N)
[23:25:17] [PASSED] 0x46D4 (ALDERLAKE_N)
[23:25:17] [PASSED] 0xA721 (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7A1 (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7A9 (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7AC (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7AD (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA720 (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7A0 (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7A8 (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7AA (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA7AB (ALDERLAKE_P)
[23:25:17] [PASSED] 0xA780 (ALDERLAKE_S)
[23:25:17] [PASSED] 0xA781 (ALDERLAKE_S)
[23:25:17] [PASSED] 0xA782 (ALDERLAKE_S)
[23:25:17] [PASSED] 0xA783 (ALDERLAKE_S)
[23:25:17] [PASSED] 0xA788 (ALDERLAKE_S)
[23:25:17] [PASSED] 0xA789 (ALDERLAKE_S)
[23:25:17] [PASSED] 0xA78A (ALDERLAKE_S)
[23:25:17] [PASSED] 0xA78B (ALDERLAKE_S)
[23:25:17] [PASSED] 0x4905 (DG1)
[23:25:17] [PASSED] 0x4906 (DG1)
[23:25:17] [PASSED] 0x4907 (DG1)
[23:25:17] [PASSED] 0x4908 (DG1)
[23:25:17] [PASSED] 0x4909 (DG1)
[23:25:17] [PASSED] 0x56C0 (DG2)
[23:25:17] [PASSED] 0x56C2 (DG2)
[23:25:17] [PASSED] 0x56C1 (DG2)
[23:25:17] [PASSED] 0x7D51 (METEORLAKE)
[23:25:17] [PASSED] 0x7DD1 (METEORLAKE)
[23:25:17] [PASSED] 0x7D41 (METEORLAKE)
[23:25:17] [PASSED] 0x7D67 (METEORLAKE)
[23:25:17] [PASSED] 0xB640 (METEORLAKE)
[23:25:17] [PASSED] 0x56A0 (DG2)
[23:25:17] [PASSED] 0x56A1 (DG2)
[23:25:17] [PASSED] 0x56A2 (DG2)
[23:25:17] [PASSED] 0x56BE (DG2)
[23:25:17] [PASSED] 0x56BF (DG2)
[23:25:17] [PASSED] 0x5690 (DG2)
[23:25:17] [PASSED] 0x5691 (DG2)
[23:25:17] [PASSED] 0x5692 (DG2)
[23:25:17] [PASSED] 0x56A5 (DG2)
[23:25:17] [PASSED] 0x56A6 (DG2)
[23:25:17] [PASSED] 0x56B0 (DG2)
[23:25:17] [PASSED] 0x56B1 (DG2)
[23:25:17] [PASSED] 0x56BA (DG2)
[23:25:17] [PASSED] 0x56BB (DG2)
[23:25:17] [PASSED] 0x56BC (DG2)
[23:25:17] [PASSED] 0x56BD (DG2)
[23:25:17] [PASSED] 0x5693 (DG2)
[23:25:17] [PASSED] 0x5694 (DG2)
[23:25:17] [PASSED] 0x5695 (DG2)
[23:25:17] [PASSED] 0x56A3 (DG2)
[23:25:17] [PASSED] 0x56A4 (DG2)
[23:25:17] [PASSED] 0x56B2 (DG2)
[23:25:17] [PASSED] 0x56B3 (DG2)
[23:25:17] [PASSED] 0x5696 (DG2)
[23:25:17] [PASSED] 0x5697 (DG2)
[23:25:17] [PASSED] 0xB69 (PVC)
[23:25:17] [PASSED] 0xB6E (PVC)
[23:25:17] [PASSED] 0xBD4 (PVC)
[23:25:17] [PASSED] 0xBD5 (PVC)
[23:25:17] [PASSED] 0xBD6 (PVC)
[23:25:17] [PASSED] 0xBD7 (PVC)
[23:25:17] [PASSED] 0xBD8 (PVC)
[23:25:17] [PASSED] 0xBD9 (PVC)
[23:25:17] [PASSED] 0xBDA (PVC)
[23:25:17] [PASSED] 0xBDB (PVC)
[23:25:17] [PASSED] 0xBE0 (PVC)
[23:25:17] [PASSED] 0xBE1 (PVC)
[23:25:17] [PASSED] 0xBE5 (PVC)
[23:25:17] [PASSED] 0x7D40 (METEORLAKE)
[23:25:17] [PASSED] 0x7D45 (METEORLAKE)
[23:25:17] [PASSED] 0x7D55 (METEORLAKE)
[23:25:17] [PASSED] 0x7D60 (METEORLAKE)
[23:25:17] [PASSED] 0x7DD5 (METEORLAKE)
[23:25:17] [PASSED] 0x6420 (LUNARLAKE)
[23:25:17] [PASSED] 0x64A0 (LUNARLAKE)
[23:25:17] [PASSED] 0x64B0 (LUNARLAKE)
[23:25:17] [PASSED] 0xE202 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE209 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE20B (BATTLEMAGE)
[23:25:17] [PASSED] 0xE20C (BATTLEMAGE)
[23:25:17] [PASSED] 0xE20D (BATTLEMAGE)
[23:25:17] [PASSED] 0xE210 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE211 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE212 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE216 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE220 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE221 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE222 (BATTLEMAGE)
[23:25:17] [PASSED] 0xE223 (BATTLEMAGE)
[23:25:17] [PASSED] 0xB080 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB081 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB082 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB083 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB084 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB085 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB086 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB087 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB08F (PANTHERLAKE)
[23:25:17] [PASSED] 0xB090 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB0A0 (PANTHERLAKE)
[23:25:17] [PASSED] 0xB0B0 (PANTHERLAKE)
[23:25:17] [PASSED] 0xFD80 (PANTHERLAKE)
[23:25:17] [PASSED] 0xFD81 (PANTHERLAKE)
[23:25:17] [PASSED] 0xD740 (NOVALAKE_S)
[23:25:17] [PASSED] 0xD741 (NOVALAKE_S)
[23:25:17] [PASSED] 0xD742 (NOVALAKE_S)
[23:25:17] [PASSED] 0xD743 (NOVALAKE_S)
[23:25:17] [PASSED] 0xD744 (NOVALAKE_S)
[23:25:17] [PASSED] 0xD745 (NOVALAKE_S)
[23:25:17] [PASSED] 0x674C (CRESCENTISLAND)
[23:25:17] [PASSED] 0xD750 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD751 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD752 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD753 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD754 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD755 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD756 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD757 (NOVALAKE_P)
[23:25:17] [PASSED] 0xD75F (NOVALAKE_P)
[23:25:17] =============== [PASSED] check_platform_desc ===============
[23:25:17] ===================== [PASSED] xe_pci ======================
[23:25:17] =================== xe_rtp (2 subtests) ====================
[23:25:17] =============== xe_rtp_process_to_sr_tests ================
[23:25:17] [PASSED] coalesce-same-reg
[23:25:17] [PASSED] no-match-no-add
[23:25:17] [PASSED] match-or
[23:25:17] [PASSED] match-or-xfail
[23:25:17] [PASSED] no-match-no-add-multiple-rules
[23:25:17] [PASSED] two-regs-two-entries
[23:25:17] [PASSED] clr-one-set-other
[23:25:17] [PASSED] set-field
[23:25:17] [PASSED] conflict-duplicate
stty: 'standard input': Inappropriate ioctl for device
[23:25:17] [PASSED] conflict-not-disjoint
[23:25:17] [PASSED] conflict-reg-type
[23:25:17] =========== [PASSED] xe_rtp_process_to_sr_tests ============
[23:25:17] ================== xe_rtp_process_tests ===================
[23:25:17] [PASSED] active1
[23:25:17] [PASSED] active2
[23:25:17] [PASSED] active-inactive
[23:25:17] [PASSED] inactive-active
[23:25:17] [PASSED] inactive-1st_or_active-inactive
[23:25:17] [PASSED] inactive-2nd_or_active-inactive
[23:25:17] [PASSED] inactive-last_or_active-inactive
[23:25:17] [PASSED] inactive-no_or_active-inactive
[23:25:17] ============== [PASSED] xe_rtp_process_tests ===============
[23:25:17] ===================== [PASSED] xe_rtp ======================
[23:25:17] ==================== xe_wa (1 subtest) =====================
[23:25:17] ======================== xe_wa_gt =========================
[23:25:17] [PASSED] TIGERLAKE B0
[23:25:17] [PASSED] DG1 A0
[23:25:17] [PASSED] DG1 B0
[23:25:17] [PASSED] ALDERLAKE_S A0
[23:25:17] [PASSED] ALDERLAKE_S B0
[23:25:17] [PASSED] ALDERLAKE_S C0
[23:25:17] [PASSED] ALDERLAKE_S D0
[23:25:17] [PASSED] ALDERLAKE_P A0
[23:25:17] [PASSED] ALDERLAKE_P B0
[23:25:17] [PASSED] ALDERLAKE_P C0
[23:25:17] [PASSED] ALDERLAKE_S RPLS D0
[23:25:17] [PASSED] ALDERLAKE_P RPLU E0
[23:25:17] [PASSED] DG2 G10 C0
[23:25:17] [PASSED] DG2 G11 B1
[23:25:17] [PASSED] DG2 G12 A1
[23:25:17] [PASSED] METEORLAKE 12.70(Xe_LPG) A0 13.00(Xe_LPM+) A0
[23:25:17] [PASSED] METEORLAKE 12.71(Xe_LPG) A0 13.00(Xe_LPM+) A0
[23:25:17] [PASSED] METEORLAKE 12.74(Xe_LPG+) A0 13.00(Xe_LPM+) A0
[23:25:17] [PASSED] LUNARLAKE 20.04(Xe2_LPG) A0 20.00(Xe2_LPM) A0
[23:25:17] [PASSED] LUNARLAKE 20.04(Xe2_LPG) B0 20.00(Xe2_LPM) A0
[23:25:17] [PASSED] BATTLEMAGE 20.01(Xe2_HPG) A0 13.01(Xe2_HPM) A1
[23:25:17] [PASSED] PANTHERLAKE 30.00(Xe3_LPG) A0 30.00(Xe3_LPM) A0
[23:25:17] ==================== [PASSED] xe_wa_gt =====================
[23:25:17] ====================== [PASSED] xe_wa ======================
[23:25:17] ============================================================
[23:25:17] Testing complete. Ran 597 tests: passed: 579, skipped: 18
[23:25:17] Elapsed time: 35.493s total, 4.266s configuring, 30.559s building, 0.620s running
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/tests/.kunitconfig
[23:25:17] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[23:25:19] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[23:25:43] Starting KUnit Kernel (1/1)...
[23:25:43] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[23:25:43] ============ drm_test_pick_cmdline (2 subtests) ============
[23:25:43] [PASSED] drm_test_pick_cmdline_res_1920_1080_60
[23:25:43] =============== drm_test_pick_cmdline_named ===============
[23:25:43] [PASSED] NTSC
[23:25:43] [PASSED] NTSC-J
[23:25:43] [PASSED] PAL
[23:25:43] [PASSED] PAL-M
[23:25:43] =========== [PASSED] drm_test_pick_cmdline_named ===========
[23:25:43] ============== [PASSED] drm_test_pick_cmdline ==============
[23:25:43] == drm_test_atomic_get_connector_for_encoder (1 subtest) ===
[23:25:43] [PASSED] drm_test_drm_atomic_get_connector_for_encoder
[23:25:43] ==== [PASSED] drm_test_atomic_get_connector_for_encoder ====
[23:25:43] =========== drm_validate_clone_mode (2 subtests) ===========
[23:25:43] ============== drm_test_check_in_clone_mode ===============
[23:25:43] [PASSED] in_clone_mode
[23:25:43] [PASSED] not_in_clone_mode
[23:25:43] ========== [PASSED] drm_test_check_in_clone_mode ===========
[23:25:43] =============== drm_test_check_valid_clones ===============
[23:25:43] [PASSED] not_in_clone_mode
[23:25:43] [PASSED] valid_clone
[23:25:43] [PASSED] invalid_clone
[23:25:43] =========== [PASSED] drm_test_check_valid_clones ===========
[23:25:43] ============= [PASSED] drm_validate_clone_mode =============
[23:25:43] ============= drm_validate_modeset (1 subtest) =============
[23:25:43] [PASSED] drm_test_check_connector_changed_modeset
[23:25:43] ============== [PASSED] drm_validate_modeset ===============
[23:25:43] ====== drm_test_bridge_get_current_state (2 subtests) ======
[23:25:43] [PASSED] drm_test_drm_bridge_get_current_state_atomic
[23:25:43] [PASSED] drm_test_drm_bridge_get_current_state_legacy
[23:25:43] ======== [PASSED] drm_test_bridge_get_current_state ========
[23:25:43] ====== drm_test_bridge_helper_reset_crtc (3 subtests) ======
[23:25:43] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic
[23:25:43] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic_disabled
[23:25:43] [PASSED] drm_test_drm_bridge_helper_reset_crtc_legacy
[23:25:43] ======== [PASSED] drm_test_bridge_helper_reset_crtc ========
[23:25:43] ============== drm_bridge_alloc (2 subtests) ===============
[23:25:43] [PASSED] drm_test_drm_bridge_alloc_basic
[23:25:43] [PASSED] drm_test_drm_bridge_alloc_get_put
[23:25:43] ================ [PASSED] drm_bridge_alloc =================
[23:25:43] ============= drm_cmdline_parser (40 subtests) =============
[23:25:43] [PASSED] drm_test_cmdline_force_d_only
[23:25:43] [PASSED] drm_test_cmdline_force_D_only_dvi
[23:25:43] [PASSED] drm_test_cmdline_force_D_only_hdmi
[23:25:43] [PASSED] drm_test_cmdline_force_D_only_not_digital
[23:25:43] [PASSED] drm_test_cmdline_force_e_only
[23:25:43] [PASSED] drm_test_cmdline_res
[23:25:43] [PASSED] drm_test_cmdline_res_vesa
[23:25:43] [PASSED] drm_test_cmdline_res_vesa_rblank
[23:25:43] [PASSED] drm_test_cmdline_res_rblank
[23:25:43] [PASSED] drm_test_cmdline_res_bpp
[23:25:43] [PASSED] drm_test_cmdline_res_refresh
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh_margins
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh_force_off
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_analog
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_digital
[23:25:43] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced_margins_force_on
[23:25:43] [PASSED] drm_test_cmdline_res_margins_force_on
[23:25:43] [PASSED] drm_test_cmdline_res_vesa_margins
[23:25:43] [PASSED] drm_test_cmdline_name
[23:25:43] [PASSED] drm_test_cmdline_name_bpp
[23:25:43] [PASSED] drm_test_cmdline_name_option
[23:25:43] [PASSED] drm_test_cmdline_name_bpp_option
[23:25:43] [PASSED] drm_test_cmdline_rotate_0
[23:25:43] [PASSED] drm_test_cmdline_rotate_90
[23:25:43] [PASSED] drm_test_cmdline_rotate_180
[23:25:43] [PASSED] drm_test_cmdline_rotate_270
[23:25:43] [PASSED] drm_test_cmdline_hmirror
[23:25:43] [PASSED] drm_test_cmdline_vmirror
[23:25:43] [PASSED] drm_test_cmdline_margin_options
[23:25:43] [PASSED] drm_test_cmdline_multiple_options
[23:25:43] [PASSED] drm_test_cmdline_bpp_extra_and_option
[23:25:43] [PASSED] drm_test_cmdline_extra_and_option
[23:25:43] [PASSED] drm_test_cmdline_freestanding_options
[23:25:43] [PASSED] drm_test_cmdline_freestanding_force_e_and_options
[23:25:43] [PASSED] drm_test_cmdline_panel_orientation
[23:25:43] ================ drm_test_cmdline_invalid =================
[23:25:43] [PASSED] margin_only
[23:25:43] [PASSED] interlace_only
[23:25:43] [PASSED] res_missing_x
[23:25:43] [PASSED] res_missing_y
[23:25:43] [PASSED] res_bad_y
[23:25:43] [PASSED] res_missing_y_bpp
[23:25:43] [PASSED] res_bad_bpp
[23:25:43] [PASSED] res_bad_refresh
[23:25:43] [PASSED] res_bpp_refresh_force_on_off
[23:25:43] [PASSED] res_invalid_mode
[23:25:43] [PASSED] res_bpp_wrong_place_mode
[23:25:43] [PASSED] name_bpp_refresh
[23:25:43] [PASSED] name_refresh
[23:25:43] [PASSED] name_refresh_wrong_mode
[23:25:43] [PASSED] name_refresh_invalid_mode
[23:25:43] [PASSED] rotate_multiple
[23:25:43] [PASSED] rotate_invalid_val
[23:25:43] [PASSED] rotate_truncated
[23:25:43] [PASSED] invalid_option
[23:25:43] [PASSED] invalid_tv_option
[23:25:43] [PASSED] truncated_tv_option
[23:25:43] ============ [PASSED] drm_test_cmdline_invalid =============
[23:25:43] =============== drm_test_cmdline_tv_options ===============
[23:25:43] [PASSED] NTSC
[23:25:43] [PASSED] NTSC_443
[23:25:43] [PASSED] NTSC_J
[23:25:43] [PASSED] PAL
[23:25:43] [PASSED] PAL_M
[23:25:43] [PASSED] PAL_N
[23:25:43] [PASSED] SECAM
[23:25:43] [PASSED] MONO_525
[23:25:43] [PASSED] MONO_625
[23:25:43] =========== [PASSED] drm_test_cmdline_tv_options ===========
[23:25:43] =============== [PASSED] drm_cmdline_parser ================
[23:25:43] ========== drmm_connector_hdmi_init (20 subtests) ==========
[23:25:43] [PASSED] drm_test_connector_hdmi_init_valid
[23:25:43] [PASSED] drm_test_connector_hdmi_init_bpc_8
[23:25:43] [PASSED] drm_test_connector_hdmi_init_bpc_10
[23:25:43] [PASSED] drm_test_connector_hdmi_init_bpc_12
[23:25:43] [PASSED] drm_test_connector_hdmi_init_bpc_invalid
[23:25:43] [PASSED] drm_test_connector_hdmi_init_bpc_null
[23:25:43] [PASSED] drm_test_connector_hdmi_init_formats_empty
[23:25:43] [PASSED] drm_test_connector_hdmi_init_formats_no_rgb
[23:25:43] === drm_test_connector_hdmi_init_formats_yuv420_allowed ===
[23:25:43] [PASSED] supported_formats=0x9 yuv420_allowed=1
[23:25:43] [PASSED] supported_formats=0x9 yuv420_allowed=0
[23:25:43] [PASSED] supported_formats=0x3 yuv420_allowed=1
[23:25:43] [PASSED] supported_formats=0x3 yuv420_allowed=0
[23:25:43] === [PASSED] drm_test_connector_hdmi_init_formats_yuv420_allowed ===
[23:25:43] [PASSED] drm_test_connector_hdmi_init_null_ddc
[23:25:43] [PASSED] drm_test_connector_hdmi_init_null_product
[23:25:43] [PASSED] drm_test_connector_hdmi_init_null_vendor
[23:25:43] [PASSED] drm_test_connector_hdmi_init_product_length_exact
[23:25:43] [PASSED] drm_test_connector_hdmi_init_product_length_too_long
[23:25:43] [PASSED] drm_test_connector_hdmi_init_product_valid
[23:25:43] [PASSED] drm_test_connector_hdmi_init_vendor_length_exact
[23:25:43] [PASSED] drm_test_connector_hdmi_init_vendor_length_too_long
[23:25:43] [PASSED] drm_test_connector_hdmi_init_vendor_valid
[23:25:43] ========= drm_test_connector_hdmi_init_type_valid =========
[23:25:43] [PASSED] HDMI-A
[23:25:43] [PASSED] HDMI-B
[23:25:43] ===== [PASSED] drm_test_connector_hdmi_init_type_valid =====
[23:25:43] ======== drm_test_connector_hdmi_init_type_invalid ========
[23:25:43] [PASSED] Unknown
[23:25:43] [PASSED] VGA
[23:25:43] [PASSED] DVI-I
[23:25:43] [PASSED] DVI-D
[23:25:43] [PASSED] DVI-A
[23:25:43] [PASSED] Composite
[23:25:43] [PASSED] SVIDEO
[23:25:43] [PASSED] LVDS
[23:25:43] [PASSED] Component
[23:25:43] [PASSED] DIN
[23:25:43] [PASSED] DP
[23:25:43] [PASSED] TV
[23:25:43] [PASSED] eDP
[23:25:43] [PASSED] Virtual
[23:25:43] [PASSED] DSI
[23:25:43] [PASSED] DPI
[23:25:43] [PASSED] Writeback
[23:25:43] [PASSED] SPI
[23:25:43] [PASSED] USB
[23:25:43] ==== [PASSED] drm_test_connector_hdmi_init_type_invalid ====
[23:25:43] ============ [PASSED] drmm_connector_hdmi_init =============
[23:25:43] ============= drmm_connector_init (3 subtests) =============
[23:25:43] [PASSED] drm_test_drmm_connector_init
[23:25:43] [PASSED] drm_test_drmm_connector_init_null_ddc
[23:25:43] ========= drm_test_drmm_connector_init_type_valid =========
[23:25:43] [PASSED] Unknown
[23:25:43] [PASSED] VGA
[23:25:43] [PASSED] DVI-I
[23:25:43] [PASSED] DVI-D
[23:25:43] [PASSED] DVI-A
[23:25:43] [PASSED] Composite
[23:25:43] [PASSED] SVIDEO
[23:25:43] [PASSED] LVDS
[23:25:43] [PASSED] Component
[23:25:43] [PASSED] DIN
[23:25:43] [PASSED] DP
[23:25:43] [PASSED] HDMI-A
[23:25:43] [PASSED] HDMI-B
[23:25:43] [PASSED] TV
[23:25:43] [PASSED] eDP
[23:25:43] [PASSED] Virtual
[23:25:43] [PASSED] DSI
[23:25:43] [PASSED] DPI
[23:25:43] [PASSED] Writeback
[23:25:43] [PASSED] SPI
[23:25:43] [PASSED] USB
[23:25:43] ===== [PASSED] drm_test_drmm_connector_init_type_valid =====
[23:25:43] =============== [PASSED] drmm_connector_init ===============
[23:25:43] ========= drm_connector_dynamic_init (6 subtests) ==========
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_init
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_init_null_ddc
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_init_not_added
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_init_properties
[23:25:43] ===== drm_test_drm_connector_dynamic_init_type_valid ======
[23:25:43] [PASSED] Unknown
[23:25:43] [PASSED] VGA
[23:25:43] [PASSED] DVI-I
[23:25:43] [PASSED] DVI-D
[23:25:43] [PASSED] DVI-A
[23:25:43] [PASSED] Composite
[23:25:43] [PASSED] SVIDEO
[23:25:43] [PASSED] LVDS
[23:25:43] [PASSED] Component
[23:25:43] [PASSED] DIN
[23:25:43] [PASSED] DP
[23:25:43] [PASSED] HDMI-A
[23:25:43] [PASSED] HDMI-B
[23:25:43] [PASSED] TV
[23:25:43] [PASSED] eDP
[23:25:43] [PASSED] Virtual
[23:25:43] [PASSED] DSI
[23:25:43] [PASSED] DPI
[23:25:43] [PASSED] Writeback
[23:25:43] [PASSED] SPI
[23:25:43] [PASSED] USB
[23:25:43] = [PASSED] drm_test_drm_connector_dynamic_init_type_valid ==
[23:25:43] ======== drm_test_drm_connector_dynamic_init_name =========
[23:25:43] [PASSED] Unknown
[23:25:43] [PASSED] VGA
[23:25:43] [PASSED] DVI-I
[23:25:43] [PASSED] DVI-D
[23:25:43] [PASSED] DVI-A
[23:25:43] [PASSED] Composite
[23:25:43] [PASSED] SVIDEO
[23:25:43] [PASSED] LVDS
[23:25:43] [PASSED] Component
[23:25:43] [PASSED] DIN
[23:25:43] [PASSED] DP
[23:25:43] [PASSED] HDMI-A
[23:25:43] [PASSED] HDMI-B
[23:25:43] [PASSED] TV
[23:25:43] [PASSED] eDP
[23:25:43] [PASSED] Virtual
[23:25:43] [PASSED] DSI
[23:25:43] [PASSED] DPI
[23:25:43] [PASSED] Writeback
[23:25:43] [PASSED] SPI
[23:25:43] [PASSED] USB
[23:25:43] ==== [PASSED] drm_test_drm_connector_dynamic_init_name =====
[23:25:43] =========== [PASSED] drm_connector_dynamic_init ============
[23:25:43] ==== drm_connector_dynamic_register_early (4 subtests) =====
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_early_on_list
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_early_defer
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_early_no_init
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_early_no_mode_object
[23:25:43] ====== [PASSED] drm_connector_dynamic_register_early =======
[23:25:43] ======= drm_connector_dynamic_register (7 subtests) ========
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_on_list
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_no_defer
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_no_init
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_mode_object
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_sysfs
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_sysfs_name
[23:25:43] [PASSED] drm_test_drm_connector_dynamic_register_debugfs
[23:25:43] ========= [PASSED] drm_connector_dynamic_register ==========
[23:25:43] = drm_connector_attach_broadcast_rgb_property (2 subtests) =
[23:25:43] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property
[23:25:43] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector
[23:25:43] === [PASSED] drm_connector_attach_broadcast_rgb_property ===
[23:25:43] ========== drm_get_tv_mode_from_name (2 subtests) ==========
[23:25:43] ========== drm_test_get_tv_mode_from_name_valid ===========
[23:25:43] [PASSED] NTSC
[23:25:43] [PASSED] NTSC-443
[23:25:43] [PASSED] NTSC-J
[23:25:43] [PASSED] PAL
[23:25:43] [PASSED] PAL-M
[23:25:43] [PASSED] PAL-N
[23:25:43] [PASSED] SECAM
[23:25:43] [PASSED] Mono
[23:25:43] ====== [PASSED] drm_test_get_tv_mode_from_name_valid =======
[23:25:43] [PASSED] drm_test_get_tv_mode_from_name_truncated
[23:25:43] ============ [PASSED] drm_get_tv_mode_from_name ============
[23:25:43] = drm_test_connector_hdmi_compute_mode_clock (12 subtests) =
[23:25:43] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb
[23:25:43] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc
[23:25:43] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc_vic_1
[23:25:43] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc
[23:25:43] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc_vic_1
[23:25:43] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_double
[23:25:43] = drm_test_connector_hdmi_compute_mode_clock_yuv420_valid =
[23:25:43] [PASSED] VIC 96
[23:25:43] [PASSED] VIC 97
[23:25:43] [PASSED] VIC 101
[23:25:43] [PASSED] VIC 102
[23:25:43] [PASSED] VIC 106
[23:25:43] [PASSED] VIC 107
[23:25:43] === [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_valid ===
[23:25:43] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc
[23:25:43] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc
[23:25:43] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc
[23:25:43] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc
[23:25:43] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc
[23:25:43] === [PASSED] drm_test_connector_hdmi_compute_mode_clock ====
[23:25:43] == drm_hdmi_connector_get_broadcast_rgb_name (2 subtests) ==
[23:25:43] === drm_test_drm_hdmi_connector_get_broadcast_rgb_name ====
[23:25:43] [PASSED] Automatic
[23:25:43] [PASSED] Full
[23:25:43] [PASSED] Limited 16:235
[23:25:43] === [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name ===
[23:25:43] [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid
[23:25:43] ==== [PASSED] drm_hdmi_connector_get_broadcast_rgb_name ====
[23:25:43] == drm_hdmi_connector_get_output_format_name (2 subtests) ==
[23:25:43] === drm_test_drm_hdmi_connector_get_output_format_name ====
[23:25:43] [PASSED] RGB
[23:25:43] [PASSED] YUV 4:2:0
[23:25:43] [PASSED] YUV 4:2:2
[23:25:43] [PASSED] YUV 4:4:4
[23:25:43] === [PASSED] drm_test_drm_hdmi_connector_get_output_format_name ===
[23:25:43] [PASSED] drm_test_drm_hdmi_connector_get_output_format_name_invalid
[23:25:43] ==== [PASSED] drm_hdmi_connector_get_output_format_name ====
[23:25:43] ============= drm_damage_helper (21 subtests) ==============
[23:25:43] [PASSED] drm_test_damage_iter_no_damage
[23:25:43] [PASSED] drm_test_damage_iter_no_damage_fractional_src
[23:25:43] [PASSED] drm_test_damage_iter_no_damage_src_moved
[23:25:43] [PASSED] drm_test_damage_iter_no_damage_fractional_src_moved
[23:25:43] [PASSED] drm_test_damage_iter_no_damage_not_visible
[23:25:43] [PASSED] drm_test_damage_iter_no_damage_no_crtc
[23:25:43] [PASSED] drm_test_damage_iter_no_damage_no_fb
[23:25:43] [PASSED] drm_test_damage_iter_simple_damage
[23:25:43] [PASSED] drm_test_damage_iter_single_damage
[23:25:43] [PASSED] drm_test_damage_iter_single_damage_intersect_src
[23:25:43] [PASSED] drm_test_damage_iter_single_damage_outside_src
[23:25:43] [PASSED] drm_test_damage_iter_single_damage_fractional_src
[23:25:43] [PASSED] drm_test_damage_iter_single_damage_intersect_fractional_src
[23:25:43] [PASSED] drm_test_damage_iter_single_damage_outside_fractional_src
[23:25:43] [PASSED] drm_test_damage_iter_single_damage_src_moved
[23:25:43] [PASSED] drm_test_damage_iter_single_damage_fractional_src_moved
[23:25:43] [PASSED] drm_test_damage_iter_damage
[23:25:43] [PASSED] drm_test_damage_iter_damage_one_intersect
[23:25:43] [PASSED] drm_test_damage_iter_damage_one_outside
[23:25:43] [PASSED] drm_test_damage_iter_damage_src_moved
[23:25:43] [PASSED] drm_test_damage_iter_damage_not_visible
[23:25:43] ================ [PASSED] drm_damage_helper ================
[23:25:43] ============== drm_dp_mst_helper (3 subtests) ==============
[23:25:43] ============== drm_test_dp_mst_calc_pbn_mode ==============
[23:25:43] [PASSED] Clock 154000 BPP 30 DSC disabled
[23:25:43] [PASSED] Clock 234000 BPP 30 DSC disabled
[23:25:43] [PASSED] Clock 297000 BPP 24 DSC disabled
[23:25:43] [PASSED] Clock 332880 BPP 24 DSC enabled
[23:25:43] [PASSED] Clock 324540 BPP 24 DSC enabled
[23:25:43] ========== [PASSED] drm_test_dp_mst_calc_pbn_mode ==========
[23:25:43] ============== drm_test_dp_mst_calc_pbn_div ===============
[23:25:43] [PASSED] Link rate 2000000 lane count 4
[23:25:43] [PASSED] Link rate 2000000 lane count 2
[23:25:43] [PASSED] Link rate 2000000 lane count 1
[23:25:43] [PASSED] Link rate 1350000 lane count 4
[23:25:43] [PASSED] Link rate 1350000 lane count 2
[23:25:43] [PASSED] Link rate 1350000 lane count 1
[23:25:43] [PASSED] Link rate 1000000 lane count 4
[23:25:43] [PASSED] Link rate 1000000 lane count 2
[23:25:43] [PASSED] Link rate 1000000 lane count 1
[23:25:43] [PASSED] Link rate 810000 lane count 4
[23:25:43] [PASSED] Link rate 810000 lane count 2
[23:25:43] [PASSED] Link rate 810000 lane count 1
[23:25:43] [PASSED] Link rate 540000 lane count 4
[23:25:43] [PASSED] Link rate 540000 lane count 2
[23:25:43] [PASSED] Link rate 540000 lane count 1
[23:25:43] [PASSED] Link rate 270000 lane count 4
[23:25:43] [PASSED] Link rate 270000 lane count 2
[23:25:43] [PASSED] Link rate 270000 lane count 1
[23:25:43] [PASSED] Link rate 162000 lane count 4
[23:25:43] [PASSED] Link rate 162000 lane count 2
[23:25:43] [PASSED] Link rate 162000 lane count 1
[23:25:43] ========== [PASSED] drm_test_dp_mst_calc_pbn_div ===========
[23:25:43] ========= drm_test_dp_mst_sideband_msg_req_decode =========
[23:25:43] [PASSED] DP_ENUM_PATH_RESOURCES with port number
[23:25:43] [PASSED] DP_POWER_UP_PHY with port number
[23:25:43] [PASSED] DP_POWER_DOWN_PHY with port number
[23:25:43] [PASSED] DP_ALLOCATE_PAYLOAD with SDP stream sinks
[23:25:43] [PASSED] DP_ALLOCATE_PAYLOAD with port number
[23:25:43] [PASSED] DP_ALLOCATE_PAYLOAD with VCPI
[23:25:43] [PASSED] DP_ALLOCATE_PAYLOAD with PBN
[23:25:43] [PASSED] DP_QUERY_PAYLOAD with port number
[23:25:43] [PASSED] DP_QUERY_PAYLOAD with VCPI
[23:25:43] [PASSED] DP_REMOTE_DPCD_READ with port number
[23:25:43] [PASSED] DP_REMOTE_DPCD_READ with DPCD address
[23:25:43] [PASSED] DP_REMOTE_DPCD_READ with max number of bytes
[23:25:43] [PASSED] DP_REMOTE_DPCD_WRITE with port number
[23:25:43] [PASSED] DP_REMOTE_DPCD_WRITE with DPCD address
[23:25:43] [PASSED] DP_REMOTE_DPCD_WRITE with data array
[23:25:43] [PASSED] DP_REMOTE_I2C_READ with port number
[23:25:43] [PASSED] DP_REMOTE_I2C_READ with I2C device ID
[23:25:43] [PASSED] DP_REMOTE_I2C_READ with transactions array
[23:25:43] [PASSED] DP_REMOTE_I2C_WRITE with port number
[23:25:43] [PASSED] DP_REMOTE_I2C_WRITE with I2C device ID
[23:25:43] [PASSED] DP_REMOTE_I2C_WRITE with data array
[23:25:43] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream ID
[23:25:43] [PASSED] DP_QUERY_STREAM_ENC_STATUS with client ID
[23:25:43] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream event
[23:25:43] [PASSED] DP_QUERY_STREAM_ENC_STATUS with valid stream event
[23:25:43] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream behavior
[23:25:43] [PASSED] DP_QUERY_STREAM_ENC_STATUS with a valid stream behavior
[23:25:43] ===== [PASSED] drm_test_dp_mst_sideband_msg_req_decode =====
[23:25:43] ================ [PASSED] drm_dp_mst_helper ================
[23:25:43] ================== drm_exec (7 subtests) ===================
[23:25:43] [PASSED] sanitycheck
[23:25:43] [PASSED] test_lock
[23:25:43] [PASSED] test_lock_unlock
[23:25:43] [PASSED] test_duplicates
[23:25:43] [PASSED] test_prepare
[23:25:43] [PASSED] test_prepare_array
[23:25:43] [PASSED] test_multiple_loops
[23:25:43] ==================== [PASSED] drm_exec =====================
[23:25:43] =========== drm_format_helper_test (17 subtests) ===========
[23:25:43] ============== drm_test_fb_xrgb8888_to_gray8 ==============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ========== [PASSED] drm_test_fb_xrgb8888_to_gray8 ==========
[23:25:43] ============= drm_test_fb_xrgb8888_to_rgb332 ==============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb332 ==========
[23:25:43] ============= drm_test_fb_xrgb8888_to_rgb565 ==============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb565 ==========
[23:25:43] ============ drm_test_fb_xrgb8888_to_xrgb1555 =============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======== [PASSED] drm_test_fb_xrgb8888_to_xrgb1555 =========
[23:25:43] ============ drm_test_fb_xrgb8888_to_argb1555 =============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======== [PASSED] drm_test_fb_xrgb8888_to_argb1555 =========
[23:25:43] ============ drm_test_fb_xrgb8888_to_rgba5551 =============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======== [PASSED] drm_test_fb_xrgb8888_to_rgba5551 =========
[23:25:43] ============= drm_test_fb_xrgb8888_to_rgb888 ==============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb888 ==========
[23:25:43] ============= drm_test_fb_xrgb8888_to_bgr888 ==============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ========= [PASSED] drm_test_fb_xrgb8888_to_bgr888 ==========
[23:25:43] ============ drm_test_fb_xrgb8888_to_argb8888 =============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======== [PASSED] drm_test_fb_xrgb8888_to_argb8888 =========
[23:25:43] =========== drm_test_fb_xrgb8888_to_xrgb2101010 ===========
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======= [PASSED] drm_test_fb_xrgb8888_to_xrgb2101010 =======
[23:25:43] =========== drm_test_fb_xrgb8888_to_argb2101010 ===========
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======= [PASSED] drm_test_fb_xrgb8888_to_argb2101010 =======
[23:25:43] ============== drm_test_fb_xrgb8888_to_mono ===============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ========== [PASSED] drm_test_fb_xrgb8888_to_mono ===========
[23:25:43] ==================== drm_test_fb_swab =====================
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ================ [PASSED] drm_test_fb_swab =================
[23:25:43] ============ drm_test_fb_xrgb8888_to_xbgr8888 =============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======== [PASSED] drm_test_fb_xrgb8888_to_xbgr8888 =========
[23:25:43] ============ drm_test_fb_xrgb8888_to_abgr8888 =============
[23:25:43] [PASSED] single_pixel_source_buffer
[23:25:43] [PASSED] single_pixel_clip_rectangle
[23:25:43] [PASSED] well_known_colors
[23:25:43] [PASSED] destination_pitch
[23:25:43] ======== [PASSED] drm_test_fb_xrgb8888_to_abgr8888 =========
[23:25:43] ================= drm_test_fb_clip_offset =================
[23:25:43] [PASSED] pass through
[23:25:43] [PASSED] horizontal offset
[23:25:43] [PASSED] vertical offset
[23:25:43] [PASSED] horizontal and vertical offset
[23:25:43] [PASSED] horizontal offset (custom pitch)
[23:25:43] [PASSED] vertical offset (custom pitch)
[23:25:43] [PASSED] horizontal and vertical offset (custom pitch)
[23:25:43] ============= [PASSED] drm_test_fb_clip_offset =============
[23:25:43] =================== drm_test_fb_memcpy ====================
[23:25:43] [PASSED] single_pixel_source_buffer: XR24 little-endian (0x34325258)
[23:25:43] [PASSED] single_pixel_source_buffer: XRA8 little-endian (0x38415258)
[23:25:43] [PASSED] single_pixel_source_buffer: YU24 little-endian (0x34325559)
[23:25:43] [PASSED] single_pixel_clip_rectangle: XB24 little-endian (0x34324258)
[23:25:43] [PASSED] single_pixel_clip_rectangle: XRA8 little-endian (0x38415258)
[23:25:43] [PASSED] single_pixel_clip_rectangle: YU24 little-endian (0x34325559)
[23:25:43] [PASSED] well_known_colors: XB24 little-endian (0x34324258)
[23:25:43] [PASSED] well_known_colors: XRA8 little-endian (0x38415258)
[23:25:43] [PASSED] well_known_colors: YU24 little-endian (0x34325559)
[23:25:43] [PASSED] destination_pitch: XB24 little-endian (0x34324258)
[23:25:43] [PASSED] destination_pitch: XRA8 little-endian (0x38415258)
[23:25:43] [PASSED] destination_pitch: YU24 little-endian (0x34325559)
[23:25:43] =============== [PASSED] drm_test_fb_memcpy ================
[23:25:43] ============= [PASSED] drm_format_helper_test ==============
[23:25:43] ================= drm_format (18 subtests) =================
[23:25:43] [PASSED] drm_test_format_block_width_invalid
[23:25:43] [PASSED] drm_test_format_block_width_one_plane
[23:25:43] [PASSED] drm_test_format_block_width_two_plane
[23:25:43] [PASSED] drm_test_format_block_width_three_plane
[23:25:43] [PASSED] drm_test_format_block_width_tiled
[23:25:43] [PASSED] drm_test_format_block_height_invalid
[23:25:43] [PASSED] drm_test_format_block_height_one_plane
[23:25:43] [PASSED] drm_test_format_block_height_two_plane
[23:25:43] [PASSED] drm_test_format_block_height_three_plane
[23:25:43] [PASSED] drm_test_format_block_height_tiled
[23:25:43] [PASSED] drm_test_format_min_pitch_invalid
[23:25:43] [PASSED] drm_test_format_min_pitch_one_plane_8bpp
[23:25:43] [PASSED] drm_test_format_min_pitch_one_plane_16bpp
[23:25:43] [PASSED] drm_test_format_min_pitch_one_plane_24bpp
[23:25:43] [PASSED] drm_test_format_min_pitch_one_plane_32bpp
[23:25:43] [PASSED] drm_test_format_min_pitch_two_plane
[23:25:43] [PASSED] drm_test_format_min_pitch_three_plane_8bpp
[23:25:43] [PASSED] drm_test_format_min_pitch_tiled
[23:25:43] =================== [PASSED] drm_format ====================
[23:25:43] ============== drm_framebuffer (10 subtests) ===============
[23:25:43] ========== drm_test_framebuffer_check_src_coords ==========
[23:25:43] [PASSED] Success: source fits into fb
[23:25:43] [PASSED] Fail: overflowing fb with x-axis coordinate
[23:25:43] [PASSED] Fail: overflowing fb with y-axis coordinate
[23:25:43] [PASSED] Fail: overflowing fb with source width
[23:25:43] [PASSED] Fail: overflowing fb with source height
[23:25:43] ====== [PASSED] drm_test_framebuffer_check_src_coords ======
[23:25:43] [PASSED] drm_test_framebuffer_cleanup
[23:25:43] =============== drm_test_framebuffer_create ===============
[23:25:43] [PASSED] ABGR8888 normal sizes
[23:25:43] [PASSED] ABGR8888 max sizes
[23:25:43] [PASSED] ABGR8888 pitch greater than min required
[23:25:43] [PASSED] ABGR8888 pitch less than min required
[23:25:43] [PASSED] ABGR8888 Invalid width
[23:25:43] [PASSED] ABGR8888 Invalid buffer handle
[23:25:43] [PASSED] No pixel format
[23:25:43] [PASSED] ABGR8888 Width 0
[23:25:43] [PASSED] ABGR8888 Height 0
[23:25:43] [PASSED] ABGR8888 Out of bound height * pitch combination
[23:25:43] [PASSED] ABGR8888 Large buffer offset
[23:25:43] [PASSED] ABGR8888 Buffer offset for inexistent plane
[23:25:43] [PASSED] ABGR8888 Invalid flag
[23:25:43] [PASSED] ABGR8888 Set DRM_MODE_FB_MODIFIERS without modifiers
[23:25:43] [PASSED] ABGR8888 Valid buffer modifier
[23:25:43] [PASSED] ABGR8888 Invalid buffer modifier(DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
[23:25:43] [PASSED] ABGR8888 Extra pitches without DRM_MODE_FB_MODIFIERS
[23:25:43] [PASSED] ABGR8888 Extra pitches with DRM_MODE_FB_MODIFIERS
[23:25:43] [PASSED] NV12 Normal sizes
[23:25:43] [PASSED] NV12 Max sizes
[23:25:43] [PASSED] NV12 Invalid pitch
[23:25:43] [PASSED] NV12 Invalid modifier/missing DRM_MODE_FB_MODIFIERS flag
[23:25:43] [PASSED] NV12 different modifier per-plane
[23:25:43] [PASSED] NV12 with DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
[23:25:43] [PASSED] NV12 Valid modifiers without DRM_MODE_FB_MODIFIERS
[23:25:43] [PASSED] NV12 Modifier for inexistent plane
[23:25:43] [PASSED] NV12 Handle for inexistent plane
[23:25:43] [PASSED] NV12 Handle for inexistent plane without DRM_MODE_FB_MODIFIERS
[23:25:43] [PASSED] YVU420 DRM_MODE_FB_MODIFIERS set without modifier
[23:25:43] [PASSED] YVU420 Normal sizes
[23:25:43] [PASSED] YVU420 Max sizes
[23:25:43] [PASSED] YVU420 Invalid pitch
[23:25:43] [PASSED] YVU420 Different pitches
[23:25:43] [PASSED] YVU420 Different buffer offsets/pitches
[23:25:43] [PASSED] YVU420 Modifier set just for plane 0, without DRM_MODE_FB_MODIFIERS
[23:25:43] [PASSED] YVU420 Modifier set just for planes 0, 1, without DRM_MODE_FB_MODIFIERS
[23:25:43] [PASSED] YVU420 Modifier set just for plane 0, 1, with DRM_MODE_FB_MODIFIERS
[23:25:43] [PASSED] YVU420 Valid modifier
[23:25:43] [PASSED] YVU420 Different modifiers per plane
[23:25:43] [PASSED] YVU420 Modifier for inexistent plane
[23:25:43] [PASSED] YUV420_10BIT Invalid modifier(DRM_FORMAT_MOD_LINEAR)
[23:25:43] [PASSED] X0L2 Normal sizes
[23:25:43] [PASSED] X0L2 Max sizes
[23:25:43] [PASSED] X0L2 Invalid pitch
[23:25:43] [PASSED] X0L2 Pitch greater than minimum required
[23:25:43] [PASSED] X0L2 Handle for inexistent plane
[23:25:43] [PASSED] X0L2 Offset for inexistent plane, without DRM_MODE_FB_MODIFIERS set
[23:25:43] [PASSED] X0L2 Modifier without DRM_MODE_FB_MODIFIERS set
[23:25:43] [PASSED] X0L2 Valid modifier
[23:25:43] [PASSED] X0L2 Modifier for inexistent plane
[23:25:43] =========== [PASSED] drm_test_framebuffer_create ===========
[23:25:43] [PASSED] drm_test_framebuffer_free
[23:25:43] [PASSED] drm_test_framebuffer_init
[23:25:43] [PASSED] drm_test_framebuffer_init_bad_format
[23:25:43] [PASSED] drm_test_framebuffer_init_dev_mismatch
[23:25:43] [PASSED] drm_test_framebuffer_lookup
[23:25:43] [PASSED] drm_test_framebuffer_lookup_inexistent
[23:25:43] [PASSED] drm_test_framebuffer_modifiers_not_supported
[23:25:43] ================= [PASSED] drm_framebuffer =================
[23:25:43] ================ drm_gem_shmem (8 subtests) ================
[23:25:43] [PASSED] drm_gem_shmem_test_obj_create
[23:25:43] [PASSED] drm_gem_shmem_test_obj_create_private
[23:25:43] [PASSED] drm_gem_shmem_test_pin_pages
[23:25:43] [PASSED] drm_gem_shmem_test_vmap
[23:25:43] [PASSED] drm_gem_shmem_test_get_sg_table
[23:25:43] [PASSED] drm_gem_shmem_test_get_pages_sgt
[23:25:43] [PASSED] drm_gem_shmem_test_madvise
[23:25:43] [PASSED] drm_gem_shmem_test_purge
[23:25:43] ================== [PASSED] drm_gem_shmem ==================
[23:25:43] === drm_atomic_helper_connector_hdmi_check (27 subtests) ===
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode_vic_1
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode_vic_1
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode_vic_1
[23:25:43] ====== drm_test_check_broadcast_rgb_cea_mode_yuv420 =======
[23:25:43] [PASSED] Automatic
[23:25:43] [PASSED] Full
[23:25:43] [PASSED] Limited 16:235
[23:25:43] == [PASSED] drm_test_check_broadcast_rgb_cea_mode_yuv420 ===
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_changed
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_not_changed
[23:25:43] [PASSED] drm_test_check_disable_connector
[23:25:43] [PASSED] drm_test_check_hdmi_funcs_reject_rate
[23:25:43] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_rgb
[23:25:43] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_yuv420
[23:25:43] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv422
[23:25:43] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv420
[23:25:43] [PASSED] drm_test_check_driver_unsupported_fallback_yuv420
[23:25:43] [PASSED] drm_test_check_output_bpc_crtc_mode_changed
[23:25:43] [PASSED] drm_test_check_output_bpc_crtc_mode_not_changed
[23:25:43] [PASSED] drm_test_check_output_bpc_dvi
[23:25:43] [PASSED] drm_test_check_output_bpc_format_vic_1
[23:25:43] [PASSED] drm_test_check_output_bpc_format_display_8bpc_only
[23:25:43] [PASSED] drm_test_check_output_bpc_format_display_rgb_only
[23:25:43] [PASSED] drm_test_check_output_bpc_format_driver_8bpc_only
[23:25:43] [PASSED] drm_test_check_output_bpc_format_driver_rgb_only
[23:25:43] [PASSED] drm_test_check_tmds_char_rate_rgb_8bpc
[23:25:43] [PASSED] drm_test_check_tmds_char_rate_rgb_10bpc
[23:25:43] [PASSED] drm_test_check_tmds_char_rate_rgb_12bpc
[23:25:43] ===== [PASSED] drm_atomic_helper_connector_hdmi_check ======
[23:25:43] === drm_atomic_helper_connector_hdmi_reset (6 subtests) ====
[23:25:43] [PASSED] drm_test_check_broadcast_rgb_value
[23:25:43] [PASSED] drm_test_check_bpc_8_value
[23:25:43] [PASSED] drm_test_check_bpc_10_value
[23:25:43] [PASSED] drm_test_check_bpc_12_value
[23:25:43] [PASSED] drm_test_check_format_value
[23:25:43] [PASSED] drm_test_check_tmds_char_value
[23:25:43] ===== [PASSED] drm_atomic_helper_connector_hdmi_reset ======
[23:25:43] = drm_atomic_helper_connector_hdmi_mode_valid (4 subtests) =
[23:25:43] [PASSED] drm_test_check_mode_valid
[23:25:43] [PASSED] drm_test_check_mode_valid_reject
[23:25:43] [PASSED] drm_test_check_mode_valid_reject_rate
[23:25:43] [PASSED] drm_test_check_mode_valid_reject_max_clock
[23:25:43] === [PASSED] drm_atomic_helper_connector_hdmi_mode_valid ===
[23:25:43] = drm_atomic_helper_connector_hdmi_infoframes (5 subtests) =
[23:25:43] [PASSED] drm_test_check_infoframes
[23:25:43] [PASSED] drm_test_check_reject_avi_infoframe
[23:25:43] [PASSED] drm_test_check_reject_hdr_infoframe_bpc_8
[23:25:43] [PASSED] drm_test_check_reject_hdr_infoframe_bpc_10
[23:25:43] [PASSED] drm_test_check_reject_audio_infoframe
[23:25:43] === [PASSED] drm_atomic_helper_connector_hdmi_infoframes ===
[23:25:43] ================= drm_managed (2 subtests) =================
[23:25:43] [PASSED] drm_test_managed_release_action
[23:25:43] [PASSED] drm_test_managed_run_action
[23:25:43] =================== [PASSED] drm_managed ===================
[23:25:43] =================== drm_mm (6 subtests) ====================
[23:25:43] [PASSED] drm_test_mm_init
[23:25:43] [PASSED] drm_test_mm_debug
[23:25:43] [PASSED] drm_test_mm_align32
[23:25:43] [PASSED] drm_test_mm_align64
[23:25:43] [PASSED] drm_test_mm_lowest
[23:25:43] [PASSED] drm_test_mm_highest
[23:25:43] ===================== [PASSED] drm_mm ======================
[23:25:43] ============= drm_modes_analog_tv (5 subtests) =============
[23:25:43] [PASSED] drm_test_modes_analog_tv_mono_576i
[23:25:43] [PASSED] drm_test_modes_analog_tv_ntsc_480i
[23:25:43] [PASSED] drm_test_modes_analog_tv_ntsc_480i_inlined
[23:25:43] [PASSED] drm_test_modes_analog_tv_pal_576i
[23:25:43] [PASSED] drm_test_modes_analog_tv_pal_576i_inlined
[23:25:43] =============== [PASSED] drm_modes_analog_tv ===============
[23:25:43] ============== drm_plane_helper (2 subtests) ===============
[23:25:43] =============== drm_test_check_plane_state ================
[23:25:43] [PASSED] clipping_simple
[23:25:43] [PASSED] clipping_rotate_reflect
[23:25:43] [PASSED] positioning_simple
[23:25:43] [PASSED] upscaling
[23:25:43] [PASSED] downscaling
[23:25:43] [PASSED] rounding1
[23:25:43] [PASSED] rounding2
[23:25:43] [PASSED] rounding3
[23:25:43] [PASSED] rounding4
[23:25:43] =========== [PASSED] drm_test_check_plane_state ============
[23:25:43] =========== drm_test_check_invalid_plane_state ============
[23:25:43] [PASSED] positioning_invalid
[23:25:43] [PASSED] upscaling_invalid
[23:25:43] [PASSED] downscaling_invalid
[23:25:43] ======= [PASSED] drm_test_check_invalid_plane_state ========
[23:25:43] ================ [PASSED] drm_plane_helper =================
[23:25:43] ====== drm_connector_helper_tv_get_modes (1 subtest) =======
[23:25:43] ====== drm_test_connector_helper_tv_get_modes_check =======
[23:25:43] [PASSED] None
[23:25:43] [PASSED] PAL
[23:25:43] [PASSED] NTSC
[23:25:43] [PASSED] Both, NTSC Default
[23:25:43] [PASSED] Both, PAL Default
[23:25:43] [PASSED] Both, NTSC Default, with PAL on command-line
[23:25:43] [PASSED] Both, PAL Default, with NTSC on command-line
[23:25:43] == [PASSED] drm_test_connector_helper_tv_get_modes_check ===
[23:25:43] ======== [PASSED] drm_connector_helper_tv_get_modes ========
[23:25:43] ================== drm_rect (9 subtests) ===================
[23:25:43] [PASSED] drm_test_rect_clip_scaled_div_by_zero
[23:25:43] [PASSED] drm_test_rect_clip_scaled_not_clipped
[23:25:43] [PASSED] drm_test_rect_clip_scaled_clipped
[23:25:43] [PASSED] drm_test_rect_clip_scaled_signed_vs_unsigned
[23:25:43] ================= drm_test_rect_intersect =================
[23:25:43] [PASSED] top-left x bottom-right: 2x2+1+1 x 2x2+0+0
[23:25:43] [PASSED] top-right x bottom-left: 2x2+0+0 x 2x2+1-1
[23:25:43] [PASSED] bottom-left x top-right: 2x2+1-1 x 2x2+0+0
[23:25:43] [PASSED] bottom-right x top-left: 2x2+0+0 x 2x2+1+1
[23:25:43] [PASSED] right x left: 2x1+0+0 x 3x1+1+0
[23:25:43] [PASSED] left x right: 3x1+1+0 x 2x1+0+0
[23:25:43] [PASSED] up x bottom: 1x2+0+0 x 1x3+0-1
[23:25:43] [PASSED] bottom x up: 1x3+0-1 x 1x2+0+0
[23:25:43] [PASSED] touching corner: 1x1+0+0 x 2x2+1+1
[23:25:43] [PASSED] touching side: 1x1+0+0 x 1x1+1+0
[23:25:43] [PASSED] equal rects: 2x2+0+0 x 2x2+0+0
[23:25:43] [PASSED] inside another: 2x2+0+0 x 1x1+1+1
[23:25:43] [PASSED] far away: 1x1+0+0 x 1x1+3+6
[23:25:43] [PASSED] points intersecting: 0x0+5+10 x 0x0+5+10
[23:25:43] [PASSED] points not intersecting: 0x0+0+0 x 0x0+5+10
[23:25:43] ============= [PASSED] drm_test_rect_intersect =============
[23:25:43] ================ drm_test_rect_calc_hscale ================
[23:25:43] [PASSED] normal use
[23:25:43] [PASSED] out of max range
[23:25:43] [PASSED] out of min range
[23:25:43] [PASSED] zero dst
[23:25:43] [PASSED] negative src
[23:25:43] [PASSED] negative dst
[23:25:43] ============ [PASSED] drm_test_rect_calc_hscale ============
[23:25:43] ================ drm_test_rect_calc_vscale ================
[23:25:43] [PASSED] normal use
[23:25:43] [PASSED] out of max range
[23:25:43] [PASSED] out of min range
[23:25:43] [PASSED] zero dst
[23:25:43] [PASSED] negative src
[23:25:43] [PASSED] negative dst
stty: 'standard input': Inappropriate ioctl for device
[23:25:43] ============ [PASSED] drm_test_rect_calc_vscale ============
[23:25:43] ================== drm_test_rect_rotate ===================
[23:25:43] [PASSED] reflect-x
[23:25:43] [PASSED] reflect-y
[23:25:43] [PASSED] rotate-0
[23:25:43] [PASSED] rotate-90
[23:25:43] [PASSED] rotate-180
[23:25:43] [PASSED] rotate-270
[23:25:43] ============== [PASSED] drm_test_rect_rotate ===============
[23:25:43] ================ drm_test_rect_rotate_inv =================
[23:25:43] [PASSED] reflect-x
[23:25:43] [PASSED] reflect-y
[23:25:43] [PASSED] rotate-0
[23:25:43] [PASSED] rotate-90
[23:25:43] [PASSED] rotate-180
[23:25:43] [PASSED] rotate-270
[23:25:43] ============ [PASSED] drm_test_rect_rotate_inv =============
[23:25:43] ==================== [PASSED] drm_rect =====================
[23:25:43] ============ drm_sysfb_modeset_test (1 subtest) ============
[23:25:43] ============ drm_test_sysfb_build_fourcc_list =============
[23:25:43] [PASSED] no native formats
[23:25:43] [PASSED] XRGB8888 as native format
[23:25:43] [PASSED] remove duplicates
[23:25:43] [PASSED] convert alpha formats
[23:25:43] [PASSED] random formats
[23:25:43] ======== [PASSED] drm_test_sysfb_build_fourcc_list =========
[23:25:43] ============= [PASSED] drm_sysfb_modeset_test ==============
[23:25:43] ================== drm_fixp (2 subtests) ===================
[23:25:43] [PASSED] drm_test_int2fixp
[23:25:43] [PASSED] drm_test_sm2fixp
[23:25:43] ==================== [PASSED] drm_fixp =====================
[23:25:43] ============================================================
[23:25:43] Testing complete. Ran 621 tests: passed: 621
[23:25:43] Elapsed time: 25.909s total, 1.708s configuring, 24.072s building, 0.127s running
+ /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/ttm/tests/.kunitconfig
[23:25:43] Configuring KUnit Kernel ...
Regenerating .config ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
[23:25:45] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=48
[23:25:54] Starting KUnit Kernel (1/1)...
[23:25:54] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[23:25:54] ================= ttm_device (5 subtests) ==================
[23:25:54] [PASSED] ttm_device_init_basic
[23:25:54] [PASSED] ttm_device_init_multiple
[23:25:54] [PASSED] ttm_device_fini_basic
[23:25:54] [PASSED] ttm_device_init_no_vma_man
[23:25:54] ================== ttm_device_init_pools ==================
[23:25:54] [PASSED] No DMA allocations, no DMA32 required
[23:25:54] [PASSED] DMA allocations, DMA32 required
[23:25:54] [PASSED] No DMA allocations, DMA32 required
[23:25:54] [PASSED] DMA allocations, no DMA32 required
[23:25:54] ============== [PASSED] ttm_device_init_pools ==============
[23:25:54] =================== [PASSED] ttm_device ====================
[23:25:54] ================== ttm_pool (8 subtests) ===================
[23:25:54] ================== ttm_pool_alloc_basic ===================
[23:25:54] [PASSED] One page
[23:25:54] [PASSED] More than one page
[23:25:54] [PASSED] Above the allocation limit
[23:25:54] [PASSED] One page, with coherent DMA mappings enabled
[23:25:54] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[23:25:54] ============== [PASSED] ttm_pool_alloc_basic ===============
[23:25:54] ============== ttm_pool_alloc_basic_dma_addr ==============
[23:25:54] [PASSED] One page
[23:25:54] [PASSED] More than one page
[23:25:54] [PASSED] Above the allocation limit
[23:25:54] [PASSED] One page, with coherent DMA mappings enabled
[23:25:54] [PASSED] Above the allocation limit, with coherent DMA mappings enabled
[23:25:54] ========== [PASSED] ttm_pool_alloc_basic_dma_addr ==========
[23:25:54] [PASSED] ttm_pool_alloc_order_caching_match
[23:25:54] [PASSED] ttm_pool_alloc_caching_mismatch
[23:25:54] [PASSED] ttm_pool_alloc_order_mismatch
[23:25:54] [PASSED] ttm_pool_free_dma_alloc
[23:25:54] [PASSED] ttm_pool_free_no_dma_alloc
[23:25:54] [PASSED] ttm_pool_fini_basic
[23:25:54] ==================== [PASSED] ttm_pool =====================
[23:25:54] ================ ttm_resource (8 subtests) =================
[23:25:54] ================= ttm_resource_init_basic =================
[23:25:54] [PASSED] Init resource in TTM_PL_SYSTEM
[23:25:54] [PASSED] Init resource in TTM_PL_VRAM
[23:25:54] [PASSED] Init resource in a private placement
[23:25:54] [PASSED] Init resource in TTM_PL_SYSTEM, set placement flags
[23:25:54] ============= [PASSED] ttm_resource_init_basic =============
[23:25:54] [PASSED] ttm_resource_init_pinned
[23:25:54] [PASSED] ttm_resource_fini_basic
[23:25:54] [PASSED] ttm_resource_manager_init_basic
[23:25:54] [PASSED] ttm_resource_manager_usage_basic
[23:25:54] [PASSED] ttm_resource_manager_set_used_basic
[23:25:54] [PASSED] ttm_sys_man_alloc_basic
[23:25:54] [PASSED] ttm_sys_man_free_basic
[23:25:54] ================== [PASSED] ttm_resource ===================
[23:25:54] =================== ttm_tt (15 subtests) ===================
[23:25:54] ==================== ttm_tt_init_basic ====================
[23:25:54] [PASSED] Page-aligned size
[23:25:54] [PASSED] Extra pages requested
[23:25:54] ================ [PASSED] ttm_tt_init_basic ================
[23:25:54] [PASSED] ttm_tt_init_misaligned
[23:25:54] [PASSED] ttm_tt_fini_basic
[23:25:54] [PASSED] ttm_tt_fini_sg
[23:25:54] [PASSED] ttm_tt_fini_shmem
[23:25:54] [PASSED] ttm_tt_create_basic
[23:25:54] [PASSED] ttm_tt_create_invalid_bo_type
[23:25:54] [PASSED] ttm_tt_create_ttm_exists
[23:25:54] [PASSED] ttm_tt_create_failed
[23:25:54] [PASSED] ttm_tt_destroy_basic
[23:25:54] [PASSED] ttm_tt_populate_null_ttm
[23:25:54] [PASSED] ttm_tt_populate_populated_ttm
[23:25:54] [PASSED] ttm_tt_unpopulate_basic
[23:25:54] [PASSED] ttm_tt_unpopulate_empty_ttm
[23:25:54] [PASSED] ttm_tt_swapin_basic
[23:25:54] ===================== [PASSED] ttm_tt ======================
[23:25:54] =================== ttm_bo (14 subtests) ===================
[23:25:54] =========== ttm_bo_reserve_optimistic_no_ticket ===========
[23:25:54] [PASSED] Cannot be interrupted and sleeps
[23:25:54] [PASSED] Cannot be interrupted, locks straight away
[23:25:54] [PASSED] Can be interrupted, sleeps
[23:25:54] ======= [PASSED] ttm_bo_reserve_optimistic_no_ticket =======
[23:25:54] [PASSED] ttm_bo_reserve_locked_no_sleep
[23:25:54] [PASSED] ttm_bo_reserve_no_wait_ticket
[23:25:54] [PASSED] ttm_bo_reserve_double_resv
[23:25:54] [PASSED] ttm_bo_reserve_interrupted
[23:25:54] [PASSED] ttm_bo_reserve_deadlock
[23:25:54] [PASSED] ttm_bo_unreserve_basic
[23:25:54] [PASSED] ttm_bo_unreserve_pinned
[23:25:54] [PASSED] ttm_bo_unreserve_bulk
[23:25:54] [PASSED] ttm_bo_fini_basic
[23:25:54] [PASSED] ttm_bo_fini_shared_resv
[23:25:54] [PASSED] ttm_bo_pin_basic
[23:25:54] [PASSED] ttm_bo_pin_unpin_resource
[23:25:54] [PASSED] ttm_bo_multiple_pin_one_unpin
[23:25:54] ===================== [PASSED] ttm_bo ======================
[23:25:54] ============== ttm_bo_validate (22 subtests) ===============
[23:25:54] ============== ttm_bo_init_reserved_sys_man ===============
[23:25:54] [PASSED] Buffer object for userspace
[23:25:54] [PASSED] Kernel buffer object
[23:25:54] [PASSED] Shared buffer object
[23:25:54] ========== [PASSED] ttm_bo_init_reserved_sys_man ===========
[23:25:54] ============== ttm_bo_init_reserved_mock_man ==============
[23:25:54] [PASSED] Buffer object for userspace
[23:25:54] [PASSED] Kernel buffer object
[23:25:54] [PASSED] Shared buffer object
[23:25:54] ========== [PASSED] ttm_bo_init_reserved_mock_man ==========
[23:25:54] [PASSED] ttm_bo_init_reserved_resv
[23:25:54] ================== ttm_bo_validate_basic ==================
[23:25:54] [PASSED] Buffer object for userspace
[23:25:54] [PASSED] Kernel buffer object
[23:25:54] [PASSED] Shared buffer object
[23:25:54] ============== [PASSED] ttm_bo_validate_basic ==============
[23:25:54] [PASSED] ttm_bo_validate_invalid_placement
[23:25:54] ============= ttm_bo_validate_same_placement ==============
[23:25:54] [PASSED] System manager
[23:25:54] [PASSED] VRAM manager
[23:25:54] ========= [PASSED] ttm_bo_validate_same_placement ==========
[23:25:54] [PASSED] ttm_bo_validate_failed_alloc
[23:25:54] [PASSED] ttm_bo_validate_pinned
[23:25:54] [PASSED] ttm_bo_validate_busy_placement
[23:25:54] ================ ttm_bo_validate_multihop =================
[23:25:54] [PASSED] Buffer object for userspace
[23:25:54] [PASSED] Kernel buffer object
[23:25:54] [PASSED] Shared buffer object
[23:25:54] ============ [PASSED] ttm_bo_validate_multihop =============
[23:25:54] ========== ttm_bo_validate_no_placement_signaled ==========
[23:25:54] [PASSED] Buffer object in system domain, no page vector
[23:25:54] [PASSED] Buffer object in system domain with an existing page vector
[23:25:54] ====== [PASSED] ttm_bo_validate_no_placement_signaled ======
[23:25:54] ======== ttm_bo_validate_no_placement_not_signaled ========
[23:25:54] [PASSED] Buffer object for userspace
[23:25:54] [PASSED] Kernel buffer object
[23:25:54] [PASSED] Shared buffer object
[23:25:54] ==== [PASSED] ttm_bo_validate_no_placement_not_signaled ====
[23:25:54] [PASSED] ttm_bo_validate_move_fence_signaled
[23:25:54] ========= ttm_bo_validate_move_fence_not_signaled =========
[23:25:54] [PASSED] Waits for GPU
[23:25:54] [PASSED] Tries to lock straight away
[23:25:54] ===== [PASSED] ttm_bo_validate_move_fence_not_signaled =====
[23:25:54] [PASSED] ttm_bo_validate_swapout
[23:25:54] [PASSED] ttm_bo_validate_happy_evict
[23:25:54] [PASSED] ttm_bo_validate_all_pinned_evict
[23:25:54] [PASSED] ttm_bo_validate_allowed_only_evict
[23:25:54] [PASSED] ttm_bo_validate_deleted_evict
[23:25:54] [PASSED] ttm_bo_validate_busy_domain_evict
[23:25:54] [PASSED] ttm_bo_validate_evict_gutting
[23:25:54] [PASSED] ttm_bo_validate_recrusive_evict
stty: 'standard input': Inappropriate ioctl for device
[23:25:54] ================= [PASSED] ttm_bo_validate =================
[23:25:54] ============================================================
[23:25:54] Testing complete. Ran 102 tests: passed: 102
[23:25:54] Elapsed time: 11.348s total, 1.731s configuring, 9.401s building, 0.175s running
+ cleanup
++ stat -c %u:%g /kernel
+ chown -R 1003:1003 /kernel
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-17 23:21 [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval fei.yang
2026-03-17 23:24 ` ✗ CI.checkpatch: warning for " Patchwork
2026-03-17 23:25 ` ✓ CI.KUnit: success " Patchwork
@ 2026-03-17 23:28 ` Summers, Stuart
2026-03-22 5:35 ` Matthew Brost
2026-03-18 0:08 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-03-19 12:33 ` ✓ Xe.CI.FULL: " Patchwork
4 siblings, 1 reply; 21+ messages in thread
From: Summers, Stuart @ 2026-03-17 23:28 UTC (permalink / raw)
To: intel-xe@lists.freedesktop.org, Yang, Fei; +Cc: Brost, Matthew
On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
> From: Fei Yang <fei.yang@intel.com>
>
> Hardware requires the software to poll the valid bit and make sure
> it's
> cleared before issuing a new TLB invalidation request.
>
> Signed-off-by: Fei Yang <fei.yang@intel.com>
> ---
> drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> index ced58f46f846..4c2f87db3167 100644
> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval
> *tlb_inval, u32 seqno)
> struct xe_guc *guc = tlb_inval->private;
> struct xe_gt *gt = guc_to_gt(guc);
> struct xe_device *xe = guc_to_xe(guc);
> + int ret;
>
> /*
> * Returning -ECANCELED in this function is squashed at the
> caller and
> @@ -85,11 +86,25 @@ static int send_tlb_inval_ggtt(struct
> xe_tlb_inval *tlb_inval, u32 seqno)
>
> CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
> if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe)
> >= 20) {
> + /* Wait 1-second for the valid bit to be
> cleared */
> + ret = xe_mmio_wait32(mmio,
> PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> + 0, 1000 * USEC_PER_MSEC,
> NULL, false);
> + if (ret) {
> + pr_info("TLB INVAL cancelled due to
> uncleared valid bit\n");
> + return -ECANCELED;
> + }
Is there a reason we aren't waiting after the write to make sure the
invalidation completed? It seems like we should be serializing these
and at least making sure hardware completes the request rather than
just sending and hoping for the best.
Thanks,
Stuart
> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
> PVC_GUC_TLB_INV_DESC1_INVALID
> ATE);
> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
> PVC_GUC_TLB_INV_DESC0_VALID);
> } else {
> + /* Wait 1-second for the valid bit to be
> cleared */
> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR,
> GUC_TLB_INV_CR_INVALIDATE,
> + 0, 1000 * USEC_PER_MSEC,
> NULL, false);
> + if (ret) {
> + pr_info("TLB INVAL cancelled due to
> uncleared valid bit\n");
> + return -ECANCELED;
> + }
> xe_mmio_write32(mmio, GUC_TLB_INV_CR,
> GUC_TLB_INV_CR_INVALIDATE);
> }
^ permalink raw reply [flat|nested] 21+ messages in thread
* ✓ Xe.CI.BAT: success for drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-17 23:21 [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval fei.yang
` (2 preceding siblings ...)
2026-03-17 23:28 ` [PATCH] " Summers, Stuart
@ 2026-03-18 0:08 ` Patchwork
2026-03-19 12:33 ` ✓ Xe.CI.FULL: " Patchwork
4 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2026-03-18 0:08 UTC (permalink / raw)
To: fei.yang; +Cc: intel-xe
[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]
== Series Details ==
Series: drm/xe: Wait for HW clearance before issuing the next TLB inval.
URL : https://patchwork.freedesktop.org/series/163417/
State : success
== Summary ==
CI Bug Log - changes from xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1_BAT -> xe-pw-163417v1_BAT
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Participating hosts (14 -> 14)
------------------------------
No changes in participating hosts
Known issues
------------
Here are the changes found in xe-pw-163417v1_BAT that come from known issues:
### IGT changes ###
#### Possible fixes ####
* igt@xe_waitfence@engine:
- bat-dg2-oem2: [FAIL][1] ([Intel XE#6519]) -> [PASS][2]
[1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/bat-dg2-oem2/igt@xe_waitfence@engine.html
[2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/bat-dg2-oem2/igt@xe_waitfence@engine.html
[Intel XE#6519]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6519
Build changes
-------------
* Linux: xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1 -> xe-pw-163417v1
IGT_8807: 7f44d96d705f1583d689f1f8c2275b685b4ca11d @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1: c479cdf62a3f9a6101dd020abbc471f35142b3d1
xe-pw-163417v1: 163417v1
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/index.html
[-- Attachment #2: Type: text/html, Size: 2085 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* ✓ Xe.CI.FULL: success for drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-17 23:21 [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval fei.yang
` (3 preceding siblings ...)
2026-03-18 0:08 ` ✓ Xe.CI.BAT: success for " Patchwork
@ 2026-03-19 12:33 ` Patchwork
4 siblings, 0 replies; 21+ messages in thread
From: Patchwork @ 2026-03-19 12:33 UTC (permalink / raw)
To: fei.yang; +Cc: intel-xe
[-- Attachment #1: Type: text/plain, Size: 49924 bytes --]
== Series Details ==
Series: drm/xe: Wait for HW clearance before issuing the next TLB inval.
URL : https://patchwork.freedesktop.org/series/163417/
State : success
== Summary ==
CI Bug Log - changes from xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1_FULL -> xe-pw-163417v1_FULL
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Participating hosts (2 -> 2)
------------------------------
No changes in participating hosts
Known issues
------------
Here are the changes found in xe-pw-163417v1_FULL that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@core_hotunplug@hotunbind-rebind:
- shard-bmg: [PASS][1] -> [ABORT][2] ([Intel XE#7578])
[1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-7/igt@core_hotunplug@hotunbind-rebind.html
[2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-5/igt@core_hotunplug@hotunbind-rebind.html
* igt@core_hotunplug@hotunplug-rescan:
- shard-bmg: [PASS][3] -> [SKIP][4] ([Intel XE#6779])
[3]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@core_hotunplug@hotunplug-rescan.html
[4]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@core_hotunplug@hotunplug-rescan.html
* igt@kms_big_fb@linear-16bpp-rotate-270:
- shard-bmg: NOTRUN -> [SKIP][5] ([Intel XE#2327])
[5]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_big_fb@linear-16bpp-rotate-270.html
* igt@kms_big_fb@linear-max-hw-stride-64bpp-rotate-180-hflip:
- shard-bmg: NOTRUN -> [SKIP][6] ([Intel XE#7059] / [Intel XE#7085])
[6]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_big_fb@linear-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_big_fb@y-tiled-16bpp-rotate-180:
- shard-bmg: NOTRUN -> [SKIP][7] ([Intel XE#1124]) +1 other test skip
[7]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_big_fb@y-tiled-16bpp-rotate-180.html
* igt@kms_bw@connected-linear-tiling-2-displays-2560x1440p:
- shard-bmg: [PASS][8] -> [SKIP][9] ([Intel XE#2314] / [Intel XE#2894] / [Intel XE#7373])
[8]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-1/igt@kms_bw@connected-linear-tiling-2-displays-2560x1440p.html
[9]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-5/igt@kms_bw@connected-linear-tiling-2-displays-2560x1440p.html
* igt@kms_bw@linear-tiling-2-displays-2160x1440p:
- shard-bmg: NOTRUN -> [SKIP][10] ([Intel XE#367] / [Intel XE#7354])
[10]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_bw@linear-tiling-2-displays-2160x1440p.html
* igt@kms_ccs@ccs-on-another-bo-4-tiled-mtl-rc-ccs-cc:
- shard-bmg: NOTRUN -> [SKIP][11] ([Intel XE#2887]) +1 other test skip
[11]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_ccs@ccs-on-another-bo-4-tiled-mtl-rc-ccs-cc.html
* igt@kms_chamelium_edid@vga-edid-read:
- shard-bmg: NOTRUN -> [SKIP][12] ([Intel XE#2252])
[12]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_chamelium_edid@vga-edid-read.html
* igt@kms_content_protection@uevent-hdcp14:
- shard-bmg: NOTRUN -> [FAIL][13] ([Intel XE#6707] / [Intel XE#7439]) +1 other test fail
[13]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@kms_content_protection@uevent-hdcp14.html
* igt@kms_cursor_crc@cursor-onscreen-512x512:
- shard-bmg: NOTRUN -> [SKIP][14] ([Intel XE#2321] / [Intel XE#7355])
[14]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_cursor_crc@cursor-onscreen-512x512.html
* igt@kms_cursor_crc@cursor-rapid-movement-128x42:
- shard-bmg: NOTRUN -> [SKIP][15] ([Intel XE#2320])
[15]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_cursor_crc@cursor-rapid-movement-128x42.html
* igt@kms_cursor_legacy@cursorb-vs-flipa-atomic-transitions-varying-size:
- shard-bmg: [PASS][16] -> [SKIP][17] ([Intel XE#2291]) +2 other tests skip
[16]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_cursor_legacy@cursorb-vs-flipa-atomic-transitions-varying-size.html
[17]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_cursor_legacy@cursorb-vs-flipa-atomic-transitions-varying-size.html
* igt@kms_dp_aux_dev:
- shard-bmg: [PASS][18] -> [SKIP][19] ([Intel XE#3009])
[18]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-1/igt@kms_dp_aux_dev.html
[19]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-5/igt@kms_dp_aux_dev.html
* igt@kms_feature_discovery@display-2x:
- shard-bmg: [PASS][20] -> [SKIP][21] ([Intel XE#2373] / [Intel XE#7344])
[20]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_feature_discovery@display-2x.html
[21]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_feature_discovery@display-2x.html
* igt@kms_flip@2x-plain-flip:
- shard-bmg: [PASS][22] -> [SKIP][23] ([Intel XE#2316]) +1 other test skip
[22]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-7/igt@kms_flip@2x-plain-flip.html
[23]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-5/igt@kms_flip@2x-plain-flip.html
* igt@kms_flip@flip-vs-expired-vblank@c-edp1:
- shard-lnl: [PASS][24] -> [FAIL][25] ([Intel XE#301] / [Intel XE#3149])
[24]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-lnl-7/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html
[25]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-lnl-6/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html
* igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling:
- shard-bmg: NOTRUN -> [SKIP][26] ([Intel XE#7178] / [Intel XE#7351]) +3 other tests skip
[26]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-bmg: NOTRUN -> [SKIP][27] ([Intel XE#4141]) +2 other tests skip
[27]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen.html
* igt@kms_frontbuffer_tracking@fbc-argb161616f-draw-blt:
- shard-bmg: NOTRUN -> [SKIP][28] ([Intel XE#7061] / [Intel XE#7356]) +1 other test skip
[28]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbc-argb161616f-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcdrrs-rgb101010-draw-render:
- shard-bmg: NOTRUN -> [SKIP][29] ([Intel XE#2311]) +7 other tests skip
[29]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_frontbuffer_tracking@fbcdrrs-rgb101010-draw-render.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-blt:
- shard-bmg: NOTRUN -> [SKIP][30] ([Intel XE#2313]) +3 other tests skip
[30]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-blt.html
* igt@kms_hdr@static-toggle:
- shard-bmg: [PASS][31] -> [SKIP][32] ([Intel XE#1503])
[31]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-4/igt@kms_hdr@static-toggle.html
[32]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_hdr@static-toggle.html
* igt@kms_plane_multiple@2x-tiling-yf:
- shard-bmg: NOTRUN -> [SKIP][33] ([Intel XE#5021] / [Intel XE#7377])
[33]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_plane_multiple@2x-tiling-yf.html
* igt@kms_pm_backlight@basic-brightness:
- shard-bmg: NOTRUN -> [SKIP][34] ([Intel XE#7376] / [Intel XE#870])
[34]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@kms_pm_backlight@basic-brightness.html
* igt@kms_pm_dc@dc3co-vpb-simulation:
- shard-bmg: NOTRUN -> [SKIP][35] ([Intel XE#2391] / [Intel XE#6927])
[35]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_pm_dc@dc3co-vpb-simulation.html
* igt@kms_psr2_sf@fbc-psr2-cursor-plane-move-continuous-exceed-fully-sf:
- shard-bmg: NOTRUN -> [SKIP][36] ([Intel XE#1489]) +3 other tests skip
[36]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_psr2_sf@fbc-psr2-cursor-plane-move-continuous-exceed-fully-sf.html
* igt@kms_psr@psr-suspend:
- shard-bmg: NOTRUN -> [SKIP][37] ([Intel XE#2234] / [Intel XE#2850]) +2 other tests skip
[37]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_psr@psr-suspend.html
* igt@kms_setmode@invalid-clone-single-crtc-stealing:
- shard-bmg: [PASS][38] -> [SKIP][39] ([Intel XE#1435])
[38]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_setmode@invalid-clone-single-crtc-stealing.html
[39]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_setmode@invalid-clone-single-crtc-stealing.html
* igt@kms_sharpness_filter@filter-toggle:
- shard-bmg: NOTRUN -> [SKIP][40] ([Intel XE#6503])
[40]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@kms_sharpness_filter@filter-toggle.html
* igt@kms_vrr@cmrr:
- shard-bmg: NOTRUN -> [SKIP][41] ([Intel XE#2168] / [Intel XE#7444])
[41]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@kms_vrr@cmrr.html
* igt@kms_vrr@flip-suspend:
- shard-bmg: NOTRUN -> [SKIP][42] ([Intel XE#1499])
[42]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@kms_vrr@flip-suspend.html
* igt@xe_eudebug@vma-ufence:
- shard-bmg: NOTRUN -> [SKIP][43] ([Intel XE#4837]) +1 other test skip
[43]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_eudebug@vma-ufence.html
* igt@xe_eudebug_online@writes-caching-sram-bb-sram-target-vram:
- shard-bmg: NOTRUN -> [SKIP][44] ([Intel XE#4837] / [Intel XE#6665])
[44]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_eudebug_online@writes-caching-sram-bb-sram-target-vram.html
* igt@xe_exec_basic@multigpu-no-exec-basic-defer-bind:
- shard-bmg: NOTRUN -> [SKIP][45] ([Intel XE#2322] / [Intel XE#7372])
[45]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_exec_basic@multigpu-no-exec-basic-defer-bind.html
* igt@xe_exec_fault_mode@many-execqueues-multi-queue-userptr-invalidate-race-imm:
- shard-bmg: NOTRUN -> [SKIP][46] ([Intel XE#7136])
[46]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@xe_exec_fault_mode@many-execqueues-multi-queue-userptr-invalidate-race-imm.html
* igt@xe_exec_multi_queue@two-queues-basic-smem:
- shard-bmg: NOTRUN -> [SKIP][47] ([Intel XE#6874]) +4 other tests skip
[47]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_exec_multi_queue@two-queues-basic-smem.html
* igt@xe_exec_system_allocator@many-large-execqueues-mmap-free-nomemset:
- shard-bmg: [PASS][48] -> [SKIP][49] ([Intel XE#6703]) +120 other tests skip
[48]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_exec_system_allocator@many-large-execqueues-mmap-free-nomemset.html
[49]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_exec_system_allocator@many-large-execqueues-mmap-free-nomemset.html
* igt@xe_exec_system_allocator@pat-index-madvise-pat-idx-uc-multi-vma:
- shard-lnl: [PASS][50] -> [FAIL][51] ([Intel XE#5625])
[50]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-lnl-6/igt@xe_exec_system_allocator@pat-index-madvise-pat-idx-uc-multi-vma.html
[51]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-lnl-6/igt@xe_exec_system_allocator@pat-index-madvise-pat-idx-uc-multi-vma.html
* igt@xe_exec_system_allocator@process-many-large-execqueues-mmap-new-madvise:
- shard-bmg: [PASS][52] -> [SKIP][53] ([Intel XE#6557] / [Intel XE#6703]) +1 other test skip
[52]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_exec_system_allocator@process-many-large-execqueues-mmap-new-madvise.html
[53]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_exec_system_allocator@process-many-large-execqueues-mmap-new-madvise.html
* igt@xe_exec_system_allocator@twice-large-mmap:
- shard-bmg: [PASS][54] -> [DMESG-FAIL][55] ([Intel XE#5545] / [Intel XE#6652])
[54]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_exec_system_allocator@twice-large-mmap.html
[55]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_exec_system_allocator@twice-large-mmap.html
* igt@xe_exec_threads@threads-multi-queue-cm-userptr-invalidate-race:
- shard-bmg: NOTRUN -> [SKIP][56] ([Intel XE#7138]) +1 other test skip
[56]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_exec_threads@threads-multi-queue-cm-userptr-invalidate-race.html
* igt@xe_query@multigpu-query-engines:
- shard-bmg: NOTRUN -> [SKIP][57] ([Intel XE#944])
[57]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@xe_query@multigpu-query-engines.html
#### Possible fixes ####
* igt@core_hotunplug@hotreplug:
- shard-bmg: [ABORT][58] ([Intel XE#7578]) -> [PASS][59]
[58]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-1/igt@core_hotunplug@hotreplug.html
[59]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@core_hotunplug@hotreplug.html
* igt@kms_bw@connected-linear-tiling-2-displays-3840x2160p:
- shard-bmg: [SKIP][60] ([Intel XE#2314] / [Intel XE#2894] / [Intel XE#7373]) -> [PASS][61]
[60]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@kms_bw@connected-linear-tiling-2-displays-3840x2160p.html
[61]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-7/igt@kms_bw@connected-linear-tiling-2-displays-3840x2160p.html
* igt@kms_cursor_edge_walk@256x256-right-edge:
- shard-bmg: [FAIL][62] ([Intel XE#6841]) -> [PASS][63] +1 other test pass
[62]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_cursor_edge_walk@256x256-right-edge.html
[63]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-1/igt@kms_cursor_edge_walk@256x256-right-edge.html
* igt@kms_flip@2x-nonexisting-fb:
- shard-bmg: [SKIP][64] ([Intel XE#2316]) -> [PASS][65] +4 other tests pass
[64]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@kms_flip@2x-nonexisting-fb.html
[65]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-10/igt@kms_flip@2x-nonexisting-fb.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-lnl: [FAIL][66] ([Intel XE#301]) -> [PASS][67]
[66]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-lnl-7/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[67]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-lnl-6/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_hdr@static-swap:
- shard-bmg: [SKIP][68] ([Intel XE#1503]) -> [PASS][69]
[68]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@kms_hdr@static-swap.html
[69]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-10/igt@kms_hdr@static-swap.html
* igt@xe_evict@evict-beng-mixed-many-threads-small:
- shard-bmg: [INCOMPLETE][70] ([Intel XE#6321]) -> [PASS][71]
[70]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-8/igt@xe_evict@evict-beng-mixed-many-threads-small.html
[71]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_evict@evict-beng-mixed-many-threads-small.html
* igt@xe_module_load@load:
- shard-bmg: ([PASS][72], [PASS][73], [PASS][74], [PASS][75], [PASS][76], [PASS][77], [PASS][78], [PASS][79], [PASS][80], [PASS][81], [PASS][82], [PASS][83], [PASS][84], [PASS][85], [PASS][86], [PASS][87], [PASS][88], [PASS][89], [PASS][90], [PASS][91], [SKIP][92], [PASS][93], [PASS][94], [PASS][95], [PASS][96], [PASS][97]) ([Intel XE#2457] / [Intel XE#7405]) -> ([PASS][98], [PASS][99], [PASS][100], [PASS][101], [PASS][102], [PASS][103], [PASS][104], [PASS][105], [PASS][106], [PASS][107], [PASS][108], [PASS][109], [PASS][110], [PASS][111], [PASS][112], [PASS][113], [PASS][114], [PASS][115], [PASS][116], [PASS][117], [PASS][118], [PASS][119], [PASS][120], [PASS][121], [PASS][122])
[72]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@xe_module_load@load.html
[73]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@xe_module_load@load.html
[74]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-10/igt@xe_module_load@load.html
[75]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-7/igt@xe_module_load@load.html
[76]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@xe_module_load@load.html
[77]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-10/igt@xe_module_load@load.html
[78]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-10/igt@xe_module_load@load.html
[79]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-4/igt@xe_module_load@load.html
[80]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-3/igt@xe_module_load@load.html
[81]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-3/igt@xe_module_load@load.html
[82]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-8/igt@xe_module_load@load.html
[83]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-7/igt@xe_module_load@load.html
[84]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_module_load@load.html
[85]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_module_load@load.html
[86]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_module_load@load.html
[87]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-1/igt@xe_module_load@load.html
[88]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-1/igt@xe_module_load@load.html
[89]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-6/igt@xe_module_load@load.html
[90]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-6/igt@xe_module_load@load.html
[91]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-3/igt@xe_module_load@load.html
[92]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@xe_module_load@load.html
[93]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-4/igt@xe_module_load@load.html
[94]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-8/igt@xe_module_load@load.html
[95]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-8/igt@xe_module_load@load.html
[96]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-9/igt@xe_module_load@load.html
[97]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-9/igt@xe_module_load@load.html
[98]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-9/igt@xe_module_load@load.html
[99]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-5/igt@xe_module_load@load.html
[100]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-5/igt@xe_module_load@load.html
[101]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-8/igt@xe_module_load@load.html
[102]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-8/igt@xe_module_load@load.html
[103]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-8/igt@xe_module_load@load.html
[104]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-1/igt@xe_module_load@load.html
[105]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@xe_module_load@load.html
[106]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_module_load@load.html
[107]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_module_load@load.html
[108]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-10/igt@xe_module_load@load.html
[109]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-1/igt@xe_module_load@load.html
[110]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@xe_module_load@load.html
[111]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-10/igt@xe_module_load@load.html
[112]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-10/igt@xe_module_load@load.html
[113]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@xe_module_load@load.html
[114]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-6/igt@xe_module_load@load.html
[115]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-7/igt@xe_module_load@load.html
[116]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-7/igt@xe_module_load@load.html
[117]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@xe_module_load@load.html
[118]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-9/igt@xe_module_load@load.html
[119]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-9/igt@xe_module_load@load.html
[120]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_module_load@load.html
[121]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_module_load@load.html
[122]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-4/igt@xe_module_load@load.html
* igt@xe_pm@d3hot-mmap-vram:
- shard-bmg: [DMESG-WARN][123] -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-3/igt@xe_pm@d3hot-mmap-vram.html
[124]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-9/igt@xe_pm@d3hot-mmap-vram.html
#### Warnings ####
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-bmg: [SKIP][125] ([Intel XE#1124]) -> [SKIP][126] ([Intel XE#6703]) +1 other test skip
[125]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
[126]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_bw@connected-linear-tiling-2-displays-2160x1440p:
- shard-bmg: [SKIP][127] ([Intel XE#7621]) -> [SKIP][128] ([Intel XE#6703])
[127]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_bw@connected-linear-tiling-2-displays-2160x1440p.html
[128]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_bw@connected-linear-tiling-2-displays-2160x1440p.html
* igt@kms_ccs@missing-ccs-buffer-y-tiled-gen12-rc-ccs-cc:
- shard-bmg: [SKIP][129] ([Intel XE#2887]) -> [SKIP][130] ([Intel XE#6703]) +3 other tests skip
[129]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_ccs@missing-ccs-buffer-y-tiled-gen12-rc-ccs-cc.html
[130]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_ccs@missing-ccs-buffer-y-tiled-gen12-rc-ccs-cc.html
* igt@kms_chamelium_edid@dp-edid-read:
- shard-bmg: [SKIP][131] ([Intel XE#2252]) -> [SKIP][132] ([Intel XE#6703]) +1 other test skip
[131]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_chamelium_edid@dp-edid-read.html
[132]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_chamelium_edid@dp-edid-read.html
* igt@kms_content_protection@atomic-dpms-hdcp14:
- shard-bmg: [FAIL][133] ([Intel XE#3304] / [Intel XE#7374]) -> [SKIP][134] ([Intel XE#7194])
[133]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-4/igt@kms_content_protection@atomic-dpms-hdcp14.html
[134]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_content_protection@atomic-dpms-hdcp14.html
* igt@kms_content_protection@dp-mst-type-1:
- shard-bmg: [SKIP][135] ([Intel XE#2390] / [Intel XE#6974]) -> [SKIP][136] ([Intel XE#6703])
[135]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_content_protection@dp-mst-type-1.html
[136]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_content_protection@dp-mst-type-1.html
* igt@kms_content_protection@lic-type-0:
- shard-bmg: [FAIL][137] ([Intel XE#1178] / [Intel XE#3304] / [Intel XE#7374]) -> [SKIP][138] ([Intel XE#2341])
[137]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-1/igt@kms_content_protection@lic-type-0.html
[138]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-5/igt@kms_content_protection@lic-type-0.html
* igt@kms_content_protection@lic-type-0-hdcp14:
- shard-bmg: [FAIL][139] ([Intel XE#1178] / [Intel XE#3304] / [Intel XE#7374]) -> [SKIP][140] ([Intel XE#7194])
[139]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-4/igt@kms_content_protection@lic-type-0-hdcp14.html
[140]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_content_protection@lic-type-0-hdcp14.html
* igt@kms_cursor_crc@cursor-random-256x85:
- shard-bmg: [SKIP][141] ([Intel XE#2320]) -> [SKIP][142] ([Intel XE#6703])
[141]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_cursor_crc@cursor-random-256x85.html
[142]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_cursor_crc@cursor-random-256x85.html
* igt@kms_cursor_crc@cursor-sliding-512x512:
- shard-bmg: [SKIP][143] ([Intel XE#2321] / [Intel XE#7355]) -> [SKIP][144] ([Intel XE#6703])
[143]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_cursor_crc@cursor-sliding-512x512.html
[144]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_cursor_crc@cursor-sliding-512x512.html
* igt@kms_dsc@dsc-with-formats:
- shard-bmg: [SKIP][145] ([Intel XE#2244]) -> [SKIP][146] ([Intel XE#6703])
[145]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_dsc@dsc-with-formats.html
[146]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_dsc@dsc-with-formats.html
* igt@kms_flip@flip-vs-expired-vblank:
- shard-lnl: [FAIL][147] ([Intel XE#301]) -> [FAIL][148] ([Intel XE#301] / [Intel XE#3149])
[147]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-lnl-7/igt@kms_flip@flip-vs-expired-vblank.html
[148]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-lnl-6/igt@kms_flip@flip-vs-expired-vblank.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling:
- shard-bmg: [SKIP][149] ([Intel XE#7178] / [Intel XE#7351]) -> [SKIP][150] ([Intel XE#6703])
[149]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling.html
[150]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling.html
* igt@kms_frontbuffer_tracking@drrs-1p-primscrn-pri-shrfb-draw-mmap-wc:
- shard-bmg: [SKIP][151] ([Intel XE#2311]) -> [SKIP][152] ([Intel XE#6557] / [Intel XE#6703])
[151]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_frontbuffer_tracking@drrs-1p-primscrn-pri-shrfb-draw-mmap-wc.html
[152]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_frontbuffer_tracking@drrs-1p-primscrn-pri-shrfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@drrs-2p-primscrn-indfb-pgflip-blt:
- shard-bmg: [SKIP][153] ([Intel XE#2311]) -> [SKIP][154] ([Intel XE#2312]) +11 other tests skip
[153]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-4/igt@kms_frontbuffer_tracking@drrs-2p-primscrn-indfb-pgflip-blt.html
[154]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_frontbuffer_tracking@drrs-2p-primscrn-indfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@drrs-2p-primscrn-spr-indfb-draw-render:
- shard-bmg: [SKIP][155] ([Intel XE#2311]) -> [SKIP][156] ([Intel XE#6703]) +6 other tests skip
[155]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_frontbuffer_tracking@drrs-2p-primscrn-spr-indfb-draw-render.html
[156]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_frontbuffer_tracking@drrs-2p-primscrn-spr-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-wc:
- shard-bmg: [SKIP][157] ([Intel XE#2312]) -> [SKIP][158] ([Intel XE#4141]) +7 other tests skip
[157]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-3/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-wc.html
[158]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-9/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt:
- shard-bmg: [SKIP][159] ([Intel XE#4141]) -> [SKIP][160] ([Intel XE#6703]) +1 other test skip
[159]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt.html
[160]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-onoff:
- shard-bmg: [SKIP][161] ([Intel XE#4141]) -> [SKIP][162] ([Intel XE#2312]) +5 other tests skip
[161]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-onoff.html
[162]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-onoff.html
* igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-shrfb-plflip-blt:
- shard-bmg: [SKIP][163] ([Intel XE#2312]) -> [SKIP][164] ([Intel XE#2311]) +7 other tests skip
[163]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-shrfb-plflip-blt.html
[164]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-10/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-shrfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@fbcdrrs-tiling-y:
- shard-bmg: [SKIP][165] ([Intel XE#2352] / [Intel XE#7399]) -> [SKIP][166] ([Intel XE#6703])
[165]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_frontbuffer_tracking@fbcdrrs-tiling-y.html
[166]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_frontbuffer_tracking@fbcdrrs-tiling-y.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-shrfb-pgflip-blt:
- shard-bmg: [SKIP][167] ([Intel XE#2312]) -> [SKIP][168] ([Intel XE#2313]) +9 other tests skip
[167]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-shrfb-pgflip-blt.html
[168]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-10/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-shrfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-blt:
- shard-bmg: [SKIP][169] ([Intel XE#2313]) -> [SKIP][170] ([Intel XE#6703]) +7 other tests skip
[169]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-blt.html
[170]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-cur-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-draw-render:
- shard-bmg: [SKIP][171] ([Intel XE#2313]) -> [SKIP][172] ([Intel XE#2312]) +10 other tests skip
[171]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-draw-render.html
[172]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-3/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-draw-render.html
* igt@kms_joiner@basic-big-joiner:
- shard-bmg: [SKIP][173] ([Intel XE#6901]) -> [SKIP][174] ([Intel XE#6703])
[173]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_joiner@basic-big-joiner.html
[174]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_joiner@basic-big-joiner.html
* igt@kms_multipipe_modeset@basic-max-pipe-crc-check:
- shard-bmg: [SKIP][175] ([Intel XE#7591]) -> [SKIP][176] ([Intel XE#6703])
[175]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_multipipe_modeset@basic-max-pipe-crc-check.html
[176]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_multipipe_modeset@basic-max-pipe-crc-check.html
* igt@kms_plane@pixel-format-4-tiled-mtl-rc-ccs-modifier:
- shard-bmg: [SKIP][177] ([Intel XE#7283]) -> [SKIP][178] ([Intel XE#6703])
[177]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_plane@pixel-format-4-tiled-mtl-rc-ccs-modifier.html
[178]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_plane@pixel-format-4-tiled-mtl-rc-ccs-modifier.html
* igt@kms_plane_multiple@2x-tiling-y:
- shard-bmg: [SKIP][179] ([Intel XE#4596]) -> [SKIP][180] ([Intel XE#5021] / [Intel XE#7377])
[179]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-5/igt@kms_plane_multiple@2x-tiling-y.html
[180]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-7/igt@kms_plane_multiple@2x-tiling-y.html
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75:
- shard-bmg: [SKIP][181] ([Intel XE#2763] / [Intel XE#6886]) -> [SKIP][182] ([Intel XE#6703])
[181]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75.html
[182]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75.html
* igt@kms_psr2_sf@pr-primary-plane-update-sf-dmg-area:
- shard-bmg: [SKIP][183] ([Intel XE#1489]) -> [SKIP][184] ([Intel XE#6703])
[183]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_psr2_sf@pr-primary-plane-update-sf-dmg-area.html
[184]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_psr2_sf@pr-primary-plane-update-sf-dmg-area.html
* igt@kms_psr@pr-cursor-plane-onoff:
- shard-bmg: [SKIP][185] ([Intel XE#2234] / [Intel XE#2850]) -> [SKIP][186] ([Intel XE#6703]) +2 other tests skip
[185]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_psr@pr-cursor-plane-onoff.html
[186]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_psr@pr-cursor-plane-onoff.html
* igt@kms_sharpness_filter@filter-basic:
- shard-bmg: [SKIP][187] ([Intel XE#6503]) -> [SKIP][188] ([Intel XE#6703])
[187]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@kms_sharpness_filter@filter-basic.html
[188]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@kms_sharpness_filter@filter-basic.html
* igt@xe_eudebug@multigpu-basic-client:
- shard-bmg: [SKIP][189] ([Intel XE#4837]) -> [SKIP][190] ([Intel XE#6703])
[189]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_eudebug@multigpu-basic-client.html
[190]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_eudebug@multigpu-basic-client.html
* igt@xe_evict@evict-threads-small-multi-queue:
- shard-bmg: [SKIP][191] ([Intel XE#7140]) -> [SKIP][192] ([Intel XE#6703])
[191]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_evict@evict-threads-small-multi-queue.html
[192]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_evict@evict-threads-small-multi-queue.html
* igt@xe_exec_basic@multigpu-many-execqueues-many-vm-null-defer-bind:
- shard-bmg: [SKIP][193] ([Intel XE#2322] / [Intel XE#7372]) -> [SKIP][194] ([Intel XE#6703]) +1 other test skip
[193]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_exec_basic@multigpu-many-execqueues-many-vm-null-defer-bind.html
[194]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_exec_basic@multigpu-many-execqueues-many-vm-null-defer-bind.html
* igt@xe_exec_fault_mode@twice-multi-queue-userptr-invalidate-race-imm:
- shard-bmg: [SKIP][195] ([Intel XE#7136]) -> [SKIP][196] ([Intel XE#6703]) +1 other test skip
[195]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_exec_fault_mode@twice-multi-queue-userptr-invalidate-race-imm.html
[196]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_exec_fault_mode@twice-multi-queue-userptr-invalidate-race-imm.html
* igt@xe_exec_multi_queue@few-execs-preempt-mode-close-fd-smem:
- shard-bmg: [SKIP][197] ([Intel XE#6874]) -> [SKIP][198] ([Intel XE#6703]) +5 other tests skip
[197]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_exec_multi_queue@few-execs-preempt-mode-close-fd-smem.html
[198]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_exec_multi_queue@few-execs-preempt-mode-close-fd-smem.html
* igt@xe_exec_threads@threads-multi-queue-fd-userptr-rebind:
- shard-bmg: [SKIP][199] ([Intel XE#7138]) -> [SKIP][200] ([Intel XE#6703]) +1 other test skip
[199]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_exec_threads@threads-multi-queue-fd-userptr-rebind.html
[200]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_exec_threads@threads-multi-queue-fd-userptr-rebind.html
* igt@xe_pm@d3cold-mmap-system:
- shard-bmg: [SKIP][201] ([Intel XE#2284] / [Intel XE#7370]) -> [SKIP][202] ([Intel XE#6703])
[201]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1/shard-bmg-2/igt@xe_pm@d3cold-mmap-system.html
[202]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/shard-bmg-2/igt@xe_pm@d3cold-mmap-system.html
[Intel XE#1124]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1124
[Intel XE#1178]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1178
[Intel XE#1435]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1435
[Intel XE#1489]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1489
[Intel XE#1499]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1499
[Intel XE#1503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1503
[Intel XE#2168]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2168
[Intel XE#2234]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2234
[Intel XE#2244]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2244
[Intel XE#2252]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2252
[Intel XE#2284]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2284
[Intel XE#2291]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2291
[Intel XE#2311]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2311
[Intel XE#2312]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2312
[Intel XE#2313]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2313
[Intel XE#2314]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2314
[Intel XE#2316]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2316
[Intel XE#2320]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2320
[Intel XE#2321]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2321
[Intel XE#2322]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2322
[Intel XE#2327]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2327
[Intel XE#2341]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2341
[Intel XE#2352]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2352
[Intel XE#2373]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2373
[Intel XE#2390]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2390
[Intel XE#2391]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2391
[Intel XE#2457]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2457
[Intel XE#2763]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2763
[Intel XE#2850]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2850
[Intel XE#2887]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2887
[Intel XE#2894]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2894
[Intel XE#3009]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3009
[Intel XE#301]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/301
[Intel XE#3149]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3149
[Intel XE#3304]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3304
[Intel XE#367]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/367
[Intel XE#4141]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4141
[Intel XE#4596]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4596
[Intel XE#4837]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4837
[Intel XE#5021]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5021
[Intel XE#5545]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5545
[Intel XE#5625]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5625
[Intel XE#6321]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6321
[Intel XE#6503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6503
[Intel XE#6557]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6557
[Intel XE#6652]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6652
[Intel XE#6665]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6665
[Intel XE#6703]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6703
[Intel XE#6707]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6707
[Intel XE#6779]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6779
[Intel XE#6841]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6841
[Intel XE#6874]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6874
[Intel XE#6886]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6886
[Intel XE#6901]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6901
[Intel XE#6927]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6927
[Intel XE#6974]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6974
[Intel XE#7059]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7059
[Intel XE#7061]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7061
[Intel XE#7085]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7085
[Intel XE#7136]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7136
[Intel XE#7138]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7138
[Intel XE#7140]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7140
[Intel XE#7178]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7178
[Intel XE#7194]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7194
[Intel XE#7283]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7283
[Intel XE#7344]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7344
[Intel XE#7351]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7351
[Intel XE#7354]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7354
[Intel XE#7355]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7355
[Intel XE#7356]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7356
[Intel XE#7370]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7370
[Intel XE#7372]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7372
[Intel XE#7373]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7373
[Intel XE#7374]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7374
[Intel XE#7376]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7376
[Intel XE#7377]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7377
[Intel XE#7399]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7399
[Intel XE#7405]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7405
[Intel XE#7439]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7439
[Intel XE#7444]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7444
[Intel XE#7578]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7578
[Intel XE#7591]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7591
[Intel XE#7621]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7621
[Intel XE#870]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/870
[Intel XE#944]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/944
Build changes
-------------
* Linux: xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1 -> xe-pw-163417v1
IGT_8807: 7f44d96d705f1583d689f1f8c2275b685b4ca11d @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
xe-4740-c479cdf62a3f9a6101dd020abbc471f35142b3d1: c479cdf62a3f9a6101dd020abbc471f35142b3d1
xe-pw-163417v1: 163417v1
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-163417v1/index.html
[-- Attachment #2: Type: text/html, Size: 58487 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-17 23:28 ` [PATCH] " Summers, Stuart
@ 2026-03-22 5:35 ` Matthew Brost
2026-03-24 20:39 ` Yang, Fei
0 siblings, 1 reply; 21+ messages in thread
From: Matthew Brost @ 2026-03-22 5:35 UTC (permalink / raw)
To: Summers, Stuart; +Cc: intel-xe@lists.freedesktop.org, Yang, Fei
On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart wrote:
> On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
> > From: Fei Yang <fei.yang@intel.com>
> >
> > Hardware requires the software to poll the valid bit and make sure
> > it's
> > cleared before issuing a new TLB invalidation request.
> >
> > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > index ced58f46f846..4c2f87db3167 100644
> > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval
> > *tlb_inval, u32 seqno)
> > struct xe_guc *guc = tlb_inval->private;
> > struct xe_gt *gt = guc_to_gt(guc);
> > struct xe_device *xe = guc_to_xe(guc);
> > + int ret;
> >
> > /*
> > * Returning -ECANCELED in this function is squashed at the
> > caller and
> > @@ -85,11 +86,25 @@ static int send_tlb_inval_ggtt(struct
> > xe_tlb_inval *tlb_inval, u32 seqno)
> >
> > CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
> > if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe)
> > >= 20) {
> > + /* Wait 1-second for the valid bit to be
> > cleared */
> > + ret = xe_mmio_wait32(mmio,
> > PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > + 0, 1000 * USEC_PER_MSEC,
> > NULL, false);
> > + if (ret) {
> > + pr_info("TLB INVAL cancelled due to
> > uncleared valid bit\n");
> > + return -ECANCELED;
> > + }
>
> Is there a reason we aren't waiting after the write to make sure the
> invalidation completed? It seems like we should be serializing these
> and at least making sure hardware completes the request rather than
> just sending and hoping for the best.
Yes, this is correct—we should after wait issue *if* this code is
actually needed.
This is early Xe code from me, and it’s questionable whether it’s even
required. Typically, if the CTs are not live, the GuC isn’t doing
anything meaningful in terms of referencing memory that the KMD is
moving around (which would require an invalidation). So this entire flow
of issuing a GAM port TLB invalidation is, again, questionable.
So I'd suggest move the wait after issue, plus throw in:
“XXX: Why do we need to invalidate GGTT memory when the CTs are not
live? This suggests the GuC is still in the load phase. Investigate and
remove this code once confirmed.'
Matt
>
> Thanks,
> Stuart
>
> > xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
> > PVC_GUC_TLB_INV_DESC1_INVALID
> > ATE);
> > xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
> > PVC_GUC_TLB_INV_DESC0_VALID);
> > } else {
> > + /* Wait 1-second for the valid bit to be
> > cleared */
> > + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR,
> > GUC_TLB_INV_CR_INVALIDATE,
> > + 0, 1000 * USEC_PER_MSEC,
> > NULL, false);
> > + if (ret) {
> > + pr_info("TLB INVAL cancelled due to
> > uncleared valid bit\n");
> > + return -ECANCELED;
> > + }
> > xe_mmio_write32(mmio, GUC_TLB_INV_CR,
> > GUC_TLB_INV_CR_INVALIDATE);
> > }
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-22 5:35 ` Matthew Brost
@ 2026-03-24 20:39 ` Yang, Fei
2026-03-24 20:53 ` Matthew Brost
0 siblings, 1 reply; 21+ messages in thread
From: Yang, Fei @ 2026-03-24 20:39 UTC (permalink / raw)
To: Brost, Matthew, Summers, Stuart; +Cc: intel-xe@lists.freedesktop.org
> On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart wrote:
>> On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
>>> From: Fei Yang <fei.yang@intel.com>
>>>
>>> Hardware requires the software to poll the valid bit and make sure
>>> it's cleared before issuing a new TLB invalidation request.
>>>
>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
>>> 1 file changed, 15 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
>>> b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
>>> index ced58f46f846..4c2f87db3167 100644
>>> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
>>> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
>>> @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval
>>> *tlb_inval, u32 seqno)
>>> struct xe_guc *guc = tlb_inval->private;
>>> struct xe_gt *gt = guc_to_gt(guc);
>>> struct xe_device *xe = guc_to_xe(guc);
>>> + int ret;
>>>
>>> /*
>>> * Returning -ECANCELED in this function is squashed at the
>>> caller and @@ -85,11 +86,25 @@ static int send_tlb_inval_ggtt(struct
>>> xe_tlb_inval *tlb_inval, u32 seqno)
>>>
>>> CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt),
>>> XE_FW_GT);
>>> if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe)
>>> >= 20) {
>>> + /* Wait 1-second for the valid bit to be
>>> cleared */
>>> + ret = xe_mmio_wait32(mmio,
>>> PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
>>> + 0, 1000 *
>>> +USEC_PER_MSEC,
>>> NULL, false);
>>> + if (ret) {
>>> + pr_info("TLB INVAL cancelled due to
>>> uncleared valid bit\n");
>>> + return -ECANCELED;
>>> + }
>>
>> Is there a reason we aren't waiting after the write to make sure the
>> invalidation completed? It seems like we should be serializing these
>> and at least making sure hardware completes the request rather than
>> just sending and hoping for the best.
>
> Yes, this is correct—we should after wait issue *if* this code is actually needed.
No, the issue is that software cannot issue another TLB invalidation request while the ongoing
one has not been completed yet. Otherwise the hardware could potentially lockup.
So we need to make sure the valid bit is cleared before issuing another TLB invalidation request.
> This is early Xe code from me, and it’s questionable whether it’s even required.
This seems to be required, otherwise modprobe would fail at golden context submission,
[ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0: hwe ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> Typically, if the CTs are not live, the GuC isn’t doing anything meaningful in terms of
> referencing memory that the KMD is moving around (which would require an invalidation).
> So this entire flow of issuing a GAM port TLB invalidation is, again, questionable.
>
> So I'd suggest move the wait after issue, plus throw in:
>
> “XXX: Why do we need to invalidate GGTT memory when the CTs are not live? This suggests
> the GuC is still in the load phase. Investigate and remove this code once confirmed.'
The issue is a consequence of an earlier failure which caused the CT to be disabled. And the KMD
sees a bunch of TLB invalidation timeouts.
At this time I would expect a GT reset, but that is not how Xe behaves (the ole i915 driver triggers
a GT reset on TLB invalidation timeout if I remember correctly)
-Fei
> Matt
>
>>
>> Thanks,
>> Stuart
>>
>>> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
>>>
>>> PVC_GUC_TLB_INV_DESC1_INVALID ATE);
>>> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
>>>
>>> PVC_GUC_TLB_INV_DESC0_VALID);
>>> } else {
>>> + /* Wait 1-second for the valid bit to be
>>> cleared */
>>> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR,
>>> GUC_TLB_INV_CR_INVALIDATE,
>>> + 0, 1000 *
>>> +USEC_PER_MSEC,
>>> NULL, false);
>>> + if (ret) {
>>> + pr_info("TLB INVAL cancelled due to
>>> uncleared valid bit\n");
>>> + return -ECANCELED;
>>> + }
>>> xe_mmio_write32(mmio, GUC_TLB_INV_CR,
>>> GUC_TLB_INV_CR_INVALIDATE);
>>> }
>>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-24 20:39 ` Yang, Fei
@ 2026-03-24 20:53 ` Matthew Brost
2026-03-24 20:58 ` Matthew Brost
0 siblings, 1 reply; 21+ messages in thread
From: Matthew Brost @ 2026-03-24 20:53 UTC (permalink / raw)
To: Yang, Fei; +Cc: Summers, Stuart, intel-xe@lists.freedesktop.org
On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart wrote:
> >> On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
> >>> From: Fei Yang <fei.yang@intel.com>
> >>>
> >>> Hardware requires the software to poll the valid bit and make sure
> >>> it's cleared before issuing a new TLB invalidation request.
> >>>
> >>> Signed-off-by: Fei Yang <fei.yang@intel.com>
> >>> ---
> >>> drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
> >>> 1 file changed, 15 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> >>> b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> >>> index ced58f46f846..4c2f87db3167 100644
> >>> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> >>> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> >>> @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval
> >>> *tlb_inval, u32 seqno)
> >>> struct xe_guc *guc = tlb_inval->private;
> >>> struct xe_gt *gt = guc_to_gt(guc);
> >>> struct xe_device *xe = guc_to_xe(guc);
> >>> + int ret;
> >>>
> >>> /*
> >>> * Returning -ECANCELED in this function is squashed at the
> >>> caller and @@ -85,11 +86,25 @@ static int send_tlb_inval_ggtt(struct
> >>> xe_tlb_inval *tlb_inval, u32 seqno)
> >>>
> >>> CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt),
> >>> XE_FW_GT);
> >>> if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe)
> >>> >= 20) {
> >>> + /* Wait 1-second for the valid bit to be
> >>> cleared */
> >>> + ret = xe_mmio_wait32(mmio,
> >>> PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> >>> + 0, 1000 *
> >>> +USEC_PER_MSEC,
> >>> NULL, false);
> >>> + if (ret) {
> >>> + pr_info("TLB INVAL cancelled due to
> >>> uncleared valid bit\n");
> >>> + return -ECANCELED;
> >>> + }
> >>
> >> Is there a reason we aren't waiting after the write to make sure the
> >> invalidation completed? It seems like we should be serializing these
> >> and at least making sure hardware completes the request rather than
> >> just sending and hoping for the best.
> >
> > Yes, this is correct—we should after wait issue *if* this code is actually needed.
>
> No, the issue is that software cannot issue another TLB invalidation request while the ongoing
> one has not been completed yet. Otherwise the hardware could potentially lockup.
> So we need to make sure the valid bit is cleared before issuing another TLB invalidation request.
>
Yes, but we signal the TLB invalidation fence as complete without
waiting for the hardware to actually finish. The locking here is also
incorrect for MMIO-based invalidations, now that I think about it. What
really needs to happen is:
- In send_tlb_inval_ggtt(), if the MMIO path is taken, acquire a per-GT
MMIO TLB invalidation lock after obtaining the FW
- Issue the TLB invalidation
- Wait for the valid bit to clear
- Release the GT MMIO TLB invalidation lock
Without this lock, two threads could both observe the valid bit clearing
and then both attempt to issue invalidations, clobbering each other.
> > This is early Xe code from me, and it’s questionable whether it’s even required.
>
> This seems to be required, otherwise modprobe would fail at golden context submission,
> [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0: hwe ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
>
I’m somewhat surprised by this. A better solution might be to drop the
MMIO GT invalidation code in xe_guc_tlb_inval.c and instead issue an
MMIO GGTT invalidation whenever we reload the GuC.
We can defer trying this until later, as it is a riskier change.
Matt
> > Typically, if the CTs are not live, the GuC isn’t doing anything meaningful in terms of
> > referencing memory that the KMD is moving around (which would require an invalidation).
> > So this entire flow of issuing a GAM port TLB invalidation is, again, questionable.
> >
> > So I'd suggest move the wait after issue, plus throw in:
> >
> > “XXX: Why do we need to invalidate GGTT memory when the CTs are not live? This suggests
> > the GuC is still in the load phase. Investigate and remove this code once confirmed.'
>
> The issue is a consequence of an earlier failure which caused the CT to be disabled. And the KMD
> sees a bunch of TLB invalidation timeouts.
> At this time I would expect a GT reset, but that is not how Xe behaves (the ole i915 driver triggers
> a GT reset on TLB invalidation timeout if I remember correctly)
>
> -Fei
>
> > Matt
> >
> >>
> >> Thanks,
> >> Stuart
> >>
> >>> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
> >>>
> >>> PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> >>> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
> >>>
> >>> PVC_GUC_TLB_INV_DESC0_VALID);
> >>> } else {
> >>> + /* Wait 1-second for the valid bit to be
> >>> cleared */
> >>> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR,
> >>> GUC_TLB_INV_CR_INVALIDATE,
> >>> + 0, 1000 *
> >>> +USEC_PER_MSEC,
> >>> NULL, false);
> >>> + if (ret) {
> >>> + pr_info("TLB INVAL cancelled due to
> >>> uncleared valid bit\n");
> >>> + return -ECANCELED;
> >>> + }
> >>> xe_mmio_write32(mmio, GUC_TLB_INV_CR,
> >>> GUC_TLB_INV_CR_INVALIDATE);
> >>> }
> >>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-24 20:53 ` Matthew Brost
@ 2026-03-24 20:58 ` Matthew Brost
2026-03-24 21:10 ` Summers, Stuart
0 siblings, 1 reply; 21+ messages in thread
From: Matthew Brost @ 2026-03-24 20:58 UTC (permalink / raw)
To: Yang, Fei; +Cc: Summers, Stuart, intel-xe@lists.freedesktop.org
On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost wrote:
> On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart wrote:
> > >> On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
> > >>> From: Fei Yang <fei.yang@intel.com>
> > >>>
> > >>> Hardware requires the software to poll the valid bit and make sure
> > >>> it's cleared before issuing a new TLB invalidation request.
> > >>>
> > >>> Signed-off-by: Fei Yang <fei.yang@intel.com>
> > >>> ---
> > >>> drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
> > >>> 1 file changed, 15 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > >>> b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > >>> index ced58f46f846..4c2f87db3167 100644
> > >>> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > >>> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > >>> @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval
> > >>> *tlb_inval, u32 seqno)
> > >>> struct xe_guc *guc = tlb_inval->private;
> > >>> struct xe_gt *gt = guc_to_gt(guc);
> > >>> struct xe_device *xe = guc_to_xe(guc);
> > >>> + int ret;
> > >>>
> > >>> /*
> > >>> * Returning -ECANCELED in this function is squashed at the
> > >>> caller and @@ -85,11 +86,25 @@ static int send_tlb_inval_ggtt(struct
> > >>> xe_tlb_inval *tlb_inval, u32 seqno)
> > >>>
> > >>> CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt),
> > >>> XE_FW_GT);
> > >>> if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe)
> > >>> >= 20) {
> > >>> + /* Wait 1-second for the valid bit to be
> > >>> cleared */
> > >>> + ret = xe_mmio_wait32(mmio,
> > >>> PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > >>> + 0, 1000 *
> > >>> +USEC_PER_MSEC,
> > >>> NULL, false);
> > >>> + if (ret) {
> > >>> + pr_info("TLB INVAL cancelled due to
> > >>> uncleared valid bit\n");
> > >>> + return -ECANCELED;
> > >>> + }
> > >>
> > >> Is there a reason we aren't waiting after the write to make sure the
> > >> invalidation completed? It seems like we should be serializing these
> > >> and at least making sure hardware completes the request rather than
> > >> just sending and hoping for the best.
> > >
> > > Yes, this is correct—we should after wait issue *if* this code is actually needed.
> >
> > No, the issue is that software cannot issue another TLB invalidation request while the ongoing
> > one has not been completed yet. Otherwise the hardware could potentially lockup.
> > So we need to make sure the valid bit is cleared before issuing another TLB invalidation request.
> >
>
> Yes, but we signal the TLB invalidation fence as complete without
> waiting for the hardware to actually finish. The locking here is also
> incorrect for MMIO-based invalidations, now that I think about it. What
> really needs to happen is:
>
Ah, this actually another weird corner where we take down the CTs but
GuC is still using the GAM port...
> - In send_tlb_inval_ggtt(), if the MMIO path is taken, acquire a per-GT
> MMIO TLB invalidation lock after obtaining the FW
So maybe 'Wait for the valid bit to clear' here too but this still isn't
fully hardend as the GuC could immediately use the GAM port again...
Or perhaps we go straight to my suggestion below - when reloading the
GuC issue MMIO GT invalidation...
Matt
> - Issue the TLB invalidation
> - Wait for the valid bit to clear
> - Release the GT MMIO TLB invalidation lock
>
> Without this lock, two threads could both observe the valid bit clearing
> and then both attempt to issue invalidations, clobbering each other.
>
> > > This is early Xe code from me, and it’s questionable whether it’s even required.
> >
> > This seems to be required, otherwise modprobe would fail at golden context submission,
> > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0: hwe ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> >
>
> I’m somewhat surprised by this. A better solution might be to drop the
> MMIO GT invalidation code in xe_guc_tlb_inval.c and instead issue an
> MMIO GGTT invalidation whenever we reload the GuC.
>
> We can defer trying this until later, as it is a riskier change.
>
> Matt
>
> > > Typically, if the CTs are not live, the GuC isn’t doing anything meaningful in terms of
> > > referencing memory that the KMD is moving around (which would require an invalidation).
> > > So this entire flow of issuing a GAM port TLB invalidation is, again, questionable.
> > >
> > > So I'd suggest move the wait after issue, plus throw in:
> > >
> > > “XXX: Why do we need to invalidate GGTT memory when the CTs are not live? This suggests
> > > the GuC is still in the load phase. Investigate and remove this code once confirmed.'
> >
> > The issue is a consequence of an earlier failure which caused the CT to be disabled. And the KMD
> > sees a bunch of TLB invalidation timeouts.
> > At this time I would expect a GT reset, but that is not how Xe behaves (the ole i915 driver triggers
> > a GT reset on TLB invalidation timeout if I remember correctly)
> >
> > -Fei
> >
> > > Matt
> > >
> > >>
> > >> Thanks,
> > >> Stuart
> > >>
> > >>> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
> > >>>
> > >>> PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > >>> xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
> > >>>
> > >>> PVC_GUC_TLB_INV_DESC0_VALID);
> > >>> } else {
> > >>> + /* Wait 1-second for the valid bit to be
> > >>> cleared */
> > >>> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR,
> > >>> GUC_TLB_INV_CR_INVALIDATE,
> > >>> + 0, 1000 *
> > >>> +USEC_PER_MSEC,
> > >>> NULL, false);
> > >>> + if (ret) {
> > >>> + pr_info("TLB INVAL cancelled due to
> > >>> uncleared valid bit\n");
> > >>> + return -ECANCELED;
> > >>> + }
> > >>> xe_mmio_write32(mmio, GUC_TLB_INV_CR,
> > >>> GUC_TLB_INV_CR_INVALIDATE);
> > >>> }
> > >>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-24 20:58 ` Matthew Brost
@ 2026-03-24 21:10 ` Summers, Stuart
2026-03-24 23:36 ` Matthew Brost
0 siblings, 1 reply; 21+ messages in thread
From: Summers, Stuart @ 2026-03-24 21:10 UTC (permalink / raw)
To: Brost, Matthew, Yang, Fei; +Cc: intel-xe@lists.freedesktop.org
On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost wrote:
> > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart
> > > > wrote:
> > > > > On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
> > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > >
> > > > > > Hardware requires the software to poll the valid bit and
> > > > > > make sure
> > > > > > it's cleared before issuing a new TLB invalidation request.
> > > > > >
> > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
> > > > > > 1 file changed, 15 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct
> > > > > > xe_tlb_inval
> > > > > > *tlb_inval, u32 seqno)
> > > > > > struct xe_guc *guc = tlb_inval->private;
> > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > + int ret;
> > > > > >
> > > > > > /*
> > > > > > * Returning -ECANCELED in this function is
> > > > > > squashed at the
> > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > send_tlb_inval_ggtt(struct
> > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > >
> > > > > > CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt),
> > > > > > XE_FW_GT);
> > > > > > if (xe->info.platform == XE_PVC ||
> > > > > > GRAPHICS_VER(xe)
> > > > > > > = 20) {
> > > > > > + /* Wait 1-second for the valid bit
> > > > > > to be
> > > > > > cleared */
> > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > + 0, 1000 *
> > > > > > +USEC_PER_MSEC,
> > > > > > NULL, false);
> > > > > > + if (ret) {
> > > > > > + pr_info("TLB INVAL
> > > > > > cancelled due to
> > > > > > uncleared valid bit\n");
> > > > > > + return -ECANCELED;
> > > > > > + }
> > > > >
> > > > > Is there a reason we aren't waiting after the write to make
> > > > > sure the
> > > > > invalidation completed? It seems like we should be
> > > > > serializing these
> > > > > and at least making sure hardware completes the request
> > > > > rather than
> > > > > just sending and hoping for the best.
> > > >
> > > > Yes, this is correct—we should after wait issue *if* this code
> > > > is actually needed.
> > >
> > > No, the issue is that software cannot issue another TLB
> > > invalidation request while the ongoing
> > > one has not been completed yet. Otherwise the hardware could
> > > potentially lockup.
> > > So we need to make sure the valid bit is cleared before issuing
> > > another TLB invalidation request.
> > >
> >
> > Yes, but we signal the TLB invalidation fence as complete without
> > waiting for the hardware to actually finish. The locking here is
> > also
> > incorrect for MMIO-based invalidations, now that I think about it.
> > What
> > really needs to happen is:
> >
>
> Ah, this actually another weird corner where we take down the CTs but
> GuC is still using the GAM port...
>
> > - In send_tlb_inval_ggtt(), if the MMIO path is taken, acquire a
> > per-GT
> > MMIO TLB invalidation lock after obtaining the FW
>
> So maybe 'Wait for the valid bit to clear' here too but this still
> isn't
> fully hardend as the GuC could immediately use the GAM port again...
>
> Or perhaps we go straight to my suggestion below - when reloading the
> GuC issue MMIO GT invalidation...
I feel like we really should be avoiding these MMIO based invalidations
wherever possible. It creates a lot of race conditions like what you
suggested or even parallel invalidation between the GuC and KMD while
we're tearing down (KMD lock might not be able to guarantee the GuC
isn't still invalidating).
Can we instead rely more heavily on the GT reset to flush the TLBs for
us? And for the GuC memory specifically, maybe we do a full
invalidation after quiescing the GuC during hwconfig load (the first
time we load the GuC during driver load) and before any kind of
reload/reset?
We'd still need to cover the case where hardware is fully hung up and
GuC isn't responding, but then I don't know that we really care about
MMIO based invalidations since we'll want to fully reset the GT there
too.
Thanks,
Stuart
>
> Matt
>
> > - Issue the TLB invalidation
> > - Wait for the valid bit to clear
> > - Release the GT MMIO TLB invalidation lock
> >
> > Without this lock, two threads could both observe the valid bit
> > clearing
> > and then both attempt to issue invalidations, clobbering each
> > other.
> >
> > > > This is early Xe code from me, and it’s questionable whether
> > > > it’s even required.
> > >
> > > This seems to be required, otherwise modprobe would fail at
> > > golden context submission,
> > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0: hwe
> > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > >
> >
> > I’m somewhat surprised by this. A better solution might be to drop
> > the
> > MMIO GT invalidation code in xe_guc_tlb_inval.c and instead issue
> > an
> > MMIO GGTT invalidation whenever we reload the GuC.
> >
> > We can defer trying this until later, as it is a riskier change.
> >
> > Matt
> >
> > > > Typically, if the CTs are not live, the GuC isn’t doing
> > > > anything meaningful in terms of
> > > > referencing memory that the KMD is moving around (which would
> > > > require an invalidation).
> > > > So this entire flow of issuing a GAM port TLB invalidation is,
> > > > again, questionable.
> > > >
> > > > So I'd suggest move the wait after issue, plus throw in:
> > > >
> > > > “XXX: Why do we need to invalidate GGTT memory when the CTs are
> > > > not live? This suggests
> > > > the GuC is still in the load phase. Investigate and remove this
> > > > code once confirmed.'
> > >
> > > The issue is a consequence of an earlier failure which caused the
> > > CT to be disabled. And the KMD
> > > sees a bunch of TLB invalidation timeouts.
> > > At this time I would expect a GT reset, but that is not how Xe
> > > behaves (the ole i915 driver triggers
> > > a GT reset on TLB invalidation timeout if I remember correctly)
> > >
> > > -Fei
> > >
> > > > Matt
> > > >
> > > > >
> > > > > Thanks,
> > > > > Stuart
> > > > >
> > > > > > xe_mmio_write32(mmio,
> > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > >
> > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > xe_mmio_write32(mmio,
> > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > >
> > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > } else {
> > > > > > + /* Wait 1-second for the valid bit
> > > > > > to be
> > > > > > cleared */
> > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > GUC_TLB_INV_CR,
> > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > + 0, 1000 *
> > > > > > +USEC_PER_MSEC,
> > > > > > NULL, false);
> > > > > > + if (ret) {
> > > > > > + pr_info("TLB INVAL
> > > > > > cancelled due to
> > > > > > uncleared valid bit\n");
> > > > > > + return -ECANCELED;
> > > > > > + }
> > > > > > xe_mmio_write32(mmio,
> > > > > > GUC_TLB_INV_CR,
> > > > > >
> > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > }
> > > > >
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-24 21:10 ` Summers, Stuart
@ 2026-03-24 23:36 ` Matthew Brost
2026-03-25 18:37 ` Summers, Stuart
0 siblings, 1 reply; 21+ messages in thread
From: Matthew Brost @ 2026-03-24 23:36 UTC (permalink / raw)
To: Summers, Stuart; +Cc: Yang, Fei, intel-xe@lists.freedesktop.org
On Tue, Mar 24, 2026 at 03:10:41PM -0600, Summers, Stuart wrote:
> On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> > On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost wrote:
> > > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart
> > > > > wrote:
> > > > > > On Tue, 2026-03-17 at 16:21 -0700, fei.yang@intel.com wrote:
> > > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > > >
> > > > > > > Hardware requires the software to poll the valid bit and
> > > > > > > make sure
> > > > > > > it's cleared before issuing a new TLB invalidation request.
> > > > > > >
> > > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > > ---
> > > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15 +++++++++++++++
> > > > > > > 1 file changed, 15 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct
> > > > > > > xe_tlb_inval
> > > > > > > *tlb_inval, u32 seqno)
> > > > > > > struct xe_guc *guc = tlb_inval->private;
> > > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > > + int ret;
> > > > > > >
> > > > > > > /*
> > > > > > > * Returning -ECANCELED in this function is
> > > > > > > squashed at the
> > > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > > >
> > > > > > > CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt),
> > > > > > > XE_FW_GT);
> > > > > > > if (xe->info.platform == XE_PVC ||
> > > > > > > GRAPHICS_VER(xe)
> > > > > > > > = 20) {
> > > > > > > + /* Wait 1-second for the valid bit
> > > > > > > to be
> > > > > > > cleared */
> > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > > + 0, 1000 *
> > > > > > > +USEC_PER_MSEC,
> > > > > > > NULL, false);
> > > > > > > + if (ret) {
> > > > > > > + pr_info("TLB INVAL
> > > > > > > cancelled due to
> > > > > > > uncleared valid bit\n");
> > > > > > > + return -ECANCELED;
> > > > > > > + }
> > > > > >
> > > > > > Is there a reason we aren't waiting after the write to make
> > > > > > sure the
> > > > > > invalidation completed? It seems like we should be
> > > > > > serializing these
> > > > > > and at least making sure hardware completes the request
> > > > > > rather than
> > > > > > just sending and hoping for the best.
> > > > >
> > > > > Yes, this is correct—we should after wait issue *if* this code
> > > > > is actually needed.
> > > >
> > > > No, the issue is that software cannot issue another TLB
> > > > invalidation request while the ongoing
> > > > one has not been completed yet. Otherwise the hardware could
> > > > potentially lockup.
> > > > So we need to make sure the valid bit is cleared before issuing
> > > > another TLB invalidation request.
> > > >
> > >
> > > Yes, but we signal the TLB invalidation fence as complete without
> > > waiting for the hardware to actually finish. The locking here is
> > > also
> > > incorrect for MMIO-based invalidations, now that I think about it.
> > > What
> > > really needs to happen is:
> > >
> >
> > Ah, this actually another weird corner where we take down the CTs but
> > GuC is still using the GAM port...
> >
> > > - In send_tlb_inval_ggtt(), if the MMIO path is taken, acquire a
> > > per-GT
> > > MMIO TLB invalidation lock after obtaining the FW
> >
> > So maybe 'Wait for the valid bit to clear' here too but this still
> > isn't
> > fully hardend as the GuC could immediately use the GAM port again...
> >
> > Or perhaps we go straight to my suggestion below - when reloading the
> > GuC issue MMIO GT invalidation...
>
> I feel like we really should be avoiding these MMIO based invalidations
> wherever possible. It creates a lot of race conditions like what you
> suggested or even parallel invalidation between the GuC and KMD while
> we're tearing down (KMD lock might not be able to guarantee the GuC
> isn't still invalidating).
>
My guess is the issue calling xe_managed_bo_reinit_in_vram on some BOs -
the GGTT don't get invalidated GuC side and it reloads with stale GGTTs.
> Can we instead rely more heavily on the GT reset to flush the TLBs for
We likely need a MMIO invalidate whenever doing PM resume events too
as memory can move without PM refs (CTs go down when PM ref == 0) if I'm
not mistaken...
I'd also like the GAM port interaction broken out in component like
xe_gam_port.c (with a dedicated lock) in this seires [1] albiet way
simplier as we only need GGTT invalidates at this time.
Matt
[1] https://patchwork.freedesktop.org/patch/707237/?series=162171&rev=1
> us? And for the GuC memory specifically, maybe we do a full
> invalidation after quiescing the GuC during hwconfig load (the first
> time we load the GuC during driver load) and before any kind of
> reload/reset?
>
> We'd still need to cover the case where hardware is fully hung up and
> GuC isn't responding, but then I don't know that we really care about
> MMIO based invalidations since we'll want to fully reset the GT there
> too.
>
> Thanks,
> Stuart
>
> >
> > Matt
> >
> > > - Issue the TLB invalidation
> > > - Wait for the valid bit to clear
> > > - Release the GT MMIO TLB invalidation lock
> > >
> > > Without this lock, two threads could both observe the valid bit
> > > clearing
> > > and then both attempt to issue invalidations, clobbering each
> > > other.
> > >
> > > > > This is early Xe code from me, and it’s questionable whether
> > > > > it’s even required.
> > > >
> > > > This seems to be required, otherwise modprobe would fail at
> > > > golden context submission,
> > > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0: hwe
> > > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > > >
> > >
> > > I’m somewhat surprised by this. A better solution might be to drop
> > > the
> > > MMIO GT invalidation code in xe_guc_tlb_inval.c and instead issue
> > > an
> > > MMIO GGTT invalidation whenever we reload the GuC.
> > >
> > > We can defer trying this until later, as it is a riskier change.
> > >
> > > Matt
> > >
> > > > > Typically, if the CTs are not live, the GuC isn’t doing
> > > > > anything meaningful in terms of
> > > > > referencing memory that the KMD is moving around (which would
> > > > > require an invalidation).
> > > > > So this entire flow of issuing a GAM port TLB invalidation is,
> > > > > again, questionable.
> > > > >
> > > > > So I'd suggest move the wait after issue, plus throw in:
> > > > >
> > > > > “XXX: Why do we need to invalidate GGTT memory when the CTs are
> > > > > not live? This suggests
> > > > > the GuC is still in the load phase. Investigate and remove this
> > > > > code once confirmed.'
> > > >
> > > > The issue is a consequence of an earlier failure which caused the
> > > > CT to be disabled. And the KMD
> > > > sees a bunch of TLB invalidation timeouts.
> > > > At this time I would expect a GT reset, but that is not how Xe
> > > > behaves (the ole i915 driver triggers
> > > > a GT reset on TLB invalidation timeout if I remember correctly)
> > > >
> > > > -Fei
> > > >
> > > > > Matt
> > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Stuart
> > > > > >
> > > > > > > xe_mmio_write32(mmio,
> > > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > > >
> > > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > > xe_mmio_write32(mmio,
> > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > >
> > > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > > } else {
> > > > > > > + /* Wait 1-second for the valid bit
> > > > > > > to be
> > > > > > > cleared */
> > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > GUC_TLB_INV_CR,
> > > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > > + 0, 1000 *
> > > > > > > +USEC_PER_MSEC,
> > > > > > > NULL, false);
> > > > > > > + if (ret) {
> > > > > > > + pr_info("TLB INVAL
> > > > > > > cancelled due to
> > > > > > > uncleared valid bit\n");
> > > > > > > + return -ECANCELED;
> > > > > > > + }
> > > > > > > xe_mmio_write32(mmio,
> > > > > > > GUC_TLB_INV_CR,
> > > > > > >
> > > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > > }
> > > > > >
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-24 23:36 ` Matthew Brost
@ 2026-03-25 18:37 ` Summers, Stuart
2026-03-25 22:00 ` Matthew Brost
0 siblings, 1 reply; 21+ messages in thread
From: Summers, Stuart @ 2026-03-25 18:37 UTC (permalink / raw)
To: Brost, Matthew; +Cc: intel-xe@lists.freedesktop.org, Yang, Fei
On Tue, 2026-03-24 at 16:36 -0700, Matthew Brost wrote:
> On Tue, Mar 24, 2026 at 03:10:41PM -0600, Summers, Stuart wrote:
> > On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> > > On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost wrote:
> > > > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > > > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart
> > > > > > wrote:
> > > > > > > On Tue, 2026-03-17 at 16:21 -0700,
> > > > > > > fei.yang@intel.com wrote:
> > > > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > > > >
> > > > > > > > Hardware requires the software to poll the valid bit
> > > > > > > > and
> > > > > > > > make sure
> > > > > > > > it's cleared before issuing a new TLB invalidation
> > > > > > > > request.
> > > > > > > >
> > > > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15
> > > > > > > > +++++++++++++++
> > > > > > > > 1 file changed, 15 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct
> > > > > > > > xe_tlb_inval
> > > > > > > > *tlb_inval, u32 seqno)
> > > > > > > > struct xe_guc *guc = tlb_inval->private;
> > > > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > > > + int ret;
> > > > > > > >
> > > > > > > > /*
> > > > > > > > * Returning -ECANCELED in this function is
> > > > > > > > squashed at the
> > > > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > > > >
> > > > > > > > CLASS(xe_force_wake,
> > > > > > > > fw_ref)(gt_to_fw(gt),
> > > > > > > > XE_FW_GT);
> > > > > > > > if (xe->info.platform == XE_PVC ||
> > > > > > > > GRAPHICS_VER(xe)
> > > > > > > > > = 20) {
> > > > > > > > + /* Wait 1-second for the valid
> > > > > > > > bit
> > > > > > > > to be
> > > > > > > > cleared */
> > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > > > + 0, 1000 *
> > > > > > > > +USEC_PER_MSEC,
> > > > > > > > NULL, false);
> > > > > > > > + if (ret) {
> > > > > > > > + pr_info("TLB INVAL
> > > > > > > > cancelled due to
> > > > > > > > uncleared valid bit\n");
> > > > > > > > + return -ECANCELED;
> > > > > > > > + }
> > > > > > >
> > > > > > > Is there a reason we aren't waiting after the write to
> > > > > > > make
> > > > > > > sure the
> > > > > > > invalidation completed? It seems like we should be
> > > > > > > serializing these
> > > > > > > and at least making sure hardware completes the request
> > > > > > > rather than
> > > > > > > just sending and hoping for the best.
> > > > > >
> > > > > > Yes, this is correct—we should after wait issue *if* this
> > > > > > code
> > > > > > is actually needed.
> > > > >
> > > > > No, the issue is that software cannot issue another TLB
> > > > > invalidation request while the ongoing
> > > > > one has not been completed yet. Otherwise the hardware could
> > > > > potentially lockup.
> > > > > So we need to make sure the valid bit is cleared before
> > > > > issuing
> > > > > another TLB invalidation request.
> > > > >
> > > >
> > > > Yes, but we signal the TLB invalidation fence as complete
> > > > without
> > > > waiting for the hardware to actually finish. The locking here
> > > > is
> > > > also
> > > > incorrect for MMIO-based invalidations, now that I think about
> > > > it.
> > > > What
> > > > really needs to happen is:
> > > >
> > >
> > > Ah, this actually another weird corner where we take down the CTs
> > > but
> > > GuC is still using the GAM port...
> > >
> > > > - In send_tlb_inval_ggtt(), if the MMIO path is taken, acquire
> > > > a
> > > > per-GT
> > > > MMIO TLB invalidation lock after obtaining the FW
> > >
> > > So maybe 'Wait for the valid bit to clear' here too but this
> > > still
> > > isn't
> > > fully hardend as the GuC could immediately use the GAM port
> > > again...
> > >
> > > Or perhaps we go straight to my suggestion below - when reloading
> > > the
> > > GuC issue MMIO GT invalidation...
> >
> > I feel like we really should be avoiding these MMIO based
> > invalidations
> > wherever possible. It creates a lot of race conditions like what
> > you
> > suggested or even parallel invalidation between the GuC and KMD
> > while
> > we're tearing down (KMD lock might not be able to guarantee the GuC
> > isn't still invalidating).
> >
>
> My guess is the issue calling xe_managed_bo_reinit_in_vram on some
> BOs -
> the GGTT don't get invalidated GuC side and it reloads with stale
> GGTTs.
>
> > Can we instead rely more heavily on the GT reset to flush the TLBs
> > for
>
> We likely need a MMIO invalidate whenever doing PM resume events too
> as memory can move without PM refs (CTs go down when PM ref == 0) if
> I'm
> not mistaken...
But we already do a GT reset in that case right? So this should be
covered?
>
> I'd also like the GAM port interaction broken out in component like
> xe_gam_port.c (with a dedicated lock) in this seires [1] albiet way
> simplier as we only need GGTT invalidates at this time.
I'd still like to push we find a way to completely remove the MMIO
invalidation from the driver and rely on either the resets or GuC based
invalidation prior to teardowns if at all possible.
I hadn't seen your other patch yet though. I'll take a look as soon as
I have time.
Thanks,
Stuart
>
> Matt
>
> [1]
> https://patchwork.freedesktop.org/patch/707237/?series=162171&rev=1
>
> > us? And for the GuC memory specifically, maybe we do a full
> > invalidation after quiescing the GuC during hwconfig load (the
> > first
> > time we load the GuC during driver load) and before any kind of
> > reload/reset?
> >
> > We'd still need to cover the case where hardware is fully hung up
> > and
> > GuC isn't responding, but then I don't know that we really care
> > about
> > MMIO based invalidations since we'll want to fully reset the GT
> > there
> > too.
> >
> > Thanks,
> > Stuart
> >
> > >
> > > Matt
> > >
> > > > - Issue the TLB invalidation
> > > > - Wait for the valid bit to clear
> > > > - Release the GT MMIO TLB invalidation lock
> > > >
> > > > Without this lock, two threads could both observe the valid bit
> > > > clearing
> > > > and then both attempt to issue invalidations, clobbering each
> > > > other.
> > > >
> > > > > > This is early Xe code from me, and it’s questionable
> > > > > > whether
> > > > > > it’s even required.
> > > > >
> > > > > This seems to be required, otherwise modprobe would fail at
> > > > > golden context submission,
> > > > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0: hwe
> > > > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > > > >
> > > >
> > > > I’m somewhat surprised by this. A better solution might be to
> > > > drop
> > > > the
> > > > MMIO GT invalidation code in xe_guc_tlb_inval.c and instead
> > > > issue
> > > > an
> > > > MMIO GGTT invalidation whenever we reload the GuC.
> > > >
> > > > We can defer trying this until later, as it is a riskier
> > > > change.
> > > >
> > > > Matt
> > > >
> > > > > > Typically, if the CTs are not live, the GuC isn’t doing
> > > > > > anything meaningful in terms of
> > > > > > referencing memory that the KMD is moving around (which
> > > > > > would
> > > > > > require an invalidation).
> > > > > > So this entire flow of issuing a GAM port TLB invalidation
> > > > > > is,
> > > > > > again, questionable.
> > > > > >
> > > > > > So I'd suggest move the wait after issue, plus throw in:
> > > > > >
> > > > > > “XXX: Why do we need to invalidate GGTT memory when the CTs
> > > > > > are
> > > > > > not live? This suggests
> > > > > > the GuC is still in the load phase. Investigate and remove
> > > > > > this
> > > > > > code once confirmed.'
> > > > >
> > > > > The issue is a consequence of an earlier failure which caused
> > > > > the
> > > > > CT to be disabled. And the KMD
> > > > > sees a bunch of TLB invalidation timeouts.
> > > > > At this time I would expect a GT reset, but that is not how
> > > > > Xe
> > > > > behaves (the ole i915 driver triggers
> > > > > a GT reset on TLB invalidation timeout if I remember
> > > > > correctly)
> > > > >
> > > > > -Fei
> > > > >
> > > > > > Matt
> > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Stuart
> > > > > > >
> > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > > > >
> > > > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > >
> > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > > > } else {
> > > > > > > > + /* Wait 1-second for the valid
> > > > > > > > bit
> > > > > > > > to be
> > > > > > > > cleared */
> > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > > > + 0, 1000 *
> > > > > > > > +USEC_PER_MSEC,
> > > > > > > > NULL, false);
> > > > > > > > + if (ret) {
> > > > > > > > + pr_info("TLB INVAL
> > > > > > > > cancelled due to
> > > > > > > > uncleared valid bit\n");
> > > > > > > > + return -ECANCELED;
> > > > > > > > + }
> > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > GUC_TLB_INV_CR,
> > > > > > > >
> > > > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > > > }
> > > > > > >
> >
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-25 18:37 ` Summers, Stuart
@ 2026-03-25 22:00 ` Matthew Brost
2026-03-25 22:25 ` Summers, Stuart
0 siblings, 1 reply; 21+ messages in thread
From: Matthew Brost @ 2026-03-25 22:00 UTC (permalink / raw)
To: Summers, Stuart; +Cc: intel-xe@lists.freedesktop.org, Yang, Fei
On Wed, Mar 25, 2026 at 12:37:18PM -0600, Summers, Stuart wrote:
> On Tue, 2026-03-24 at 16:36 -0700, Matthew Brost wrote:
> > On Tue, Mar 24, 2026 at 03:10:41PM -0600, Summers, Stuart wrote:
> > > On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> > > > On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost wrote:
> > > > > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > > > > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers, Stuart
> > > > > > > wrote:
> > > > > > > > On Tue, 2026-03-17 at 16:21 -0700,
> > > > > > > > fei.yang@intel.com wrote:
> > > > > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > > > > >
> > > > > > > > > Hardware requires the software to poll the valid bit
> > > > > > > > > and
> > > > > > > > > make sure
> > > > > > > > > it's cleared before issuing a new TLB invalidation
> > > > > > > > > request.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > > > > ---
> > > > > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15
> > > > > > > > > +++++++++++++++
> > > > > > > > > 1 file changed, 15 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > @@ -63,6 +63,7 @@ static int send_tlb_inval_ggtt(struct
> > > > > > > > > xe_tlb_inval
> > > > > > > > > *tlb_inval, u32 seqno)
> > > > > > > > > struct xe_guc *guc = tlb_inval->private;
> > > > > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > > > > + int ret;
> > > > > > > > >
> > > > > > > > > /*
> > > > > > > > > * Returning -ECANCELED in this function is
> > > > > > > > > squashed at the
> > > > > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > > > > >
> > > > > > > > > CLASS(xe_force_wake,
> > > > > > > > > fw_ref)(gt_to_fw(gt),
> > > > > > > > > XE_FW_GT);
> > > > > > > > > if (xe->info.platform == XE_PVC ||
> > > > > > > > > GRAPHICS_VER(xe)
> > > > > > > > > > = 20) {
> > > > > > > > > + /* Wait 1-second for the valid
> > > > > > > > > bit
> > > > > > > > > to be
> > > > > > > > > cleared */
> > > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > > PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > > > > + 0, 1000 *
> > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > NULL, false);
> > > > > > > > > + if (ret) {
> > > > > > > > > + pr_info("TLB INVAL
> > > > > > > > > cancelled due to
> > > > > > > > > uncleared valid bit\n");
> > > > > > > > > + return -ECANCELED;
> > > > > > > > > + }
> > > > > > > >
> > > > > > > > Is there a reason we aren't waiting after the write to
> > > > > > > > make
> > > > > > > > sure the
> > > > > > > > invalidation completed? It seems like we should be
> > > > > > > > serializing these
> > > > > > > > and at least making sure hardware completes the request
> > > > > > > > rather than
> > > > > > > > just sending and hoping for the best.
> > > > > > >
> > > > > > > Yes, this is correct—we should after wait issue *if* this
> > > > > > > code
> > > > > > > is actually needed.
> > > > > >
> > > > > > No, the issue is that software cannot issue another TLB
> > > > > > invalidation request while the ongoing
> > > > > > one has not been completed yet. Otherwise the hardware could
> > > > > > potentially lockup.
> > > > > > So we need to make sure the valid bit is cleared before
> > > > > > issuing
> > > > > > another TLB invalidation request.
> > > > > >
> > > > >
> > > > > Yes, but we signal the TLB invalidation fence as complete
> > > > > without
> > > > > waiting for the hardware to actually finish. The locking here
> > > > > is
> > > > > also
> > > > > incorrect for MMIO-based invalidations, now that I think about
> > > > > it.
> > > > > What
> > > > > really needs to happen is:
> > > > >
> > > >
> > > > Ah, this actually another weird corner where we take down the CTs
> > > > but
> > > > GuC is still using the GAM port...
> > > >
> > > > > - In send_tlb_inval_ggtt(), if the MMIO path is taken, acquire
> > > > > a
> > > > > per-GT
> > > > > MMIO TLB invalidation lock after obtaining the FW
> > > >
> > > > So maybe 'Wait for the valid bit to clear' here too but this
> > > > still
> > > > isn't
> > > > fully hardend as the GuC could immediately use the GAM port
> > > > again...
> > > >
> > > > Or perhaps we go straight to my suggestion below - when reloading
> > > > the
> > > > GuC issue MMIO GT invalidation...
> > >
> > > I feel like we really should be avoiding these MMIO based
> > > invalidations
> > > wherever possible. It creates a lot of race conditions like what
> > > you
> > > suggested or even parallel invalidation between the GuC and KMD
> > > while
> > > we're tearing down (KMD lock might not be able to guarantee the GuC
> > > isn't still invalidating).
> > >
> >
> > My guess is the issue calling xe_managed_bo_reinit_in_vram on some
> > BOs -
> > the GGTT don't get invalidated GuC side and it reloads with stale
> > GGTTs.
> >
> > > Can we instead rely more heavily on the GT reset to flush the TLBs
> > > for
> >
> > We likely need a MMIO invalidate whenever doing PM resume events too
> > as memory can move without PM refs (CTs go down when PM ref == 0) if
> > I'm
> > not mistaken...
>
> But we already do a GT reset in that case right? So this should be
> covered?
>
D3hot doesn't perform a GT reset or enter D3cold. However, looking at
xe_ggtt.c, GGTT invalidations always hold a PM reference, so the CT
should remain live unless a GT reset is in progress.
Therefore, the only two cases where we might need MMIO invalidations
are:
- During initial driver load, after we call xe_managed_bo_reinit_in_vram
on some buffers used during the hwconfig GuC load phase, and then move
the memory while retaining the same GGTT addresses.
- During a GT reset, where memory is allowed to move around. Likely do
this step before reloading the GuC.
> >
> > I'd also like the GAM port interaction broken out in component like
> > xe_gam_port.c (with a dedicated lock) in this seires [1] albiet way
> > simplier as we only need GGTT invalidates at this time.
>
> I'd still like to push we find a way to completely remove the MMIO
> invalidation from the driver and rely on either the resets or GuC based
> invalidation prior to teardowns if at all possible.
>
I agree MMIO TLB invalidations have no place xe_guc_tlb_inval.c.
Matt
> I hadn't seen your other patch yet though. I'll take a look as soon as
> I have time.
>
> Thanks,
> Stuart
>
> >
> > Matt
> >
> > [1]
> > https://patchwork.freedesktop.org/patch/707237/?series=162171&rev=1
> >
> > > us? And for the GuC memory specifically, maybe we do a full
> > > invalidation after quiescing the GuC during hwconfig load (the
> > > first
> > > time we load the GuC during driver load) and before any kind of
> > > reload/reset?
> > >
> > > We'd still need to cover the case where hardware is fully hung up
> > > and
> > > GuC isn't responding, but then I don't know that we really care
> > > about
> > > MMIO based invalidations since we'll want to fully reset the GT
> > > there
> > > too.
> > >
> > > Thanks,
> > > Stuart
> > >
> > > >
> > > > Matt
> > > >
> > > > > - Issue the TLB invalidation
> > > > > - Wait for the valid bit to clear
> > > > > - Release the GT MMIO TLB invalidation lock
> > > > >
> > > > > Without this lock, two threads could both observe the valid bit
> > > > > clearing
> > > > > and then both attempt to issue invalidations, clobbering each
> > > > > other.
> > > > >
> > > > > > > This is early Xe code from me, and it’s questionable
> > > > > > > whether
> > > > > > > it’s even required.
> > > > > >
> > > > > > This seems to be required, otherwise modprobe would fail at
> > > > > > golden context submission,
> > > > > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0: hwe
> > > > > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > > > > >
> > > > >
> > > > > I’m somewhat surprised by this. A better solution might be to
> > > > > drop
> > > > > the
> > > > > MMIO GT invalidation code in xe_guc_tlb_inval.c and instead
> > > > > issue
> > > > > an
> > > > > MMIO GGTT invalidation whenever we reload the GuC.
> > > > >
> > > > > We can defer trying this until later, as it is a riskier
> > > > > change.
> > > > >
> > > > > Matt
> > > > >
> > > > > > > Typically, if the CTs are not live, the GuC isn’t doing
> > > > > > > anything meaningful in terms of
> > > > > > > referencing memory that the KMD is moving around (which
> > > > > > > would
> > > > > > > require an invalidation).
> > > > > > > So this entire flow of issuing a GAM port TLB invalidation
> > > > > > > is,
> > > > > > > again, questionable.
> > > > > > >
> > > > > > > So I'd suggest move the wait after issue, plus throw in:
> > > > > > >
> > > > > > > “XXX: Why do we need to invalidate GGTT memory when the CTs
> > > > > > > are
> > > > > > > not live? This suggests
> > > > > > > the GuC is still in the load phase. Investigate and remove
> > > > > > > this
> > > > > > > code once confirmed.'
> > > > > >
> > > > > > The issue is a consequence of an earlier failure which caused
> > > > > > the
> > > > > > CT to be disabled. And the KMD
> > > > > > sees a bunch of TLB invalidation timeouts.
> > > > > > At this time I would expect a GT reset, but that is not how
> > > > > > Xe
> > > > > > behaves (the ole i915 driver triggers
> > > > > > a GT reset on TLB invalidation timeout if I remember
> > > > > > correctly)
> > > > > >
> > > > > > -Fei
> > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Stuart
> > > > > > > >
> > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > > > > >
> > > > > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > > >
> > > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > > > > } else {
> > > > > > > > > + /* Wait 1-second for the valid
> > > > > > > > > bit
> > > > > > > > > to be
> > > > > > > > > cleared */
> > > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > > > > + 0, 1000 *
> > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > NULL, false);
> > > > > > > > > + if (ret) {
> > > > > > > > > + pr_info("TLB INVAL
> > > > > > > > > cancelled due to
> > > > > > > > > uncleared valid bit\n");
> > > > > > > > > + return -ECANCELED;
> > > > > > > > > + }
> > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > >
> > > > > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > > > > }
> > > > > > > >
> > >
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-25 22:00 ` Matthew Brost
@ 2026-03-25 22:25 ` Summers, Stuart
2026-03-25 22:38 ` Matthew Brost
0 siblings, 1 reply; 21+ messages in thread
From: Summers, Stuart @ 2026-03-25 22:25 UTC (permalink / raw)
To: Brost, Matthew; +Cc: intel-xe@lists.freedesktop.org, Yang, Fei
On Wed, 2026-03-25 at 15:00 -0700, Matthew Brost wrote:
> On Wed, Mar 25, 2026 at 12:37:18PM -0600, Summers, Stuart wrote:
> > On Tue, 2026-03-24 at 16:36 -0700, Matthew Brost wrote:
> > > On Tue, Mar 24, 2026 at 03:10:41PM -0600, Summers, Stuart wrote:
> > > > On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> > > > > On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost
> > > > > wrote:
> > > > > > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > > > > > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers,
> > > > > > > > Stuart
> > > > > > > > wrote:
> > > > > > > > > On Tue, 2026-03-17 at 16:21 -0700,
> > > > > > > > > fei.yang@intel.com wrote:
> > > > > > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > > > > > >
> > > > > > > > > > Hardware requires the software to poll the valid
> > > > > > > > > > bit
> > > > > > > > > > and
> > > > > > > > > > make sure
> > > > > > > > > > it's cleared before issuing a new TLB invalidation
> > > > > > > > > > request.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > > > > > ---
> > > > > > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15
> > > > > > > > > > +++++++++++++++
> > > > > > > > > > 1 file changed, 15 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > @@ -63,6 +63,7 @@ static int
> > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > xe_tlb_inval
> > > > > > > > > > *tlb_inval, u32 seqno)
> > > > > > > > > > struct xe_guc *guc = tlb_inval->private;
> > > > > > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > > > > > + int ret;
> > > > > > > > > >
> > > > > > > > > > /*
> > > > > > > > > > * Returning -ECANCELED in this function is
> > > > > > > > > > squashed at the
> > > > > > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > > > > > >
> > > > > > > > > > CLASS(xe_force_wake,
> > > > > > > > > > fw_ref)(gt_to_fw(gt),
> > > > > > > > > > XE_FW_GT);
> > > > > > > > > > if (xe->info.platform == XE_PVC ||
> > > > > > > > > > GRAPHICS_VER(xe)
> > > > > > > > > > > = 20) {
> > > > > > > > > > + /* Wait 1-second for the
> > > > > > > > > > valid
> > > > > > > > > > bit
> > > > > > > > > > to be
> > > > > > > > > > cleared */
> > > > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > > > PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > > > > > + 0,
> > > > > > > > > > 1000 *
> > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > NULL, false);
> > > > > > > > > > + if (ret) {
> > > > > > > > > > + pr_info("TLB INVAL
> > > > > > > > > > cancelled due to
> > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > + return -ECANCELED;
> > > > > > > > > > + }
> > > > > > > > >
> > > > > > > > > Is there a reason we aren't waiting after the write
> > > > > > > > > to
> > > > > > > > > make
> > > > > > > > > sure the
> > > > > > > > > invalidation completed? It seems like we should be
> > > > > > > > > serializing these
> > > > > > > > > and at least making sure hardware completes the
> > > > > > > > > request
> > > > > > > > > rather than
> > > > > > > > > just sending and hoping for the best.
> > > > > > > >
> > > > > > > > Yes, this is correct—we should after wait issue *if*
> > > > > > > > this
> > > > > > > > code
> > > > > > > > is actually needed.
> > > > > > >
> > > > > > > No, the issue is that software cannot issue another TLB
> > > > > > > invalidation request while the ongoing
> > > > > > > one has not been completed yet. Otherwise the hardware
> > > > > > > could
> > > > > > > potentially lockup.
> > > > > > > So we need to make sure the valid bit is cleared before
> > > > > > > issuing
> > > > > > > another TLB invalidation request.
> > > > > > >
> > > > > >
> > > > > > Yes, but we signal the TLB invalidation fence as complete
> > > > > > without
> > > > > > waiting for the hardware to actually finish. The locking
> > > > > > here
> > > > > > is
> > > > > > also
> > > > > > incorrect for MMIO-based invalidations, now that I think
> > > > > > about
> > > > > > it.
> > > > > > What
> > > > > > really needs to happen is:
> > > > > >
> > > > >
> > > > > Ah, this actually another weird corner where we take down the
> > > > > CTs
> > > > > but
> > > > > GuC is still using the GAM port...
> > > > >
> > > > > > - In send_tlb_inval_ggtt(), if the MMIO path is taken,
> > > > > > acquire
> > > > > > a
> > > > > > per-GT
> > > > > > MMIO TLB invalidation lock after obtaining the FW
> > > > >
> > > > > So maybe 'Wait for the valid bit to clear' here too but this
> > > > > still
> > > > > isn't
> > > > > fully hardend as the GuC could immediately use the GAM port
> > > > > again...
> > > > >
> > > > > Or perhaps we go straight to my suggestion below - when
> > > > > reloading
> > > > > the
> > > > > GuC issue MMIO GT invalidation...
> > > >
> > > > I feel like we really should be avoiding these MMIO based
> > > > invalidations
> > > > wherever possible. It creates a lot of race conditions like
> > > > what
> > > > you
> > > > suggested or even parallel invalidation between the GuC and KMD
> > > > while
> > > > we're tearing down (KMD lock might not be able to guarantee the
> > > > GuC
> > > > isn't still invalidating).
> > > >
> > >
> > > My guess is the issue calling xe_managed_bo_reinit_in_vram on
> > > some
> > > BOs -
> > > the GGTT don't get invalidated GuC side and it reloads with stale
> > > GGTTs.
> > >
> > > > Can we instead rely more heavily on the GT reset to flush the
> > > > TLBs
> > > > for
> > >
> > > We likely need a MMIO invalidate whenever doing PM resume events
> > > too
> > > as memory can move without PM refs (CTs go down when PM ref == 0)
> > > if
> > > I'm
> > > not mistaken...
> >
> > But we already do a GT reset in that case right? So this should be
> > covered?
> >
>
> D3hot doesn't perform a GT reset or enter D3cold. However, looking at
> xe_ggtt.c, GGTT invalidations always hold a PM reference, so the CT
> should remain live unless a GT reset is in progress.
>
> Therefore, the only two cases where we might need MMIO invalidations
> are:
>
> - During initial driver load, after we call
> xe_managed_bo_reinit_in_vram
> on some buffers used during the hwconfig GuC load phase, and then
> move
> the memory while retaining the same GGTT addresses.
>
> - During a GT reset, where memory is allowed to move around. Likely
> do
> this step before reloading the GuC.
But for both of these cases, we should be able to do:
for_each_gt_on_tile()
xe_tlb_inval_fence_init()
xe_tlb_inval_all()
for_each_gt_on_tile()
xe_tlb_inval_all()
Right before GuC communication goes down right? Then we wouldn't need
any MMIO communication since the TLBs are flushed at that point.
Thanks,
Stuart
>
> > >
> > > I'd also like the GAM port interaction broken out in component
> > > like
> > > xe_gam_port.c (with a dedicated lock) in this seires [1] albiet
> > > way
> > > simplier as we only need GGTT invalidates at this time.
> >
> > I'd still like to push we find a way to completely remove the MMIO
> > invalidation from the driver and rely on either the resets or GuC
> > based
> > invalidation prior to teardowns if at all possible.
> >
>
> I agree MMIO TLB invalidations have no place xe_guc_tlb_inval.c.
>
> Matt
>
> > I hadn't seen your other patch yet though. I'll take a look as soon
> > as
> > I have time.
> >
> > Thanks,
> > Stuart
> >
> > >
> > > Matt
> > >
> > > [1]
> > > https://patchwork.freedesktop.org/patch/707237/?series=162171&rev=1
> > >
> > > > us? And for the GuC memory specifically, maybe we do a full
> > > > invalidation after quiescing the GuC during hwconfig load (the
> > > > first
> > > > time we load the GuC during driver load) and before any kind of
> > > > reload/reset?
> > > >
> > > > We'd still need to cover the case where hardware is fully hung
> > > > up
> > > > and
> > > > GuC isn't responding, but then I don't know that we really care
> > > > about
> > > > MMIO based invalidations since we'll want to fully reset the GT
> > > > there
> > > > too.
> > > >
> > > > Thanks,
> > > > Stuart
> > > >
> > > > >
> > > > > Matt
> > > > >
> > > > > > - Issue the TLB invalidation
> > > > > > - Wait for the valid bit to clear
> > > > > > - Release the GT MMIO TLB invalidation lock
> > > > > >
> > > > > > Without this lock, two threads could both observe the valid
> > > > > > bit
> > > > > > clearing
> > > > > > and then both attempt to issue invalidations, clobbering
> > > > > > each
> > > > > > other.
> > > > > >
> > > > > > > > This is early Xe code from me, and it’s questionable
> > > > > > > > whether
> > > > > > > > it’s even required.
> > > > > > >
> > > > > > > This seems to be required, otherwise modprobe would fail
> > > > > > > at
> > > > > > > golden context submission,
> > > > > > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0:
> > > > > > > hwe
> > > > > > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > > > > > >
> > > > > >
> > > > > > I’m somewhat surprised by this. A better solution might be
> > > > > > to
> > > > > > drop
> > > > > > the
> > > > > > MMIO GT invalidation code in xe_guc_tlb_inval.c and instead
> > > > > > issue
> > > > > > an
> > > > > > MMIO GGTT invalidation whenever we reload the GuC.
> > > > > >
> > > > > > We can defer trying this until later, as it is a riskier
> > > > > > change.
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > > > > Typically, if the CTs are not live, the GuC isn’t doing
> > > > > > > > anything meaningful in terms of
> > > > > > > > referencing memory that the KMD is moving around (which
> > > > > > > > would
> > > > > > > > require an invalidation).
> > > > > > > > So this entire flow of issuing a GAM port TLB
> > > > > > > > invalidation
> > > > > > > > is,
> > > > > > > > again, questionable.
> > > > > > > >
> > > > > > > > So I'd suggest move the wait after issue, plus throw
> > > > > > > > in:
> > > > > > > >
> > > > > > > > “XXX: Why do we need to invalidate GGTT memory when the
> > > > > > > > CTs
> > > > > > > > are
> > > > > > > > not live? This suggests
> > > > > > > > the GuC is still in the load phase. Investigate and
> > > > > > > > remove
> > > > > > > > this
> > > > > > > > code once confirmed.'
> > > > > > >
> > > > > > > The issue is a consequence of an earlier failure which
> > > > > > > caused
> > > > > > > the
> > > > > > > CT to be disabled. And the KMD
> > > > > > > sees a bunch of TLB invalidation timeouts.
> > > > > > > At this time I would expect a GT reset, but that is not
> > > > > > > how
> > > > > > > Xe
> > > > > > > behaves (the ole i915 driver triggers
> > > > > > > a GT reset on TLB invalidation timeout if I remember
> > > > > > > correctly)
> > > > > > >
> > > > > > > -Fei
> > > > > > >
> > > > > > > > Matt
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Stuart
> > > > > > > > >
> > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > > > > > >
> > > > > > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > > > >
> > > > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > > > > > } else {
> > > > > > > > > > + /* Wait 1-second for the
> > > > > > > > > > valid
> > > > > > > > > > bit
> > > > > > > > > > to be
> > > > > > > > > > cleared */
> > > > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > > > > > + 0,
> > > > > > > > > > 1000 *
> > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > NULL, false);
> > > > > > > > > > + if (ret) {
> > > > > > > > > > + pr_info("TLB INVAL
> > > > > > > > > > cancelled due to
> > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > + return -ECANCELED;
> > > > > > > > > > + }
> > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > >
> > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > > > > > }
> > > > > > > > >
> > > >
> >
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-25 22:25 ` Summers, Stuart
@ 2026-03-25 22:38 ` Matthew Brost
2026-03-25 22:43 ` Summers, Stuart
0 siblings, 1 reply; 21+ messages in thread
From: Matthew Brost @ 2026-03-25 22:38 UTC (permalink / raw)
To: Summers, Stuart; +Cc: intel-xe@lists.freedesktop.org, Yang, Fei
On Wed, Mar 25, 2026 at 04:25:22PM -0600, Summers, Stuart wrote:
> On Wed, 2026-03-25 at 15:00 -0700, Matthew Brost wrote:
> > On Wed, Mar 25, 2026 at 12:37:18PM -0600, Summers, Stuart wrote:
> > > On Tue, 2026-03-24 at 16:36 -0700, Matthew Brost wrote:
> > > > On Tue, Mar 24, 2026 at 03:10:41PM -0600, Summers, Stuart wrote:
> > > > > On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> > > > > > On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost
> > > > > > wrote:
> > > > > > > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei wrote:
> > > > > > > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers,
> > > > > > > > > Stuart
> > > > > > > > > wrote:
> > > > > > > > > > On Tue, 2026-03-17 at 16:21 -0700,
> > > > > > > > > > fei.yang@intel.com wrote:
> > > > > > > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > > > > > > >
> > > > > > > > > > > Hardware requires the software to poll the valid
> > > > > > > > > > > bit
> > > > > > > > > > > and
> > > > > > > > > > > make sure
> > > > > > > > > > > it's cleared before issuing a new TLB invalidation
> > > > > > > > > > > request.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15
> > > > > > > > > > > +++++++++++++++
> > > > > > > > > > > 1 file changed, 15 insertions(+)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > @@ -63,6 +63,7 @@ static int
> > > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > > xe_tlb_inval
> > > > > > > > > > > *tlb_inval, u32 seqno)
> > > > > > > > > > > struct xe_guc *guc = tlb_inval->private;
> > > > > > > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > > > > > > + int ret;
> > > > > > > > > > >
> > > > > > > > > > > /*
> > > > > > > > > > > * Returning -ECANCELED in this function is
> > > > > > > > > > > squashed at the
> > > > > > > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > > > > > > >
> > > > > > > > > > > CLASS(xe_force_wake,
> > > > > > > > > > > fw_ref)(gt_to_fw(gt),
> > > > > > > > > > > XE_FW_GT);
> > > > > > > > > > > if (xe->info.platform == XE_PVC ||
> > > > > > > > > > > GRAPHICS_VER(xe)
> > > > > > > > > > > > = 20) {
> > > > > > > > > > > + /* Wait 1-second for the
> > > > > > > > > > > valid
> > > > > > > > > > > bit
> > > > > > > > > > > to be
> > > > > > > > > > > cleared */
> > > > > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > > > > PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > > > > > > + 0,
> > > > > > > > > > > 1000 *
> > > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > > NULL, false);
> > > > > > > > > > > + if (ret) {
> > > > > > > > > > > + pr_info("TLB INVAL
> > > > > > > > > > > cancelled due to
> > > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > > + return -ECANCELED;
> > > > > > > > > > > + }
> > > > > > > > > >
> > > > > > > > > > Is there a reason we aren't waiting after the write
> > > > > > > > > > to
> > > > > > > > > > make
> > > > > > > > > > sure the
> > > > > > > > > > invalidation completed? It seems like we should be
> > > > > > > > > > serializing these
> > > > > > > > > > and at least making sure hardware completes the
> > > > > > > > > > request
> > > > > > > > > > rather than
> > > > > > > > > > just sending and hoping for the best.
> > > > > > > > >
> > > > > > > > > Yes, this is correct—we should after wait issue *if*
> > > > > > > > > this
> > > > > > > > > code
> > > > > > > > > is actually needed.
> > > > > > > >
> > > > > > > > No, the issue is that software cannot issue another TLB
> > > > > > > > invalidation request while the ongoing
> > > > > > > > one has not been completed yet. Otherwise the hardware
> > > > > > > > could
> > > > > > > > potentially lockup.
> > > > > > > > So we need to make sure the valid bit is cleared before
> > > > > > > > issuing
> > > > > > > > another TLB invalidation request.
> > > > > > > >
> > > > > > >
> > > > > > > Yes, but we signal the TLB invalidation fence as complete
> > > > > > > without
> > > > > > > waiting for the hardware to actually finish. The locking
> > > > > > > here
> > > > > > > is
> > > > > > > also
> > > > > > > incorrect for MMIO-based invalidations, now that I think
> > > > > > > about
> > > > > > > it.
> > > > > > > What
> > > > > > > really needs to happen is:
> > > > > > >
> > > > > >
> > > > > > Ah, this actually another weird corner where we take down the
> > > > > > CTs
> > > > > > but
> > > > > > GuC is still using the GAM port...
> > > > > >
> > > > > > > - In send_tlb_inval_ggtt(), if the MMIO path is taken,
> > > > > > > acquire
> > > > > > > a
> > > > > > > per-GT
> > > > > > > MMIO TLB invalidation lock after obtaining the FW
> > > > > >
> > > > > > So maybe 'Wait for the valid bit to clear' here too but this
> > > > > > still
> > > > > > isn't
> > > > > > fully hardend as the GuC could immediately use the GAM port
> > > > > > again...
> > > > > >
> > > > > > Or perhaps we go straight to my suggestion below - when
> > > > > > reloading
> > > > > > the
> > > > > > GuC issue MMIO GT invalidation...
> > > > >
> > > > > I feel like we really should be avoiding these MMIO based
> > > > > invalidations
> > > > > wherever possible. It creates a lot of race conditions like
> > > > > what
> > > > > you
> > > > > suggested or even parallel invalidation between the GuC and KMD
> > > > > while
> > > > > we're tearing down (KMD lock might not be able to guarantee the
> > > > > GuC
> > > > > isn't still invalidating).
> > > > >
> > > >
> > > > My guess is the issue calling xe_managed_bo_reinit_in_vram on
> > > > some
> > > > BOs -
> > > > the GGTT don't get invalidated GuC side and it reloads with stale
> > > > GGTTs.
> > > >
> > > > > Can we instead rely more heavily on the GT reset to flush the
> > > > > TLBs
> > > > > for
> > > >
> > > > We likely need a MMIO invalidate whenever doing PM resume events
> > > > too
> > > > as memory can move without PM refs (CTs go down when PM ref == 0)
> > > > if
> > > > I'm
> > > > not mistaken...
> > >
> > > But we already do a GT reset in that case right? So this should be
> > > covered?
> > >
> >
> > D3hot doesn't perform a GT reset or enter D3cold. However, looking at
> > xe_ggtt.c, GGTT invalidations always hold a PM reference, so the CT
> > should remain live unless a GT reset is in progress.
> >
> > Therefore, the only two cases where we might need MMIO invalidations
> > are:
> >
> > - During initial driver load, after we call
> > xe_managed_bo_reinit_in_vram
> > on some buffers used during the hwconfig GuC load phase, and then
> > move
> > the memory while retaining the same GGTT addresses.
> >
> > - During a GT reset, where memory is allowed to move around. Likely
> > do
> > this step before reloading the GuC.
>
> But for both of these cases, we should be able to do:
> for_each_gt_on_tile()
> xe_tlb_inval_fence_init()
> xe_tlb_inval_all()
> for_each_gt_on_tile()
> xe_tlb_inval_all()
>
> Right before GuC communication goes down right? Then we wouldn't need
> any MMIO communication since the TLBs are flushed at that point.
CTs are live during hwconfig GuC load phase but not so much in the GT
reset case.
What is probably easiest /safest is any place xe_uc_load_hw is called,
do a MMIO invalidation of GuC TLB immediately before (but skip this step
on a VF).
Matt
>
> Thanks,
> Stuart
>
> >
> > > >
> > > > I'd also like the GAM port interaction broken out in component
> > > > like
> > > > xe_gam_port.c (with a dedicated lock) in this seires [1] albiet
> > > > way
> > > > simplier as we only need GGTT invalidates at this time.
> > >
> > > I'd still like to push we find a way to completely remove the MMIO
> > > invalidation from the driver and rely on either the resets or GuC
> > > based
> > > invalidation prior to teardowns if at all possible.
> > >
> >
> > I agree MMIO TLB invalidations have no place xe_guc_tlb_inval.c.
> >
> > Matt
> >
> > > I hadn't seen your other patch yet though. I'll take a look as soon
> > > as
> > > I have time.
> > >
> > > Thanks,
> > > Stuart
> > >
> > > >
> > > > Matt
> > > >
> > > > [1]
> > > > https://patchwork.freedesktop.org/patch/707237/?series=162171&rev=1
> > > >
> > > > > us? And for the GuC memory specifically, maybe we do a full
> > > > > invalidation after quiescing the GuC during hwconfig load (the
> > > > > first
> > > > > time we load the GuC during driver load) and before any kind of
> > > > > reload/reset?
> > > > >
> > > > > We'd still need to cover the case where hardware is fully hung
> > > > > up
> > > > > and
> > > > > GuC isn't responding, but then I don't know that we really care
> > > > > about
> > > > > MMIO based invalidations since we'll want to fully reset the GT
> > > > > there
> > > > > too.
> > > > >
> > > > > Thanks,
> > > > > Stuart
> > > > >
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > > > - Issue the TLB invalidation
> > > > > > > - Wait for the valid bit to clear
> > > > > > > - Release the GT MMIO TLB invalidation lock
> > > > > > >
> > > > > > > Without this lock, two threads could both observe the valid
> > > > > > > bit
> > > > > > > clearing
> > > > > > > and then both attempt to issue invalidations, clobbering
> > > > > > > each
> > > > > > > other.
> > > > > > >
> > > > > > > > > This is early Xe code from me, and it’s questionable
> > > > > > > > > whether
> > > > > > > > > it’s even required.
> > > > > > > >
> > > > > > > > This seems to be required, otherwise modprobe would fail
> > > > > > > > at
> > > > > > > > golden context submission,
> > > > > > > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0: GT0:
> > > > > > > > hwe
> > > > > > > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > > > > > > >
> > > > > > >
> > > > > > > I’m somewhat surprised by this. A better solution might be
> > > > > > > to
> > > > > > > drop
> > > > > > > the
> > > > > > > MMIO GT invalidation code in xe_guc_tlb_inval.c and instead
> > > > > > > issue
> > > > > > > an
> > > > > > > MMIO GGTT invalidation whenever we reload the GuC.
> > > > > > >
> > > > > > > We can defer trying this until later, as it is a riskier
> > > > > > > change.
> > > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > > > > Typically, if the CTs are not live, the GuC isn’t doing
> > > > > > > > > anything meaningful in terms of
> > > > > > > > > referencing memory that the KMD is moving around (which
> > > > > > > > > would
> > > > > > > > > require an invalidation).
> > > > > > > > > So this entire flow of issuing a GAM port TLB
> > > > > > > > > invalidation
> > > > > > > > > is,
> > > > > > > > > again, questionable.
> > > > > > > > >
> > > > > > > > > So I'd suggest move the wait after issue, plus throw
> > > > > > > > > in:
> > > > > > > > >
> > > > > > > > > “XXX: Why do we need to invalidate GGTT memory when the
> > > > > > > > > CTs
> > > > > > > > > are
> > > > > > > > > not live? This suggests
> > > > > > > > > the GuC is still in the load phase. Investigate and
> > > > > > > > > remove
> > > > > > > > > this
> > > > > > > > > code once confirmed.'
> > > > > > > >
> > > > > > > > The issue is a consequence of an earlier failure which
> > > > > > > > caused
> > > > > > > > the
> > > > > > > > CT to be disabled. And the KMD
> > > > > > > > sees a bunch of TLB invalidation timeouts.
> > > > > > > > At this time I would expect a GT reset, but that is not
> > > > > > > > how
> > > > > > > > Xe
> > > > > > > > behaves (the ole i915 driver triggers
> > > > > > > > a GT reset on TLB invalidation timeout if I remember
> > > > > > > > correctly)
> > > > > > > >
> > > > > > > > -Fei
> > > > > > > >
> > > > > > > > > Matt
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Stuart
> > > > > > > > > >
> > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > > > > > > >
> > > > > > > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > > > > >
> > > > > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > > > > > > } else {
> > > > > > > > > > > + /* Wait 1-second for the
> > > > > > > > > > > valid
> > > > > > > > > > > bit
> > > > > > > > > > > to be
> > > > > > > > > > > cleared */
> > > > > > > > > > > + ret = xe_mmio_wait32(mmio,
> > > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > > > > > > + 0,
> > > > > > > > > > > 1000 *
> > > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > > NULL, false);
> > > > > > > > > > > + if (ret) {
> > > > > > > > > > > + pr_info("TLB INVAL
> > > > > > > > > > > cancelled due to
> > > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > > + return -ECANCELED;
> > > > > > > > > > > + }
> > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > > >
> > > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > > > > > > }
> > > > > > > > > >
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-25 22:38 ` Matthew Brost
@ 2026-03-25 22:43 ` Summers, Stuart
2026-03-26 0:54 ` Matthew Brost
0 siblings, 1 reply; 21+ messages in thread
From: Summers, Stuart @ 2026-03-25 22:43 UTC (permalink / raw)
To: Brost, Matthew; +Cc: intel-xe@lists.freedesktop.org, Yang, Fei
On Wed, 2026-03-25 at 15:38 -0700, Matthew Brost wrote:
> On Wed, Mar 25, 2026 at 04:25:22PM -0600, Summers, Stuart wrote:
> > On Wed, 2026-03-25 at 15:00 -0700, Matthew Brost wrote:
> > > On Wed, Mar 25, 2026 at 12:37:18PM -0600, Summers, Stuart wrote:
> > > > On Tue, 2026-03-24 at 16:36 -0700, Matthew Brost wrote:
> > > > > On Tue, Mar 24, 2026 at 03:10:41PM -0600, Summers, Stuart
> > > > > wrote:
> > > > > > On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> > > > > > > On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost
> > > > > > > wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei
> > > > > > > > wrote:
> > > > > > > > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers,
> > > > > > > > > > Stuart
> > > > > > > > > > wrote:
> > > > > > > > > > > On Tue, 2026-03-17 at 16:21 -0700,
> > > > > > > > > > > fei.yang@intel.com wrote:
> > > > > > > > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > > > > > > > >
> > > > > > > > > > > > Hardware requires the software to poll the
> > > > > > > > > > > > valid
> > > > > > > > > > > > bit
> > > > > > > > > > > > and
> > > > > > > > > > > > make sure
> > > > > > > > > > > > it's cleared before issuing a new TLB
> > > > > > > > > > > > invalidation
> > > > > > > > > > > > request.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15
> > > > > > > > > > > > +++++++++++++++
> > > > > > > > > > > > 1 file changed, 15 insertions(+)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git
> > > > > > > > > > > > a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > @@ -63,6 +63,7 @@ static int
> > > > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > > > xe_tlb_inval
> > > > > > > > > > > > *tlb_inval, u32 seqno)
> > > > > > > > > > > > struct xe_guc *guc = tlb_inval-
> > > > > > > > > > > > >private;
> > > > > > > > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > > > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > > > > > > > + int ret;
> > > > > > > > > > > >
> > > > > > > > > > > > /*
> > > > > > > > > > > > * Returning -ECANCELED in this
> > > > > > > > > > > > function is
> > > > > > > > > > > > squashed at the
> > > > > > > > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > > > > > > > >
> > > > > > > > > > > > CLASS(xe_force_wake,
> > > > > > > > > > > > fw_ref)(gt_to_fw(gt),
> > > > > > > > > > > > XE_FW_GT);
> > > > > > > > > > > > if (xe->info.platform == XE_PVC
> > > > > > > > > > > > ||
> > > > > > > > > > > > GRAPHICS_VER(xe)
> > > > > > > > > > > > > = 20) {
> > > > > > > > > > > > + /* Wait 1-second for
> > > > > > > > > > > > the
> > > > > > > > > > > > valid
> > > > > > > > > > > > bit
> > > > > > > > > > > > to be
> > > > > > > > > > > > cleared */
> > > > > > > > > > > > + ret =
> > > > > > > > > > > > xe_mmio_wait32(mmio,
> > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > > > > > > > + 0,
> > > > > > > > > > > > 1000 *
> > > > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > > > NULL, false);
> > > > > > > > > > > > + if (ret) {
> > > > > > > > > > > > + pr_info("TLB
> > > > > > > > > > > > INVAL
> > > > > > > > > > > > cancelled due to
> > > > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > > > + return -
> > > > > > > > > > > > ECANCELED;
> > > > > > > > > > > > + }
> > > > > > > > > > >
> > > > > > > > > > > Is there a reason we aren't waiting after the
> > > > > > > > > > > write
> > > > > > > > > > > to
> > > > > > > > > > > make
> > > > > > > > > > > sure the
> > > > > > > > > > > invalidation completed? It seems like we should
> > > > > > > > > > > be
> > > > > > > > > > > serializing these
> > > > > > > > > > > and at least making sure hardware completes the
> > > > > > > > > > > request
> > > > > > > > > > > rather than
> > > > > > > > > > > just sending and hoping for the best.
> > > > > > > > > >
> > > > > > > > > > Yes, this is correct—we should after wait issue
> > > > > > > > > > *if*
> > > > > > > > > > this
> > > > > > > > > > code
> > > > > > > > > > is actually needed.
> > > > > > > > >
> > > > > > > > > No, the issue is that software cannot issue another
> > > > > > > > > TLB
> > > > > > > > > invalidation request while the ongoing
> > > > > > > > > one has not been completed yet. Otherwise the
> > > > > > > > > hardware
> > > > > > > > > could
> > > > > > > > > potentially lockup.
> > > > > > > > > So we need to make sure the valid bit is cleared
> > > > > > > > > before
> > > > > > > > > issuing
> > > > > > > > > another TLB invalidation request.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yes, but we signal the TLB invalidation fence as
> > > > > > > > complete
> > > > > > > > without
> > > > > > > > waiting for the hardware to actually finish. The
> > > > > > > > locking
> > > > > > > > here
> > > > > > > > is
> > > > > > > > also
> > > > > > > > incorrect for MMIO-based invalidations, now that I
> > > > > > > > think
> > > > > > > > about
> > > > > > > > it.
> > > > > > > > What
> > > > > > > > really needs to happen is:
> > > > > > > >
> > > > > > >
> > > > > > > Ah, this actually another weird corner where we take down
> > > > > > > the
> > > > > > > CTs
> > > > > > > but
> > > > > > > GuC is still using the GAM port...
> > > > > > >
> > > > > > > > - In send_tlb_inval_ggtt(), if the MMIO path is taken,
> > > > > > > > acquire
> > > > > > > > a
> > > > > > > > per-GT
> > > > > > > > MMIO TLB invalidation lock after obtaining the FW
> > > > > > >
> > > > > > > So maybe 'Wait for the valid bit to clear' here too but
> > > > > > > this
> > > > > > > still
> > > > > > > isn't
> > > > > > > fully hardend as the GuC could immediately use the GAM
> > > > > > > port
> > > > > > > again...
> > > > > > >
> > > > > > > Or perhaps we go straight to my suggestion below - when
> > > > > > > reloading
> > > > > > > the
> > > > > > > GuC issue MMIO GT invalidation...
> > > > > >
> > > > > > I feel like we really should be avoiding these MMIO based
> > > > > > invalidations
> > > > > > wherever possible. It creates a lot of race conditions like
> > > > > > what
> > > > > > you
> > > > > > suggested or even parallel invalidation between the GuC and
> > > > > > KMD
> > > > > > while
> > > > > > we're tearing down (KMD lock might not be able to guarantee
> > > > > > the
> > > > > > GuC
> > > > > > isn't still invalidating).
> > > > > >
> > > > >
> > > > > My guess is the issue calling xe_managed_bo_reinit_in_vram on
> > > > > some
> > > > > BOs -
> > > > > the GGTT don't get invalidated GuC side and it reloads with
> > > > > stale
> > > > > GGTTs.
> > > > >
> > > > > > Can we instead rely more heavily on the GT reset to flush
> > > > > > the
> > > > > > TLBs
> > > > > > for
> > > > >
> > > > > We likely need a MMIO invalidate whenever doing PM resume
> > > > > events
> > > > > too
> > > > > as memory can move without PM refs (CTs go down when PM ref
> > > > > == 0)
> > > > > if
> > > > > I'm
> > > > > not mistaken...
> > > >
> > > > But we already do a GT reset in that case right? So this should
> > > > be
> > > > covered?
> > > >
> > >
> > > D3hot doesn't perform a GT reset or enter D3cold. However,
> > > looking at
> > > xe_ggtt.c, GGTT invalidations always hold a PM reference, so the
> > > CT
> > > should remain live unless a GT reset is in progress.
> > >
> > > Therefore, the only two cases where we might need MMIO
> > > invalidations
> > > are:
> > >
> > > - During initial driver load, after we call
> > > xe_managed_bo_reinit_in_vram
> > > on some buffers used during the hwconfig GuC load phase, and
> > > then
> > > move
> > > the memory while retaining the same GGTT addresses.
> > >
> > > - During a GT reset, where memory is allowed to move around.
> > > Likely
> > > do
> > > this step before reloading the GuC.
> >
> > But for both of these cases, we should be able to do:
> > for_each_gt_on_tile()
> > xe_tlb_inval_fence_init()
> > xe_tlb_inval_all()
> > for_each_gt_on_tile()
> > xe_tlb_inval_all()
> >
> > Right before GuC communication goes down right? Then we wouldn't
> > need
> > any MMIO communication since the TLBs are flushed at that point.
>
> CTs are live during hwconfig GuC load phase but not so much in the GT
> reset case.
>
> What is probably easiest /safest is any place xe_uc_load_hw is
> called,
> do a MMIO invalidation of GuC TLB immediately before (but skip this
> step
> on a VF).
We need a way to quiesce GuC and HW if we're going to do this. We could
issue the reset and disable CT communication, but GuC still is in the
middle of performing a TLB invalidation, thus conflicting with ours.
For the GT reset case are you worried about a situation where the
hardware is busted and we reset after the fact to recover? Or a more
explicit invalidation in a TDR scenario? In the former, I wouldn't
think any invalidation would matter there. In the latter, it still
seems like we could invalidate TLBs explicitly through GuC before
disabling CT communication and writing GDRST.
And on that note, the GT reset I would think should clear the TLBs for
us. Do we really care about any explicit invalidation from the KMD in
that case? It seems like the main interesting case here is the time
between the hwconfig GuC load and the main GuC load where we overwrite
the same memory and thus need to flush.
Thanks,
Stuart
>
> Matt
>
> >
> > Thanks,
> > Stuart
> >
> > >
> > > > >
> > > > > I'd also like the GAM port interaction broken out in
> > > > > component
> > > > > like
> > > > > xe_gam_port.c (with a dedicated lock) in this seires [1]
> > > > > albiet
> > > > > way
> > > > > simplier as we only need GGTT invalidates at this time.
> > > >
> > > > I'd still like to push we find a way to completely remove the
> > > > MMIO
> > > > invalidation from the driver and rely on either the resets or
> > > > GuC
> > > > based
> > > > invalidation prior to teardowns if at all possible.
> > > >
> > >
> > > I agree MMIO TLB invalidations have no place xe_guc_tlb_inval.c.
> > >
> > > Matt
> > >
> > > > I hadn't seen your other patch yet though. I'll take a look as
> > > > soon
> > > > as
> > > > I have time.
> > > >
> > > > Thanks,
> > > > Stuart
> > > >
> > > > >
> > > > > Matt
> > > > >
> > > > > [1]
> > > > > https://patchwork.freedesktop.org/patch/707237/?series=162171&rev=1
> > > > >
> > > > > > us? And for the GuC memory specifically, maybe we do a full
> > > > > > invalidation after quiescing the GuC during hwconfig load
> > > > > > (the
> > > > > > first
> > > > > > time we load the GuC during driver load) and before any
> > > > > > kind of
> > > > > > reload/reset?
> > > > > >
> > > > > > We'd still need to cover the case where hardware is fully
> > > > > > hung
> > > > > > up
> > > > > > and
> > > > > > GuC isn't responding, but then I don't know that we really
> > > > > > care
> > > > > > about
> > > > > > MMIO based invalidations since we'll want to fully reset
> > > > > > the GT
> > > > > > there
> > > > > > too.
> > > > > >
> > > > > > Thanks,
> > > > > > Stuart
> > > > > >
> > > > > > >
> > > > > > > Matt
> > > > > > >
> > > > > > > > - Issue the TLB invalidation
> > > > > > > > - Wait for the valid bit to clear
> > > > > > > > - Release the GT MMIO TLB invalidation lock
> > > > > > > >
> > > > > > > > Without this lock, two threads could both observe the
> > > > > > > > valid
> > > > > > > > bit
> > > > > > > > clearing
> > > > > > > > and then both attempt to issue invalidations,
> > > > > > > > clobbering
> > > > > > > > each
> > > > > > > > other.
> > > > > > > >
> > > > > > > > > > This is early Xe code from me, and it’s
> > > > > > > > > > questionable
> > > > > > > > > > whether
> > > > > > > > > > it’s even required.
> > > > > > > > >
> > > > > > > > > This seems to be required, otherwise modprobe would
> > > > > > > > > fail
> > > > > > > > > at
> > > > > > > > > golden context submission,
> > > > > > > > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0:
> > > > > > > > > GT0:
> > > > > > > > > hwe
> > > > > > > > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > > > > > > > >
> > > > > > > >
> > > > > > > > I’m somewhat surprised by this. A better solution might
> > > > > > > > be
> > > > > > > > to
> > > > > > > > drop
> > > > > > > > the
> > > > > > > > MMIO GT invalidation code in xe_guc_tlb_inval.c and
> > > > > > > > instead
> > > > > > > > issue
> > > > > > > > an
> > > > > > > > MMIO GGTT invalidation whenever we reload the GuC.
> > > > > > > >
> > > > > > > > We can defer trying this until later, as it is a
> > > > > > > > riskier
> > > > > > > > change.
> > > > > > > >
> > > > > > > > Matt
> > > > > > > >
> > > > > > > > > > Typically, if the CTs are not live, the GuC isn’t
> > > > > > > > > > doing
> > > > > > > > > > anything meaningful in terms of
> > > > > > > > > > referencing memory that the KMD is moving around
> > > > > > > > > > (which
> > > > > > > > > > would
> > > > > > > > > > require an invalidation).
> > > > > > > > > > So this entire flow of issuing a GAM port TLB
> > > > > > > > > > invalidation
> > > > > > > > > > is,
> > > > > > > > > > again, questionable.
> > > > > > > > > >
> > > > > > > > > > So I'd suggest move the wait after issue, plus
> > > > > > > > > > throw
> > > > > > > > > > in:
> > > > > > > > > >
> > > > > > > > > > “XXX: Why do we need to invalidate GGTT memory when
> > > > > > > > > > the
> > > > > > > > > > CTs
> > > > > > > > > > are
> > > > > > > > > > not live? This suggests
> > > > > > > > > > the GuC is still in the load phase. Investigate and
> > > > > > > > > > remove
> > > > > > > > > > this
> > > > > > > > > > code once confirmed.'
> > > > > > > > >
> > > > > > > > > The issue is a consequence of an earlier failure
> > > > > > > > > which
> > > > > > > > > caused
> > > > > > > > > the
> > > > > > > > > CT to be disabled. And the KMD
> > > > > > > > > sees a bunch of TLB invalidation timeouts.
> > > > > > > > > At this time I would expect a GT reset, but that is
> > > > > > > > > not
> > > > > > > > > how
> > > > > > > > > Xe
> > > > > > > > > behaves (the ole i915 driver triggers
> > > > > > > > > a GT reset on TLB invalidation timeout if I remember
> > > > > > > > > correctly)
> > > > > > > > >
> > > > > > > > > -Fei
> > > > > > > > >
> > > > > > > > > > Matt
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Stuart
> > > > > > > > > > >
> > > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > > > > > > > >
> > > > > > > > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > > > > > >
> > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > > > > > > > } else {
> > > > > > > > > > > > + /* Wait 1-second for
> > > > > > > > > > > > the
> > > > > > > > > > > > valid
> > > > > > > > > > > > bit
> > > > > > > > > > > > to be
> > > > > > > > > > > > cleared */
> > > > > > > > > > > > + ret =
> > > > > > > > > > > > xe_mmio_wait32(mmio,
> > > > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > > > > > > > + 0,
> > > > > > > > > > > > 1000 *
> > > > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > > > NULL, false);
> > > > > > > > > > > > + if (ret) {
> > > > > > > > > > > > + pr_info("TLB
> > > > > > > > > > > > INVAL
> > > > > > > > > > > > cancelled due to
> > > > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > > > + return -
> > > > > > > > > > > > ECANCELED;
> > > > > > > > > > > > + }
> > > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > > > >
> > > > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > > > > > > > }
> > > > > > > > > > >
> > > > > >
> > > >
> >
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-03-25 22:43 ` Summers, Stuart
@ 2026-03-26 0:54 ` Matthew Brost
0 siblings, 0 replies; 21+ messages in thread
From: Matthew Brost @ 2026-03-26 0:54 UTC (permalink / raw)
To: Summers, Stuart; +Cc: intel-xe@lists.freedesktop.org, Yang, Fei
On Wed, Mar 25, 2026 at 04:43:33PM -0600, Summers, Stuart wrote:
> On Wed, 2026-03-25 at 15:38 -0700, Matthew Brost wrote:
> > On Wed, Mar 25, 2026 at 04:25:22PM -0600, Summers, Stuart wrote:
> > > On Wed, 2026-03-25 at 15:00 -0700, Matthew Brost wrote:
> > > > On Wed, Mar 25, 2026 at 12:37:18PM -0600, Summers, Stuart wrote:
> > > > > On Tue, 2026-03-24 at 16:36 -0700, Matthew Brost wrote:
> > > > > > On Tue, Mar 24, 2026 at 03:10:41PM -0600, Summers, Stuart
> > > > > > wrote:
> > > > > > > On Tue, 2026-03-24 at 13:58 -0700, Matthew Brost wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 01:53:27PM -0700, Matthew Brost
> > > > > > > > wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 02:39:54PM -0600, Yang, Fei
> > > > > > > > > wrote:
> > > > > > > > > > > On Tue, Mar 17, 2026 at 05:28:14PM -0600, Summers,
> > > > > > > > > > > Stuart
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Tue, 2026-03-17 at 16:21 -0700,
> > > > > > > > > > > > fei.yang@intel.com wrote:
> > > > > > > > > > > > > From: Fei Yang <fei.yang@intel.com>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hardware requires the software to poll the
> > > > > > > > > > > > > valid
> > > > > > > > > > > > > bit
> > > > > > > > > > > > > and
> > > > > > > > > > > > > make sure
> > > > > > > > > > > > > it's cleared before issuing a new TLB
> > > > > > > > > > > > > invalidation
> > > > > > > > > > > > > request.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Fei Yang <fei.yang@intel.com>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 15
> > > > > > > > > > > > > +++++++++++++++
> > > > > > > > > > > > > 1 file changed, 15 insertions(+)
> > > > > > > > > > > > >
> > > > > > > > > > > > > diff --git
> > > > > > > > > > > > > a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > > b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > > index ced58f46f846..4c2f87db3167 100644
> > > > > > > > > > > > > --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > > +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> > > > > > > > > > > > > @@ -63,6 +63,7 @@ static int
> > > > > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > > > > xe_tlb_inval
> > > > > > > > > > > > > *tlb_inval, u32 seqno)
> > > > > > > > > > > > > struct xe_guc *guc = tlb_inval-
> > > > > > > > > > > > > >private;
> > > > > > > > > > > > > struct xe_gt *gt = guc_to_gt(guc);
> > > > > > > > > > > > > struct xe_device *xe = guc_to_xe(guc);
> > > > > > > > > > > > > + int ret;
> > > > > > > > > > > > >
> > > > > > > > > > > > > /*
> > > > > > > > > > > > > * Returning -ECANCELED in this
> > > > > > > > > > > > > function is
> > > > > > > > > > > > > squashed at the
> > > > > > > > > > > > > caller and @@ -85,11 +86,25 @@ static int
> > > > > > > > > > > > > send_tlb_inval_ggtt(struct
> > > > > > > > > > > > > xe_tlb_inval *tlb_inval, u32 seqno)
> > > > > > > > > > > > >
> > > > > > > > > > > > > CLASS(xe_force_wake,
> > > > > > > > > > > > > fw_ref)(gt_to_fw(gt),
> > > > > > > > > > > > > XE_FW_GT);
> > > > > > > > > > > > > if (xe->info.platform == XE_PVC
> > > > > > > > > > > > > ||
> > > > > > > > > > > > > GRAPHICS_VER(xe)
> > > > > > > > > > > > > > = 20) {
> > > > > > > > > > > > > + /* Wait 1-second for
> > > > > > > > > > > > > the
> > > > > > > > > > > > > valid
> > > > > > > > > > > > > bit
> > > > > > > > > > > > > to be
> > > > > > > > > > > > > cleared */
> > > > > > > > > > > > > + ret =
> > > > > > > > > > > > > xe_mmio_wait32(mmio,
> > > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID,
> > > > > > > > > > > > > + 0,
> > > > > > > > > > > > > 1000 *
> > > > > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > > > > NULL, false);
> > > > > > > > > > > > > + if (ret) {
> > > > > > > > > > > > > + pr_info("TLB
> > > > > > > > > > > > > INVAL
> > > > > > > > > > > > > cancelled due to
> > > > > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > > > > + return -
> > > > > > > > > > > > > ECANCELED;
> > > > > > > > > > > > > + }
> > > > > > > > > > > >
> > > > > > > > > > > > Is there a reason we aren't waiting after the
> > > > > > > > > > > > write
> > > > > > > > > > > > to
> > > > > > > > > > > > make
> > > > > > > > > > > > sure the
> > > > > > > > > > > > invalidation completed? It seems like we should
> > > > > > > > > > > > be
> > > > > > > > > > > > serializing these
> > > > > > > > > > > > and at least making sure hardware completes the
> > > > > > > > > > > > request
> > > > > > > > > > > > rather than
> > > > > > > > > > > > just sending and hoping for the best.
> > > > > > > > > > >
> > > > > > > > > > > Yes, this is correct—we should after wait issue
> > > > > > > > > > > *if*
> > > > > > > > > > > this
> > > > > > > > > > > code
> > > > > > > > > > > is actually needed.
> > > > > > > > > >
> > > > > > > > > > No, the issue is that software cannot issue another
> > > > > > > > > > TLB
> > > > > > > > > > invalidation request while the ongoing
> > > > > > > > > > one has not been completed yet. Otherwise the
> > > > > > > > > > hardware
> > > > > > > > > > could
> > > > > > > > > > potentially lockup.
> > > > > > > > > > So we need to make sure the valid bit is cleared
> > > > > > > > > > before
> > > > > > > > > > issuing
> > > > > > > > > > another TLB invalidation request.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Yes, but we signal the TLB invalidation fence as
> > > > > > > > > complete
> > > > > > > > > without
> > > > > > > > > waiting for the hardware to actually finish. The
> > > > > > > > > locking
> > > > > > > > > here
> > > > > > > > > is
> > > > > > > > > also
> > > > > > > > > incorrect for MMIO-based invalidations, now that I
> > > > > > > > > think
> > > > > > > > > about
> > > > > > > > > it.
> > > > > > > > > What
> > > > > > > > > really needs to happen is:
> > > > > > > > >
> > > > > > > >
> > > > > > > > Ah, this actually another weird corner where we take down
> > > > > > > > the
> > > > > > > > CTs
> > > > > > > > but
> > > > > > > > GuC is still using the GAM port...
> > > > > > > >
> > > > > > > > > - In send_tlb_inval_ggtt(), if the MMIO path is taken,
> > > > > > > > > acquire
> > > > > > > > > a
> > > > > > > > > per-GT
> > > > > > > > > MMIO TLB invalidation lock after obtaining the FW
> > > > > > > >
> > > > > > > > So maybe 'Wait for the valid bit to clear' here too but
> > > > > > > > this
> > > > > > > > still
> > > > > > > > isn't
> > > > > > > > fully hardend as the GuC could immediately use the GAM
> > > > > > > > port
> > > > > > > > again...
> > > > > > > >
> > > > > > > > Or perhaps we go straight to my suggestion below - when
> > > > > > > > reloading
> > > > > > > > the
> > > > > > > > GuC issue MMIO GT invalidation...
> > > > > > >
> > > > > > > I feel like we really should be avoiding these MMIO based
> > > > > > > invalidations
> > > > > > > wherever possible. It creates a lot of race conditions like
> > > > > > > what
> > > > > > > you
> > > > > > > suggested or even parallel invalidation between the GuC and
> > > > > > > KMD
> > > > > > > while
> > > > > > > we're tearing down (KMD lock might not be able to guarantee
> > > > > > > the
> > > > > > > GuC
> > > > > > > isn't still invalidating).
> > > > > > >
> > > > > >
> > > > > > My guess is the issue calling xe_managed_bo_reinit_in_vram on
> > > > > > some
> > > > > > BOs -
> > > > > > the GGTT don't get invalidated GuC side and it reloads with
> > > > > > stale
> > > > > > GGTTs.
> > > > > >
> > > > > > > Can we instead rely more heavily on the GT reset to flush
> > > > > > > the
> > > > > > > TLBs
> > > > > > > for
> > > > > >
> > > > > > We likely need a MMIO invalidate whenever doing PM resume
> > > > > > events
> > > > > > too
> > > > > > as memory can move without PM refs (CTs go down when PM ref
> > > > > > == 0)
> > > > > > if
> > > > > > I'm
> > > > > > not mistaken...
> > > > >
> > > > > But we already do a GT reset in that case right? So this should
> > > > > be
> > > > > covered?
> > > > >
> > > >
> > > > D3hot doesn't perform a GT reset or enter D3cold. However,
> > > > looking at
> > > > xe_ggtt.c, GGTT invalidations always hold a PM reference, so the
> > > > CT
> > > > should remain live unless a GT reset is in progress.
> > > >
> > > > Therefore, the only two cases where we might need MMIO
> > > > invalidations
> > > > are:
> > > >
> > > > - During initial driver load, after we call
> > > > xe_managed_bo_reinit_in_vram
> > > > on some buffers used during the hwconfig GuC load phase, and
> > > > then
> > > > move
> > > > the memory while retaining the same GGTT addresses.
> > > >
> > > > - During a GT reset, where memory is allowed to move around.
> > > > Likely
> > > > do
> > > > this step before reloading the GuC.
> > >
> > > But for both of these cases, we should be able to do:
> > > for_each_gt_on_tile()
> > > xe_tlb_inval_fence_init()
> > > xe_tlb_inval_all()
> > > for_each_gt_on_tile()
> > > xe_tlb_inval_all()
> > >
> > > Right before GuC communication goes down right? Then we wouldn't
> > > need
> > > any MMIO communication since the TLBs are flushed at that point.
> >
> > CTs are live during hwconfig GuC load phase but not so much in the GT
> > reset case.
> >
> > What is probably easiest /safest is any place xe_uc_load_hw is
> > called,
> > do a MMIO invalidation of GuC TLB immediately before (but skip this
> > step
> > on a VF).
>
> We need a way to quiesce GuC and HW if we're going to do this. We could
> issue the reset and disable CT communication, but GuC still is in the
> middle of performing a TLB invalidation, thus conflicting with ours.
>
Yes, through the layers we always call xe_guc_reset before
xe_uc_load_hw. Based on Fei’s observations, a GDRST doesn’t wipe out
the TLBs, so the best place for an MMIO TLB invalidate of the GuC TLBs
may actually be in xe_guc_reset after the GDRST completes.
> For the GT reset case are you worried about a situation where the
> hardware is busted and we reset after the fact to recover? Or a more
No — we wedge the device if GDRST fails, and then (WIP) an FLR can be
issued to recover. I assume an FLR will wipe the TLBs.
> explicit invalidation in a TDR scenario? In the former, I wouldn't
> think any invalidation would matter there. In the latter, it still
> seems like we could invalidate TLBs explicitly through GuC before
> disabling CT communication and writing GDRST.
>
I think placing it after the GDRST is correct, as that ensures the GuC
is no longer using the GAM port. We likely still need the “wait for
valid to clear before + after” semantics in case a GDRST races with the
GuC programming the GAM port.
> And on that note, the GT reset I would think should clear the TLBs for
It doesn’t, based on Fei’s observations, as we do a GDRST before
reloading the GuC after the hwconfig phase. This actually makes sense,
since the GAM and TLBs are separate hardware components from the GuC IP.
> us. Do we really care about any explicit invalidation from the KMD in
> that case? It seems like the main interesting case here is the time
> between the hwconfig GuC load and the main GuC load where we overwrite
> the same memory and thus need to flush.
>
So, the TL;DR of what needs to be done:
- Update xe_guc_tlb_inval.c to blindly send CT-based GGTT invalidations
(like PPGTT invalidations). If the CT is down, the error gets squashed
and the upper layers move on. In other words, drop the MMIO
invalidations.
- Add a xe_gam_port component that has a lock around MMIO (to
future-proof this) and a single function,
xe_gam_port_tlb_inval_ggtt(), which, under the lock, polls for the valid
bit to clear, issues the GGTT invalidation, and then polls again for the
valid bit to clear.
- In xe_guc_reset(), the last thing it does is call
xe_gam_port_tlb_inval_ggtt().
Matt
> Thanks,
> Stuart
>
> >
> > Matt
> >
> > >
> > > Thanks,
> > > Stuart
> > >
> > > >
> > > > > >
> > > > > > I'd also like the GAM port interaction broken out in
> > > > > > component
> > > > > > like
> > > > > > xe_gam_port.c (with a dedicated lock) in this seires [1]
> > > > > > albiet
> > > > > > way
> > > > > > simplier as we only need GGTT invalidates at this time.
> > > > >
> > > > > I'd still like to push we find a way to completely remove the
> > > > > MMIO
> > > > > invalidation from the driver and rely on either the resets or
> > > > > GuC
> > > > > based
> > > > > invalidation prior to teardowns if at all possible.
> > > > >
> > > >
> > > > I agree MMIO TLB invalidations have no place xe_guc_tlb_inval.c.
> > > >
> > > > Matt
> > > >
> > > > > I hadn't seen your other patch yet though. I'll take a look as
> > > > > soon
> > > > > as
> > > > > I have time.
> > > > >
> > > > > Thanks,
> > > > > Stuart
> > > > >
> > > > > >
> > > > > > Matt
> > > > > >
> > > > > > [1]
> > > > > > https://patchwork.freedesktop.org/patch/707237/?series=162171&rev=1
> > > > > >
> > > > > > > us? And for the GuC memory specifically, maybe we do a full
> > > > > > > invalidation after quiescing the GuC during hwconfig load
> > > > > > > (the
> > > > > > > first
> > > > > > > time we load the GuC during driver load) and before any
> > > > > > > kind of
> > > > > > > reload/reset?
> > > > > > >
> > > > > > > We'd still need to cover the case where hardware is fully
> > > > > > > hung
> > > > > > > up
> > > > > > > and
> > > > > > > GuC isn't responding, but then I don't know that we really
> > > > > > > care
> > > > > > > about
> > > > > > > MMIO based invalidations since we'll want to fully reset
> > > > > > > the GT
> > > > > > > there
> > > > > > > too.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Stuart
> > > > > > >
> > > > > > > >
> > > > > > > > Matt
> > > > > > > >
> > > > > > > > > - Issue the TLB invalidation
> > > > > > > > > - Wait for the valid bit to clear
> > > > > > > > > - Release the GT MMIO TLB invalidation lock
> > > > > > > > >
> > > > > > > > > Without this lock, two threads could both observe the
> > > > > > > > > valid
> > > > > > > > > bit
> > > > > > > > > clearing
> > > > > > > > > and then both attempt to issue invalidations,
> > > > > > > > > clobbering
> > > > > > > > > each
> > > > > > > > > other.
> > > > > > > > >
> > > > > > > > > > > This is early Xe code from me, and it’s
> > > > > > > > > > > questionable
> > > > > > > > > > > whether
> > > > > > > > > > > it’s even required.
> > > > > > > > > >
> > > > > > > > > > This seems to be required, otherwise modprobe would
> > > > > > > > > > fail
> > > > > > > > > > at
> > > > > > > > > > golden context submission,
> > > > > > > > > > [ 480.237382] xe 0000:01:00.0: [drm] *ERROR* Tile0:
> > > > > > > > > > GT0:
> > > > > > > > > > hwe
> > > > > > > > > > ccs0: nop emit_nop_job failed (-ETIME) guc_id=4
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I’m somewhat surprised by this. A better solution might
> > > > > > > > > be
> > > > > > > > > to
> > > > > > > > > drop
> > > > > > > > > the
> > > > > > > > > MMIO GT invalidation code in xe_guc_tlb_inval.c and
> > > > > > > > > instead
> > > > > > > > > issue
> > > > > > > > > an
> > > > > > > > > MMIO GGTT invalidation whenever we reload the GuC.
> > > > > > > > >
> > > > > > > > > We can defer trying this until later, as it is a
> > > > > > > > > riskier
> > > > > > > > > change.
> > > > > > > > >
> > > > > > > > > Matt
> > > > > > > > >
> > > > > > > > > > > Typically, if the CTs are not live, the GuC isn’t
> > > > > > > > > > > doing
> > > > > > > > > > > anything meaningful in terms of
> > > > > > > > > > > referencing memory that the KMD is moving around
> > > > > > > > > > > (which
> > > > > > > > > > > would
> > > > > > > > > > > require an invalidation).
> > > > > > > > > > > So this entire flow of issuing a GAM port TLB
> > > > > > > > > > > invalidation
> > > > > > > > > > > is,
> > > > > > > > > > > again, questionable.
> > > > > > > > > > >
> > > > > > > > > > > So I'd suggest move the wait after issue, plus
> > > > > > > > > > > throw
> > > > > > > > > > > in:
> > > > > > > > > > >
> > > > > > > > > > > “XXX: Why do we need to invalidate GGTT memory when
> > > > > > > > > > > the
> > > > > > > > > > > CTs
> > > > > > > > > > > are
> > > > > > > > > > > not live? This suggests
> > > > > > > > > > > the GuC is still in the load phase. Investigate and
> > > > > > > > > > > remove
> > > > > > > > > > > this
> > > > > > > > > > > code once confirmed.'
> > > > > > > > > >
> > > > > > > > > > The issue is a consequence of an earlier failure
> > > > > > > > > > which
> > > > > > > > > > caused
> > > > > > > > > > the
> > > > > > > > > > CT to be disabled. And the KMD
> > > > > > > > > > sees a bunch of TLB invalidation timeouts.
> > > > > > > > > > At this time I would expect a GT reset, but that is
> > > > > > > > > > not
> > > > > > > > > > how
> > > > > > > > > > Xe
> > > > > > > > > > behaves (the ole i915 driver triggers
> > > > > > > > > > a GT reset on TLB invalidation timeout if I remember
> > > > > > > > > > correctly)
> > > > > > > > > >
> > > > > > > > > > -Fei
> > > > > > > > > >
> > > > > > > > > > > Matt
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks,
> > > > > > > > > > > > Stuart
> > > > > > > > > > > >
> > > > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > > > PVC_GUC_TLB_INV_DESC1,
> > > > > > > > > > > > >
> > > > > > > > > > > > > PVC_GUC_TLB_INV_DESC1_INVALID ATE);
> > > > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0,
> > > > > > > > > > > > >
> > > > > > > > > > > > > PVC_GUC_TLB_INV_DESC0_VALID);
> > > > > > > > > > > > > } else {
> > > > > > > > > > > > > + /* Wait 1-second for
> > > > > > > > > > > > > the
> > > > > > > > > > > > > valid
> > > > > > > > > > > > > bit
> > > > > > > > > > > > > to be
> > > > > > > > > > > > > cleared */
> > > > > > > > > > > > > + ret =
> > > > > > > > > > > > > xe_mmio_wait32(mmio,
> > > > > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE,
> > > > > > > > > > > > > + 0,
> > > > > > > > > > > > > 1000 *
> > > > > > > > > > > > > +USEC_PER_MSEC,
> > > > > > > > > > > > > NULL, false);
> > > > > > > > > > > > > + if (ret) {
> > > > > > > > > > > > > + pr_info("TLB
> > > > > > > > > > > > > INVAL
> > > > > > > > > > > > > cancelled due to
> > > > > > > > > > > > > uncleared valid bit\n");
> > > > > > > > > > > > > + return -
> > > > > > > > > > > > > ECANCELED;
> > > > > > > > > > > > > + }
> > > > > > > > > > > > > xe_mmio_write32(mmio,
> > > > > > > > > > > > > GUC_TLB_INV_CR,
> > > > > > > > > > > > >
> > > > > > > > > > > > > GUC_TLB_INV_CR_INVALIDATE);
> > > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > >
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
@ 2026-04-04 6:22 fei.yang
2026-04-06 18:59 ` Matthew Brost
2026-04-06 21:01 ` Matt Roper
0 siblings, 2 replies; 21+ messages in thread
From: fei.yang @ 2026-04-04 6:22 UTC (permalink / raw)
To: intel-xe; +Cc: Fei Yang, Matthew Brost, Stuart Summers
From: Fei Yang <fei.yang@intel.com>
Hardware requires the software to poll the valid bit and make sure it's
cleared before issuing a new TLB invalidation request.
We also need to avoid racing against GuC on TLB invalidations by only
allowing KMD to issue TLB invalidation request during GuC reset.
v2: separate ggtt inval to xe_gam_port and call in guc_reset only (Matt)
Signed-off-by: Fei Yang <fei.yang@intel.com>
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Cc: Stuart Summers <stuart.summers@intel.com>
---
drivers/gpu/drm/xe/Makefile | 1 +
drivers/gpu/drm/xe/xe_gam_port.c | 72 +++++++++++++++++++++++++++
drivers/gpu/drm/xe/xe_gam_port.h | 15 ++++++
drivers/gpu/drm/xe/xe_gt.c | 1 +
drivers/gpu/drm/xe/xe_gt_types.h | 7 +++
drivers/gpu/drm/xe/xe_guc.c | 4 ++
drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 18 -------
7 files changed, 100 insertions(+), 18 deletions(-)
create mode 100644 drivers/gpu/drm/xe/xe_gam_port.c
create mode 100644 drivers/gpu/drm/xe/xe_gam_port.h
diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
index f9abaf687d46..96127ad60e9b 100644
--- a/drivers/gpu/drm/xe/Makefile
+++ b/drivers/gpu/drm/xe/Makefile
@@ -78,6 +78,7 @@ xe-y += xe_bb.o \
xe_guc_rc.o \
xe_guc_submit.o \
xe_guc_tlb_inval.o \
+ xe_gam_port.o \
xe_heci_gsc.o \
xe_huc.o \
xe_hw_engine.o \
diff --git a/drivers/gpu/drm/xe/xe_gam_port.c b/drivers/gpu/drm/xe/xe_gam_port.c
new file mode 100644
index 000000000000..137887cf93b8
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_gam_port.c
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2025 Intel Corporation
+ */
+
+#include "xe_gt_stats.h"
+#include "xe_gt_types.h"
+#include "xe_gt_printk.h"
+#include "xe_mmio.h"
+#include "xe_gam_port.h"
+
+#include "regs/xe_guc_regs.h"
+
+/*
+ * GGTT TLB invalidation as part of GuC reset flow while the communication
+ * between host and GuC is disabled.
+ */
+
+int xe_gam_port_tlb_inval_ggtt(struct xe_gt *gt)
+{
+ struct xe_device *xe = gt_to_xe(gt);
+ struct xe_mmio *mmio = >->mmio;
+ int ret = 0;
+
+ spin_lock(>->mmio_tlb_invl_lock);
+
+ if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe) >= 20) {
+ /* Wait 1-second for the valid bit to be cleared */
+ ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
+ 0, 1000 * USEC_PER_MSEC, NULL, true);
+ if (ret) {
+ ret = -ECANCELED;
+ goto out;
+ }
+
+ xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1, PVC_GUC_TLB_INV_DESC1_INVALIDATE);
+ xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID);
+
+ /* Wait 1-second for the valid bit to be cleared */
+ ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
+ 0, 1000 * USEC_PER_MSEC, NULL, true);
+ if (ret) {
+ ret = -ECANCELED;
+ goto out;
+ }
+ } else {
+ /* Wait 1-second for the valid bit to be cleared */
+ ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE,
+ 0, 1000 * USEC_PER_MSEC, NULL, true);
+ if (ret) {
+ ret = -ECANCELED;
+ goto out;
+ }
+
+ xe_mmio_write32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE);
+
+ /* Wait 1-second for the valid bit to be cleared */
+ ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE,
+ 0, 1000 * USEC_PER_MSEC, NULL, true);
+ if (ret) {
+ ret = -ECANCELED;
+ goto out;
+ }
+ }
+
+out:
+ spin_unlock(>->mmio_tlb_invl_lock);
+
+ if (ret)
+ xe_gt_warn(gt, "TLB INVAL cancelled due to uncleared valid bit\n");
+ return ret;
+}
diff --git a/drivers/gpu/drm/xe/xe_gam_port.h b/drivers/gpu/drm/xe/xe_gam_port.h
new file mode 100644
index 000000000000..b5c383d635f1
--- /dev/null
+++ b/drivers/gpu/drm/xe/xe_gam_port.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2025 Intel Corporation
+ */
+
+#ifndef _XE_GAM_PORT_H_
+#define _XE_GAM_PORT_H_
+
+#include <linux/types.h>
+
+struct xe_gt;
+
+int xe_gam_port_tlb_inval_ggtt(struct xe_gt *gt);
+
+#endif
diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
index 8a31c963c372..6bb990069eff 100644
--- a/drivers/gpu/drm/xe/xe_gt.c
+++ b/drivers/gpu/drm/xe/xe_gt.c
@@ -514,6 +514,7 @@ int xe_gt_init_early(struct xe_gt *gt)
xe_force_wake_init_gt(gt, gt_to_fw(gt));
spin_lock_init(>->global_invl_lock);
+ spin_lock_init(>->mmio_tlb_invl_lock);
err = xe_gt_tlb_inval_init_early(gt);
if (err)
diff --git a/drivers/gpu/drm/xe/xe_gt_types.h b/drivers/gpu/drm/xe/xe_gt_types.h
index 8b55cf25a75f..2418a0b2f19c 100644
--- a/drivers/gpu/drm/xe/xe_gt_types.h
+++ b/drivers/gpu/drm/xe/xe_gt_types.h
@@ -324,6 +324,13 @@ struct xe_gt {
*/
spinlock_t global_invl_lock;
+ /**
+ * @mmio_tlb_invl_lock: prevents back to back TLB invalidation
+ * without polling for hardware clearance for the previous
+ * invalidation
+ */
+ spinlock_t mmio_tlb_invl_lock;
+
/** @wa_active: keep track of active workarounds */
struct {
/** @wa_active.gt: bitmap with active GT workarounds */
diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
index e762eada21db..70eff5b22fbb 100644
--- a/drivers/gpu/drm/xe/xe_guc.c
+++ b/drivers/gpu/drm/xe/xe_guc.c
@@ -48,6 +48,7 @@
#include "xe_uc_fw.h"
#include "xe_wa.h"
#include "xe_wopcm.h"
+#include "xe_gam_port.h"
static u32 guc_bo_ggtt_addr(struct xe_guc *guc,
struct xe_bo *bo)
@@ -991,6 +992,9 @@ int xe_guc_reset(struct xe_guc *guc)
goto err_out;
}
+ if (xe_gam_port_tlb_inval_ggtt(gt))
+ xe_gt_warn(gt, "GGTT TLB invalidation timed out\n");
+
return 0;
err_out:
diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
index ced58f46f846..7c3e63e49760 100644
--- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
+++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
@@ -61,8 +61,6 @@ static int send_tlb_inval_all(struct xe_tlb_inval *tlb_inval, u32 seqno)
static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
{
struct xe_guc *guc = tlb_inval->private;
- struct xe_gt *gt = guc_to_gt(guc);
- struct xe_device *xe = guc_to_xe(guc);
/*
* Returning -ECANCELED in this function is squashed at the caller and
@@ -77,22 +75,6 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
};
return send_tlb_inval(guc, action, ARRAY_SIZE(action));
- } else if (xe_device_uc_enabled(xe) && !xe_device_wedged(xe)) {
- struct xe_mmio *mmio = >->mmio;
-
- if (IS_SRIOV_VF(xe))
- return -ECANCELED;
-
- CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
- if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe) >= 20) {
- xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
- PVC_GUC_TLB_INV_DESC1_INVALIDATE);
- xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
- PVC_GUC_TLB_INV_DESC0_VALID);
- } else {
- xe_mmio_write32(mmio, GUC_TLB_INV_CR,
- GUC_TLB_INV_CR_INVALIDATE);
- }
}
return -ECANCELED;
--
2.43.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-04-04 6:22 [PATCH] " fei.yang
@ 2026-04-06 18:59 ` Matthew Brost
2026-04-06 21:01 ` Matt Roper
1 sibling, 0 replies; 21+ messages in thread
From: Matthew Brost @ 2026-04-06 18:59 UTC (permalink / raw)
To: fei.yang; +Cc: intel-xe, Stuart Summers
On Fri, Apr 03, 2026 at 11:22:49PM -0700, fei.yang@intel.com wrote:
> From: Fei Yang <fei.yang@intel.com>
>
> Hardware requires the software to poll the valid bit and make sure it's
> cleared before issuing a new TLB invalidation request.
> We also need to avoid racing against GuC on TLB invalidations by only
> allowing KMD to issue TLB invalidation request during GuC reset.
>
> v2: separate ggtt inval to xe_gam_port and call in guc_reset only (Matt)
>
I guess CI doesn't like this... Unsure why, clearly missed something in
my suggestion.
Maybe it is best move this new code into xe_guc_tlb_inval.c for TLB now
unless someone really has time to dig in.
Matt
> Signed-off-by: Fei Yang <fei.yang@intel.com>
> Suggested-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Stuart Summers <stuart.summers@intel.com>
> ---
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/xe_gam_port.c | 72 +++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_gam_port.h | 15 ++++++
> drivers/gpu/drm/xe/xe_gt.c | 1 +
> drivers/gpu/drm/xe/xe_gt_types.h | 7 +++
> drivers/gpu/drm/xe/xe_guc.c | 4 ++
> drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 18 -------
> 7 files changed, 100 insertions(+), 18 deletions(-)
> create mode 100644 drivers/gpu/drm/xe/xe_gam_port.c
> create mode 100644 drivers/gpu/drm/xe/xe_gam_port.h
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index f9abaf687d46..96127ad60e9b 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -78,6 +78,7 @@ xe-y += xe_bb.o \
> xe_guc_rc.o \
> xe_guc_submit.o \
> xe_guc_tlb_inval.o \
> + xe_gam_port.o \
> xe_heci_gsc.o \
> xe_huc.o \
> xe_hw_engine.o \
> diff --git a/drivers/gpu/drm/xe/xe_gam_port.c b/drivers/gpu/drm/xe/xe_gam_port.c
> new file mode 100644
> index 000000000000..137887cf93b8
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_gam_port.c
> @@ -0,0 +1,72 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#include "xe_gt_stats.h"
> +#include "xe_gt_types.h"
> +#include "xe_gt_printk.h"
> +#include "xe_mmio.h"
> +#include "xe_gam_port.h"
> +
> +#include "regs/xe_guc_regs.h"
> +
> +/*
> + * GGTT TLB invalidation as part of GuC reset flow while the communication
> + * between host and GuC is disabled.
> + */
> +
> +int xe_gam_port_tlb_inval_ggtt(struct xe_gt *gt)
> +{
> + struct xe_device *xe = gt_to_xe(gt);
> + struct xe_mmio *mmio = >->mmio;
> + int ret = 0;
> +
> + spin_lock(>->mmio_tlb_invl_lock);
> +
> + if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe) >= 20) {
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> +
> + xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1, PVC_GUC_TLB_INV_DESC1_INVALIDATE);
> + xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID);
> +
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> + } else {
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> +
> + xe_mmio_write32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE);
> +
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> + }
> +
> +out:
> + spin_unlock(>->mmio_tlb_invl_lock);
> +
> + if (ret)
> + xe_gt_warn(gt, "TLB INVAL cancelled due to uncleared valid bit\n");
> + return ret;
> +}
> diff --git a/drivers/gpu/drm/xe/xe_gam_port.h b/drivers/gpu/drm/xe/xe_gam_port.h
> new file mode 100644
> index 000000000000..b5c383d635f1
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_gam_port.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#ifndef _XE_GAM_PORT_H_
> +#define _XE_GAM_PORT_H_
> +
> +#include <linux/types.h>
> +
> +struct xe_gt;
> +
> +int xe_gam_port_tlb_inval_ggtt(struct xe_gt *gt);
> +
> +#endif
> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index 8a31c963c372..6bb990069eff 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
> @@ -514,6 +514,7 @@ int xe_gt_init_early(struct xe_gt *gt)
>
> xe_force_wake_init_gt(gt, gt_to_fw(gt));
> spin_lock_init(>->global_invl_lock);
> + spin_lock_init(>->mmio_tlb_invl_lock);
>
> err = xe_gt_tlb_inval_init_early(gt);
> if (err)
> diff --git a/drivers/gpu/drm/xe/xe_gt_types.h b/drivers/gpu/drm/xe/xe_gt_types.h
> index 8b55cf25a75f..2418a0b2f19c 100644
> --- a/drivers/gpu/drm/xe/xe_gt_types.h
> +++ b/drivers/gpu/drm/xe/xe_gt_types.h
> @@ -324,6 +324,13 @@ struct xe_gt {
> */
> spinlock_t global_invl_lock;
>
> + /**
> + * @mmio_tlb_invl_lock: prevents back to back TLB invalidation
> + * without polling for hardware clearance for the previous
> + * invalidation
> + */
> + spinlock_t mmio_tlb_invl_lock;
> +
> /** @wa_active: keep track of active workarounds */
> struct {
> /** @wa_active.gt: bitmap with active GT workarounds */
> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> index e762eada21db..70eff5b22fbb 100644
> --- a/drivers/gpu/drm/xe/xe_guc.c
> +++ b/drivers/gpu/drm/xe/xe_guc.c
> @@ -48,6 +48,7 @@
> #include "xe_uc_fw.h"
> #include "xe_wa.h"
> #include "xe_wopcm.h"
> +#include "xe_gam_port.h"
>
> static u32 guc_bo_ggtt_addr(struct xe_guc *guc,
> struct xe_bo *bo)
> @@ -991,6 +992,9 @@ int xe_guc_reset(struct xe_guc *guc)
> goto err_out;
> }
>
> + if (xe_gam_port_tlb_inval_ggtt(gt))
> + xe_gt_warn(gt, "GGTT TLB invalidation timed out\n");
> +
> return 0;
>
> err_out:
> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> index ced58f46f846..7c3e63e49760 100644
> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> @@ -61,8 +61,6 @@ static int send_tlb_inval_all(struct xe_tlb_inval *tlb_inval, u32 seqno)
> static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
> {
> struct xe_guc *guc = tlb_inval->private;
> - struct xe_gt *gt = guc_to_gt(guc);
> - struct xe_device *xe = guc_to_xe(guc);
>
> /*
> * Returning -ECANCELED in this function is squashed at the caller and
> @@ -77,22 +75,6 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
> };
>
> return send_tlb_inval(guc, action, ARRAY_SIZE(action));
> - } else if (xe_device_uc_enabled(xe) && !xe_device_wedged(xe)) {
> - struct xe_mmio *mmio = >->mmio;
> -
> - if (IS_SRIOV_VF(xe))
> - return -ECANCELED;
> -
> - CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
> - if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe) >= 20) {
> - xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
> - PVC_GUC_TLB_INV_DESC1_INVALIDATE);
> - xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
> - PVC_GUC_TLB_INV_DESC0_VALID);
> - } else {
> - xe_mmio_write32(mmio, GUC_TLB_INV_CR,
> - GUC_TLB_INV_CR_INVALIDATE);
> - }
> }
>
> return -ECANCELED;
> --
> 2.43.0
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval.
2026-04-04 6:22 [PATCH] " fei.yang
2026-04-06 18:59 ` Matthew Brost
@ 2026-04-06 21:01 ` Matt Roper
1 sibling, 0 replies; 21+ messages in thread
From: Matt Roper @ 2026-04-06 21:01 UTC (permalink / raw)
To: fei.yang; +Cc: intel-xe, Matthew Brost, Stuart Summers
On Fri, Apr 03, 2026 at 11:22:49PM -0700, fei.yang@intel.com wrote:
> From: Fei Yang <fei.yang@intel.com>
>
> Hardware requires the software to poll the valid bit and make sure it's
> cleared before issuing a new TLB invalidation request.
> We also need to avoid racing against GuC on TLB invalidations by only
> allowing KMD to issue TLB invalidation request during GuC reset.
>
> v2: separate ggtt inval to xe_gam_port and call in guc_reset only (Matt)
>
> Signed-off-by: Fei Yang <fei.yang@intel.com>
> Suggested-by: Matthew Brost <matthew.brost@intel.com>
> Cc: Stuart Summers <stuart.summers@intel.com>
> ---
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/xe_gam_port.c | 72 +++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_gam_port.h | 15 ++++++
> drivers/gpu/drm/xe/xe_gt.c | 1 +
> drivers/gpu/drm/xe/xe_gt_types.h | 7 +++
> drivers/gpu/drm/xe/xe_guc.c | 4 ++
> drivers/gpu/drm/xe/xe_guc_tlb_inval.c | 18 -------
> 7 files changed, 100 insertions(+), 18 deletions(-)
> create mode 100644 drivers/gpu/drm/xe/xe_gam_port.c
> create mode 100644 drivers/gpu/drm/xe/xe_gam_port.h
>
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index f9abaf687d46..96127ad60e9b 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -78,6 +78,7 @@ xe-y += xe_bb.o \
> xe_guc_rc.o \
> xe_guc_submit.o \
> xe_guc_tlb_inval.o \
> + xe_gam_port.o \
> xe_heci_gsc.o \
> xe_huc.o \
> xe_hw_engine.o \
> diff --git a/drivers/gpu/drm/xe/xe_gam_port.c b/drivers/gpu/drm/xe/xe_gam_port.c
> new file mode 100644
> index 000000000000..137887cf93b8
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_gam_port.c
> @@ -0,0 +1,72 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#include "xe_gt_stats.h"
> +#include "xe_gt_types.h"
> +#include "xe_gt_printk.h"
> +#include "xe_mmio.h"
> +#include "xe_gam_port.h"
> +
> +#include "regs/xe_guc_regs.h"
> +
> +/*
> + * GGTT TLB invalidation as part of GuC reset flow while the communication
> + * between host and GuC is disabled.
> + */
> +
> +int xe_gam_port_tlb_inval_ggtt(struct xe_gt *gt)
> +{
> + struct xe_device *xe = gt_to_xe(gt);
> + struct xe_mmio *mmio = >->mmio;
> + int ret = 0;
> +
> + spin_lock(>->mmio_tlb_invl_lock);
> +
> + if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe) >= 20) {
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> +
> + xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1, PVC_GUC_TLB_INV_DESC1_INVALIDATE);
> + xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID);
> +
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, PVC_GUC_TLB_INV_DESC0, PVC_GUC_TLB_INV_DESC0_VALID,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> + } else {
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> +
> + xe_mmio_write32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE);
> +
> + /* Wait 1-second for the valid bit to be cleared */
> + ret = xe_mmio_wait32(mmio, GUC_TLB_INV_CR, GUC_TLB_INV_CR_INVALIDATE,
> + 0, 1000 * USEC_PER_MSEC, NULL, true);
> + if (ret) {
> + ret = -ECANCELED;
> + goto out;
> + }
> + }
> +
> +out:
> + spin_unlock(>->mmio_tlb_invl_lock);
> +
> + if (ret)
> + xe_gt_warn(gt, "TLB INVAL cancelled due to uncleared valid bit\n");
> + return ret;
> +}
> diff --git a/drivers/gpu/drm/xe/xe_gam_port.h b/drivers/gpu/drm/xe/xe_gam_port.h
> new file mode 100644
> index 000000000000..b5c383d635f1
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_gam_port.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2025 Intel Corporation
> + */
> +
> +#ifndef _XE_GAM_PORT_H_
> +#define _XE_GAM_PORT_H_
> +
> +#include <linux/types.h>
> +
> +struct xe_gt;
> +
> +int xe_gam_port_tlb_inval_ggtt(struct xe_gt *gt);
> +
> +#endif
> diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
> index 8a31c963c372..6bb990069eff 100644
> --- a/drivers/gpu/drm/xe/xe_gt.c
> +++ b/drivers/gpu/drm/xe/xe_gt.c
> @@ -514,6 +514,7 @@ int xe_gt_init_early(struct xe_gt *gt)
>
> xe_force_wake_init_gt(gt, gt_to_fw(gt));
> spin_lock_init(>->global_invl_lock);
> + spin_lock_init(>->mmio_tlb_invl_lock);
>
> err = xe_gt_tlb_inval_init_early(gt);
> if (err)
> diff --git a/drivers/gpu/drm/xe/xe_gt_types.h b/drivers/gpu/drm/xe/xe_gt_types.h
> index 8b55cf25a75f..2418a0b2f19c 100644
> --- a/drivers/gpu/drm/xe/xe_gt_types.h
> +++ b/drivers/gpu/drm/xe/xe_gt_types.h
> @@ -324,6 +324,13 @@ struct xe_gt {
> */
> spinlock_t global_invl_lock;
>
> + /**
> + * @mmio_tlb_invl_lock: prevents back to back TLB invalidation
> + * without polling for hardware clearance for the previous
> + * invalidation
> + */
> + spinlock_t mmio_tlb_invl_lock;
> +
> /** @wa_active: keep track of active workarounds */
> struct {
> /** @wa_active.gt: bitmap with active GT workarounds */
> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> index e762eada21db..70eff5b22fbb 100644
> --- a/drivers/gpu/drm/xe/xe_guc.c
> +++ b/drivers/gpu/drm/xe/xe_guc.c
> @@ -48,6 +48,7 @@
> #include "xe_uc_fw.h"
> #include "xe_wa.h"
> #include "xe_wopcm.h"
> +#include "xe_gam_port.h"
>
> static u32 guc_bo_ggtt_addr(struct xe_guc *guc,
> struct xe_bo *bo)
> @@ -991,6 +992,9 @@ int xe_guc_reset(struct xe_guc *guc)
> goto err_out;
> }
>
> + if (xe_gam_port_tlb_inval_ggtt(gt))
> + xe_gt_warn(gt, "GGTT TLB invalidation timed out\n");
> +
> return 0;
>
> err_out:
> diff --git a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> index ced58f46f846..7c3e63e49760 100644
> --- a/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> +++ b/drivers/gpu/drm/xe/xe_guc_tlb_inval.c
> @@ -61,8 +61,6 @@ static int send_tlb_inval_all(struct xe_tlb_inval *tlb_inval, u32 seqno)
> static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
> {
> struct xe_guc *guc = tlb_inval->private;
> - struct xe_gt *gt = guc_to_gt(guc);
> - struct xe_device *xe = guc_to_xe(guc);
>
> /*
> * Returning -ECANCELED in this function is squashed at the caller and
> @@ -77,22 +75,6 @@ static int send_tlb_inval_ggtt(struct xe_tlb_inval *tlb_inval, u32 seqno)
> };
>
> return send_tlb_inval(guc, action, ARRAY_SIZE(action));
> - } else if (xe_device_uc_enabled(xe) && !xe_device_wedged(xe)) {
> - struct xe_mmio *mmio = >->mmio;
> -
> - if (IS_SRIOV_VF(xe))
> - return -ECANCELED;
> -
> - CLASS(xe_force_wake, fw_ref)(gt_to_fw(gt), XE_FW_GT);
> - if (xe->info.platform == XE_PVC || GRAPHICS_VER(xe) >= 20) {
> - xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC1,
> - PVC_GUC_TLB_INV_DESC1_INVALIDATE);
> - xe_mmio_write32(mmio, PVC_GUC_TLB_INV_DESC0,
> - PVC_GUC_TLB_INV_DESC0_VALID);
> - } else {
> - xe_mmio_write32(mmio, GUC_TLB_INV_CR,
> - GUC_TLB_INV_CR_INVALIDATE);
> - }
It's not clear to me why it's safe to remove this. Aren't we still
required to do GGTT invalidations during initial device probe, before
we're at the point where the CT is running and we can start asking the
GuC to do it on our behalf? We allocate and map various buffers into
the GGTT in order to get the GuC firmware itself loaded and running, so
if we're not doing invalidations on those, I'm not sure the GuC
initialization itself will work?
Is there an assumption that something else like an FLR already did the
invalidation for us and it's safe to update with GGTT without doing
further invalidations? If so, it would be good to explain those flows
in more detail in the commit message.
Matt
> }
>
> return -ECANCELED;
> --
> 2.43.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2026-04-06 21:02 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-17 23:21 [PATCH] drm/xe: Wait for HW clearance before issuing the next TLB inval fei.yang
2026-03-17 23:24 ` ✗ CI.checkpatch: warning for " Patchwork
2026-03-17 23:25 ` ✓ CI.KUnit: success " Patchwork
2026-03-17 23:28 ` [PATCH] " Summers, Stuart
2026-03-22 5:35 ` Matthew Brost
2026-03-24 20:39 ` Yang, Fei
2026-03-24 20:53 ` Matthew Brost
2026-03-24 20:58 ` Matthew Brost
2026-03-24 21:10 ` Summers, Stuart
2026-03-24 23:36 ` Matthew Brost
2026-03-25 18:37 ` Summers, Stuart
2026-03-25 22:00 ` Matthew Brost
2026-03-25 22:25 ` Summers, Stuart
2026-03-25 22:38 ` Matthew Brost
2026-03-25 22:43 ` Summers, Stuart
2026-03-26 0:54 ` Matthew Brost
2026-03-18 0:08 ` ✓ Xe.CI.BAT: success for " Patchwork
2026-03-19 12:33 ` ✓ Xe.CI.FULL: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2026-04-04 6:22 [PATCH] " fei.yang
2026-04-06 18:59 ` Matthew Brost
2026-04-06 21:01 ` Matt Roper
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox