[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Update GUC_KLV_0_KEY definition
== Series Details == Series: drm/i915/guc: Update GUC_KLV_0_KEY definition URL : https://patchwork.freedesktop.org/series/123130/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13583_full -> Patchwork_123130v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_123130v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_123130v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_123130v1_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-suspend@a-dp4: - shard-dg2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-dg2-11/igt@kms_flip@flip-vs-susp...@a-dp4.html Known issues Here are the changes found in Patchwork_123130v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-apl: ([PASS][2], [PASS][3], [PASS][4], [PASS][5], [FAIL][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26]) ([i915#8293]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl4/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl6/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl6/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl6/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl6/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl1/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl1/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl1/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl1/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl2/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl2/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl2/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl4/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl4/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl7/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl7/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl2/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl2/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-apl2/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/shard-a
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use vblank worker to unpin old legacy cursor fb safely
== Series Details == Series: drm/i915: Use vblank worker to unpin old legacy cursor fb safely URL : https://patchwork.freedesktop.org/series/123125/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13583_full -> Patchwork_123125v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_123125v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_123125v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 10) -- Additional (1): shard-tglu0 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_123125v1_full: ### IGT changes ### Possible regressions * igt@gem_lmem_swapping@parallel-random-verify@lmem0: - shard-dg2: NOTRUN -> [ABORT][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-dg2-3/igt@gem_lmem_swapping@parallel-random-ver...@lmem0.html * igt@gem_lmem_swapping@verify@lmem0: - shard-dg1: [PASS][2] -> [ABORT][3] +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-dg1-17/igt@gem_lmem_swapping@ver...@lmem0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-dg1-19/igt@gem_lmem_swapping@ver...@lmem0.html - shard-dg2: [PASS][4] -> [ABORT][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-dg2-1/igt@gem_lmem_swapping@ver...@lmem0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-dg2-8/igt@gem_lmem_swapping@ver...@lmem0.html * igt@kms_universal_plane@cursor-fb-leak-pipe-a: - shard-snb: [PASS][6] -> [FAIL][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-snb6/igt@kms_universal_pl...@cursor-fb-leak-pipe-a.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-snb2/igt@kms_universal_pl...@cursor-fb-leak-pipe-a.html * igt@kms_universal_plane@cursor-fb-leak-pipe-b: - shard-rkl: [PASS][8] -> [FAIL][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-rkl-2/igt@kms_universal_pl...@cursor-fb-leak-pipe-b.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-rkl-7/igt@kms_universal_pl...@cursor-fb-leak-pipe-b.html - shard-dg1: [PASS][10] -> [FAIL][11] +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-dg1-12/igt@kms_universal_pl...@cursor-fb-leak-pipe-b.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-dg1-12/igt@kms_universal_pl...@cursor-fb-leak-pipe-b.html - shard-snb: NOTRUN -> [FAIL][12] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-snb6/igt@kms_universal_pl...@cursor-fb-leak-pipe-b.html * igt@kms_universal_plane@cursor-fb-leak-pipe-c: - shard-dg2: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-dg2-1/igt@kms_universal_pl...@cursor-fb-leak-pipe-c.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-dg2-8/igt@kms_universal_pl...@cursor-fb-leak-pipe-c.html * igt@kms_universal_plane@cursor-fb-leak-pipe-d: - shard-dg2: NOTRUN -> [FAIL][15] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-dg2-3/igt@kms_universal_pl...@cursor-fb-leak-pipe-d.html Warnings * igt@i915_module_load@resize-bar: - shard-dg1: [SKIP][16] ([i915#7178]) -> [ABORT][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-dg1-12/igt@i915_module_l...@resize-bar.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/shard-dg1-12/igt@i915_module_l...@resize-bar.html Known issues Here are the changes found in Patchwork_123125v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-apl: ([PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [FAIL][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42]) ([i915#8293]) -> ([PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58], [PASS][59], [PASS][60], [PASS][61], [PASS][62], [PASS][63], [PASS][64], [PASS][65], [PASS][66], [PASS][67]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/shard-apl1/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/s
[Intel-gfx] [PATCH] drm/i915: Add Wa_14015150844
Disables Atomic-chaining of Typed Writes.
BSpec: 54040
Signed-off-by: Shekhar Chauhan
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 0e4c638fcbbf..a00ff51c681d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1218,6 +1218,8 @@
#define XEHP_HDC_CHICKEN0 MCR_REG(0xe5f0)
#define LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK REG_GENMASK(13,
11)
+#define DIS_ATOMIC_CHAINING_TYPED_WRITES REG_BIT(3)
+
#define ICL_HDC_MODE MCR_REG(0xe5f4)
#define EU_PERF_CNTL2 PERF_REG(0xe658)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 864d41bcf6bb..70071ead0659 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2327,6 +2327,14 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK);
}
+ if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
+ IS_DG2(i915)) {
+ /* Wa_14015150844 */
+ wa_mcr_add(wal, XEHP_HDC_CHICKEN0, 0,
+ _MASKED_BIT_ENABLE(DIS_ATOMIC_CHAINING_TYPED_WRITES),
+ 0, true);
+ }
+
if (IS_DG2_G11(i915) || IS_DG2_G10(i915)) {
/* Wa_22014600077:dg2 */
wa_mcr_add(wal, GEN10_CACHE_MODE_SS, 0,
--
2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for WQ_UNBOUND warning since recent workqueue refactoring
== Series Details == Series: WQ_UNBOUND warning since recent workqueue refactoring URL : https://patchwork.freedesktop.org/series/123134/ State : success == Summary == CI Bug Log - changes from CI_DRM_13583 -> Patchwork_123134v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/index.html Participating hosts (38 -> 39) -- Additional (2): fi-kbl-soraka bat-rpls-2 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_123134v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-2: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@info: - bat-rpls-2: NOTRUN -> [SKIP][2] ([i915#1849] / [i915#2582]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@fb...@info.html * igt@fbdev@read: - bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#2582]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@fb...@read.html * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [PASS][4] -> [INCOMPLETE][5] ([i915#6311]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-rpls-2: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-rpls-2: NOTRUN -> [SKIP][9] ([i915#3282]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-rpls-2: NOTRUN -> [SKIP][10] ([i915#7561]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-rpls-2: NOTRUN -> [SKIP][11] ([i915#6621]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][12] -> [ABORT][13] ([i915#7911] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][14] ([i915#5334] / [i915#7872]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html - fi-apl-guc: [PASS][15] -> [DMESG-FAIL][16] ([i915#5334]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][17] ([i915#4258] / [i915#7913]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][18] ([i915#1886] / [i915#7913]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_busy@basic: - bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#1845]) +16 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/bat-rpls-2/igt@kms_b...@basic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-kbl-soraka: NOTRUN -> [SKIP][20] ([fdo#109271]) +8 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123134v1/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-dpms: - bat-rpls-2: NOTRUN -> [SKIP][21] ([i915#3637]) +3 similar issues [21]: https://intel
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for WQ_UNBOUND warning since recent workqueue refactoring
== Series Details ==
Series: WQ_UNBOUND warning since recent workqueue refactoring
URL : https://patchwork.freedesktop.org/series/123134/
State : warning
== Summary ==
Error: dim checkpatch failed
f4ee63f6c28e WQ_UNBOUND warning since recent workqueue refactoring
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
>>> Recently I started to see the following warning on linux-next and presumably
-:45: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit cfd48ad8c4a9 ("drm/i915: Fix HPD
polling, reenabling the output poll work as needed")'
#45:
> after cfd48ad8c4a9 ("drm/i915: Fix HPD polling, reenabling the output poll
> work as needed")
-:102: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 2 errors, 1 warnings, 0 checks, 24 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Use list_for_each_entry() helper
== Series Details == Series: drm/i915/gvt: Use list_for_each_entry() helper URL : https://patchwork.freedesktop.org/series/123133/ State : success == Summary == CI Bug Log - changes from CI_DRM_13583 -> Patchwork_123133v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/index.html Participating hosts (38 -> 39) -- Additional (2): fi-kbl-soraka bat-rpls-2 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_123133v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-2: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@info: - bat-rpls-2: NOTRUN -> [SKIP][2] ([i915#1849] / [i915#2582]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@fb...@info.html * igt@fbdev@read: - bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#2582]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@fb...@read.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#3282]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-rpls-2: NOTRUN -> [SKIP][8] ([i915#7561]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-rpls-2: NOTRUN -> [SKIP][9] ([i915#6621]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#5334] / [i915#7872]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][11] ([i915#4258] / [i915#7913]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][12] ([i915#1886] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-dg2-11: [PASS][13] -> [DMESG-FAIL][14] ([i915#7913]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html * igt@kms_busy@basic: - bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#1845]) +16 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@kms_b...@basic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-kbl-soraka: NOTRUN -> [SKIP][16] ([fdo#109271]) +8 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-dpms: - bat-rpls-2: NOTRUN -> [SKIP][17] ([i915#3637]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@kms_f...@basic-flip-vs-dpms.html * igt@kms_force_connector_basic@force-load-detect: - bat-rpls-2: NOTRUN -> [SKIP][18] ([fdo#109285]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#1849]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123133v1/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html * igt@kms_psr@sprite_plane_onoff: - bat-rpls-2: NOTRUN -> [SKIP][20] ([i915#1072]) +3 simila
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Update GUC_KLV_0_KEY definition
== Series Details ==
Series: drm/i915/guc: Update GUC_KLV_0_KEY definition
URL : https://patchwork.freedesktop.org/series/123130/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13583 -> Patchwork_123130v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/index.html
Participating hosts (38 -> 37)
--
Additional (1): bat-rpls-2
Missing(2): bat-dg2-9 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_123130v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-rpls-2: NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html
* igt@fbdev@info:
- bat-rpls-2: NOTRUN -> [SKIP][2] ([i915#1849] / [i915#2582])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@fb...@info.html
* igt@fbdev@read:
- bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#2582]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@fb...@read.html
* igt@gem_lmem_swapping@verify-random:
- bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#7561])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#6621])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_pm:
- bat-rpls-2: NOTRUN -> [DMESG-FAIL][8] ([i915#4258] / [i915#7913])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@kms_busy@basic:
- bat-rpls-2: NOTRUN -> [SKIP][9] ([i915#1845]) +16 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@kms_b...@basic.html
* igt@kms_flip@basic-flip-vs-dpms:
- bat-rpls-2: NOTRUN -> [SKIP][10] ([i915#3637]) +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-rpls-2: NOTRUN -> [SKIP][11] ([fdo#109285])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_frontbuffer_tracking@basic:
- bat-rpls-2: NOTRUN -> [SKIP][12] ([i915#1849])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][13] -> [ABORT][14] ([i915#8442] / [i915#8668])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
* igt@kms_psr@sprite_plane_onoff:
- bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#3555])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-flip:
- bat-rpls-2: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#1845] /
[i915#3708])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@prime_v...@basic-fence-flip.html
* igt@prime_vgem@basic-fence-read:
- bat-rpls-2: NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3708]) +2
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123130v1/bat-rpls-2/igt@prime_v...@basic-fence-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[Intel XE#485]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/485
[fdo#109285]: https://bugs.freedeskto
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev11)
== Series Details ==
Series: drm/i915/gvt: KVM: KVMGT fixes and page-track cleanups (rev11)
URL : https://patchwork.freedesktop.org/series/112196/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/112196/revisions/11/mbox/ not
applied
Applying: drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page"
Applying: drm/i915/gvt: remove interface intel_gvt_is_valid_gfn
Applying: drm/i915/gvt: Verify hugepages are contiguous in physical address
space
Applying: drm/i915/gvt: Don't try to unpin an empty page range
Applying: drm/i915/gvt: Put the page reference obtained by KVM's gfn_to_pfn()
Applying: drm/i915/gvt: Explicitly check that vGPU is attached before shadowing
Applying: drm/i915/gvt: Error out on an attempt to shadowing an unknown GTT
entry type
Applying: drm/i915/gvt: Don't rely on KVM's gfn_to_pfn() to query possible 2M
GTT
Applying: drm/i915/gvt: Use an "unsigned long" to iterate over memslot gfns
Applying: drm/i915/gvt: Drop unused helper intel_vgpu_reset_gtt()
Applying: drm/i915/gvt: Protect gfn hash table with vgpu_lock
Applying: KVM: x86/mmu: Move kvm_arch_flush_shadow_{all, memslot}() to mmu.c
Applying: KVM: x86/mmu: Don't rely on page-track mechanism to flush on memslot
change
Applying: KVM: x86/mmu: Don't bounce through page-track mechanism for guest PTEs
Applying: KVM: drm/i915/gvt: Drop @vcpu from KVM's ->track_write() hook
Applying: KVM: x86: Reject memslot MOVE operations if KVMGT is attached
error: corrupt patch at line 6
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0016 KVM: x86: Reject memslot MOVE operations if KVMGT is
attached
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Build failed, no error log produced
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Update GUC_KLV_0_KEY definition
== Series Details == Series: drm/i915/guc: Update GUC_KLV_0_KEY definition URL : https://patchwork.freedesktop.org/series/123130/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Update GUC_KLV_0_KEY definition
== Series Details == Series: drm/i915/guc: Update GUC_KLV_0_KEY definition URL : https://patchwork.freedesktop.org/series/123130/ State : warning == Summary == Error: dim checkpatch failed aadae3354910 drm/i915/guc: Update GUC_KLV_0_KEY definition -:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #14: inlined from ‘__guc_context_set_prio.isra.48’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3332:3, -:42: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed by Closes: with a URL to the report #42: Reported-by: Linyu Yuan Signed-off-by: Michal Wajdeczko total: 0 errors, 2 warnings, 0 checks, 8 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use vblank worker to unpin old legacy cursor fb safely
== Series Details ==
Series: drm/i915: Use vblank worker to unpin old legacy cursor fb safely
URL : https://patchwork.freedesktop.org/series/123125/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13583 -> Patchwork_123125v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/index.html
Participating hosts (38 -> 37)
--
Additional (1): bat-rpls-2
Missing(2): fi-kbl-x1275 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_123125v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-rpls-2: NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html
* igt@fbdev@info:
- bat-rpls-2: NOTRUN -> [SKIP][2] ([i915#1849] / [i915#2582])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@fb...@info.html
* igt@fbdev@read:
- bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#2582]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@fb...@read.html
* igt@gem_lmem_swapping@verify-random:
- bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_tiled_pread_basic:
- bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-rpls-2: NOTRUN -> [SKIP][6] ([i915#7561])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rps@basic-api:
- bat-rpls-2: NOTRUN -> [SKIP][7] ([i915#6621])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_pm:
- bat-rpls-2: NOTRUN -> [DMESG-FAIL][8] ([i915#4258] / [i915#7913])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@kms_busy@basic:
- bat-rpls-2: NOTRUN -> [SKIP][9] ([i915#1845]) +16 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@kms_b...@basic.html
* igt@kms_flip@basic-flip-vs-dpms:
- bat-rpls-2: NOTRUN -> [SKIP][10] ([i915#3637]) +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-rpls-2: NOTRUN -> [SKIP][11] ([fdo#109285])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_frontbuffer_tracking@basic:
- bat-rpls-2: NOTRUN -> [SKIP][12] ([i915#1849])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-2:
- bat-dg1-5: [PASS][13] -> [FAIL][14] ([fdo#103375])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-dg1-5/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-2.html
* igt@kms_psr@sprite_plane_onoff:
- bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#3555])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-flip:
- bat-rpls-2: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#1845] /
[i915#3708])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@prime_v...@basic-fence-flip.html
* igt@prime_vgem@basic-fence-read:
- bat-rpls-2: NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3708]) +2
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123125v1/bat-rpls-2/igt@prime_v...@basic-fence-read.html
Possible fixes
* igt@kms_chamelium_edid@hdmi-edid-read:
- {bat-dg2-13}: [DMESG-WARN][19] ([i915#7952]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-dg2-13/igt@kms_chamelium_e...@hdmi-edid-read.html
[20]:
h
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add Wa_14015150844 (rev2)
== Series Details == Series: drm/i915: Add Wa_14015150844 (rev2) URL : https://patchwork.freedesktop.org/series/123074/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13583 -> Patchwork_123074v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_123074v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_123074v2, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/index.html Participating hosts (38 -> 38) -- Additional (2): fi-kbl-soraka bat-rpls-2 Missing(2): fi-tgl-1115g4 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_123074v2: ### IGT changes ### Possible regressions * igt@gem_exec_fence@basic-await@vcs1: - bat-mtlp-6: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-mtlp-6/igt@gem_exec_fence@basic-aw...@vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-mtlp-6/igt@gem_exec_fence@basic-aw...@vcs1.html Known issues Here are the changes found in Patchwork_123074v2 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-2: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@info: - bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#1849] / [i915#2582]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@fb...@info.html * igt@fbdev@read: - bat-rpls-2: NOTRUN -> [SKIP][5] ([i915#2582]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@fb...@read.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-rpls-2: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-rpls-2: NOTRUN -> [SKIP][9] ([i915#3282]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-rpls-2: NOTRUN -> [SKIP][10] ([i915#7561]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-rpls-2: NOTRUN -> [SKIP][11] ([i915#6621]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_pm: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][12] ([i915#4258] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@i915_selftest@live@gt_pm.html - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][13] ([i915#1886] / [i915#7913]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_busy@basic: - bat-rpls-2: NOTRUN -> [SKIP][14] ([i915#1845]) +16 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@kms_b...@basic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/fi-kbl-soraka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_flip@basic-flip-vs-dpms: - bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#3637]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@kms_f...@basic-flip-vs-dpms.html * igt@kms_force_connector_basic@force-load-detect: - bat-rpls-2: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123074v2/bat-rpls-2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - bat-rpls-2: NOTRUN -> [SKIP][18] ([i915#1
[Intel-gfx] ✗ Fi.CI.BAT: failure for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/123117/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13583 -> Patchwork_123117v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_123117v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_123117v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/index.html Participating hosts (38 -> 39) -- Additional (2): fi-kbl-soraka bat-rpls-2 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_123117v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_lrc: - bat-dg1-5: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-dg1-5/igt@i915_selftest@live@gt_lrc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-dg1-5/igt@i915_selftest@live@gt_lrc.html - fi-rkl-11600: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/fi-rkl-11600/igt@i915_selftest@live@gt_lrc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/fi-rkl-11600/igt@i915_selftest@live@gt_lrc.html - bat-mtlp-8: [PASS][5] -> [ABORT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-mtlp-8/igt@i915_selftest@live@gt_lrc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-mtlp-8/igt@i915_selftest@live@gt_lrc.html - bat-adlm-1: [PASS][7] -> [ABORT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-adlm-1/igt@i915_selftest@live@gt_lrc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-adlm-1/igt@i915_selftest@live@gt_lrc.html - fi-tgl-1115g4: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/fi-tgl-1115g4/igt@i915_selftest@live@gt_lrc.html - bat-rpls-1: [PASS][11] -> [ABORT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-rpls-1/igt@i915_selftest@live@gt_lrc.html - bat-mtlp-6: [PASS][13] -> [ABORT][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13583/bat-mtlp-6/igt@i915_selftest@live@gt_lrc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-mtlp-6/igt@i915_selftest@live@gt_lrc.html Known issues Here are the changes found in Patchwork_123117v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-2: NOTRUN -> [SKIP][15] ([i915#7456]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@info: - bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#1849] / [i915#2582]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-rpls-2/igt@fb...@info.html * igt@fbdev@read: - bat-rpls-2: NOTRUN -> [SKIP][17] ([i915#2582]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-rpls-2/igt@fb...@read.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@verify-random: - bat-rpls-2: NOTRUN -> [SKIP][20] ([i915#4613]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-rpls-2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-rpls-2: NOTRUN -> [SKIP][21] ([i915#3282]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-rpls-2/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-rpls-2: NOTRUN -> [SKIP][22] ([i915#7561]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123117v1/bat-rpls-2/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-rpls-2: NOTR
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/123117/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Apply Wa_16018031267 / Wa_16018063123
== Series Details == Series: Apply Wa_16018031267 / Wa_16018063123 URL : https://patchwork.freedesktop.org/series/123117/ State : warning == Summary == Error: dim checkpatch failed aa56c62d03ba drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 -:10: WARNING:BAD_SIGN_OFF: Co-developed-by: should not be used to attribute nominal patch author 'Nirmoy Das ' #10: Co-developed-by: Nirmoy Das -:10: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do not match #10: Co-developed-by: Nirmoy Das Signed-off-by: Jonathan Cavitt -:35: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'engine' - possible side-effects? #35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS) -:35: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'engine' may be better as '(engine)' to avoid precedence issues #35: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:86: +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \ + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \ + engine->class == COPY_ENGINE_CLASS) -:68: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #68: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:836: + GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1); -:187: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #187: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1465: + GEM_BUG_ON(cs - start > I915_GTT_PAGE_SIZE / sizeof(*cs)); -:373: ERROR:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Nirmoy Das ' total: 1 errors, 4 warnings, 2 checks, 323 lines checked e506f946b484 drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
On 8/25/2023 7:33 AM, Javier Pello wrote:
There is an assertion in ggtt_reserve_guc_top that the global GTT
is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit
platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc
("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON
is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the
subsequent reservation fails and the driver fails to initialise
the device:
i915 :00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT
for GuC
i915 :00:02.0: Device initialization failed (-28)
i915 :00:02.0: Please file a bug on drm/i915; see
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for
details.
i915: probe of :00:02.0 failed with error -28
Make the reservation at the top of the available space, whatever
that is, instead of assuming that the top will be GUC_GGTT_TOP.
Fixes: 911800765ef6 ("drm/i915/uc: Reserve upper range of GGTT")
For tracking, it might be good to also add:
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9080
Signed-off-by: Javier Pello
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org # v5.3+
Need the full CC list here, so that when the patch gets back-ported the
relevant developers get automatically added.
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index e9328e1a..0157bebb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -511,20 +511,29 @@ void intel_ggtt_unbind_vma(struct i915_address_space *vm,
vm->clear_range(vm, vma_res->start, vma_res->vma_size);
}
+/* Reserve the top of the GuC address space for firmware images. Addresses
+ * beyond GUC_GGTT_TOP in the GuC address space are inaccessible by GuC,
+ * which makes for a suitable range to hold GuC/HuC firmware images if the
+ * size of the GGTT is 4G. However, on a 32-bit platform the size of the GGTT
+ * is limited to 2G, which is less than GUC_GGTT_TOP, but we reserve a chunk
+ * of the same size anyway, which is far more than needed, to keep the logic
+ * in uc_fw_ggtt_offset() simple. */
Style: multi-line comment should be formatted as:
/*
* Text
* more text
*/
+#define GUC_TOP_RESERVE_SIZE (SZ_4G - GUC_GGTT_TOP)
+
static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt)
{
- u64 size;
+ u64 offset;
int ret;
if (!intel_uc_uses_guc(&ggtt->vm.gt->uc))
return 0;
- GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP);
- size = ggtt->vm.total - GUC_GGTT_TOP;
+ GEM_BUG_ON(ggtt->vm.total <= GUC_TOP_RESERVE_SIZE);
+ offset = ggtt->vm.total - GUC_TOP_RESERVE_SIZE;
- ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw, size,
- GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE,
- PIN_NOEVICT);
+ ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &ggtt->uc_fw,
+ GUC_TOP_RESERVE_SIZE, offset,
+ I915_COLOR_UNEVICTABLE, PIN_NOEVICT);
The code change looks good to me, so with the style fix and the
additions to the commit message this is:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
if (ret)
drm_dbg(&ggtt->vm.i915->drm,
"Failed to reserve top of GGTT for GuC\n");
Re: [Intel-gfx] [PATCH v5] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset
On 8/31/2023 07:00, Andi Shyti wrote:
Hi,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a0e3ef1c65d2..600388c849f7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1359,7 +1359,16 @@ static void guc_enable_busyness_worker(struct intel_guc
*guc)
static void guc_cancel_busyness_worker(struct intel_guc *guc)
{
- cancel_delayed_work_sync(&guc->timestamp.work);
+ /*
+* When intel_gt_reset was called, task will hold a lock.
+* To cacel delayed work here, the _sync version will also acquire a
lock, which might
+* trigger the possible cirular locking dependency warning.
+* Check the reset_in_progress flag, call async verion if reset is in
progress.
+*/
This needs to explain in much more detail what is going on and why it is not
a problem. E.g.:
The busyness worker needs to be cancelled. In general that means
using the synchronous cancel version to ensure that an in-progress
worker will not keep executing beyond whatever is happening that
needs the cancel. E.g. suspend, driver unload, etc. However, in the
case of a reset, the synchronous version is not required and can
trigger a false deadlock detection warning.
The business worker takes the reset mutex to protect against resets
interfering with it. However, it does a trylock and bails out if the
reset lock is already acquired. Thus there is no actual deadlock or
other concern with the worker running concurrently with a reset. So
an asynchronous cancel is safe in the case of a reset rather than a
driver unload or suspend type operation. On the other hand, if the
cancel_sync version is used when a reset is in progress then the
mutex deadlock detection sees the mutex being acquired through
multiple paths and complains.
So just don't bother. That keeps the detection code happy and is
safe because of the trylock code described above.
So why do we even need to cancel anything if it doesn't do anything while
the reset is in progress?
It still needs to be cancelled. The worker only aborts if it is actively
executing concurrently with the reset. It might not start to execute until
after the reset has completed. And there is presumably a reason why the
cancel is being called, a reason not necessarily related to resets at all.
Leaving the worker to run arbitrarily after the driver is expecting it to be
stopped will lead to much worse things than a fake lockdep splat, e.g. a use
after free pointer deref.
I was actually thinking why not leave things as they are and just
disable lockdep from CI. This doesn't look like a relevant report
to me.
Andi
Disable lockdep? The whole of lockdep? We absolutely do not want to
disable an extremely important deadlock testing infrastructure in our
test framework. That would be defeating the whole point of CI.
Potentially we could annotate this one particular scenario to suppress
this one particular error. But it seems simpler and safer to just
update the code to not hit that scenario in the first place.
John.
Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()
On 2023-08-30 01:29, Jani Nikula wrote: On Tue, 29 Aug 2023, Alex Hung wrote: On 2023-08-29 11:03, Jani Nikula wrote: On Tue, 29 Aug 2023, Jani Nikula wrote: On Tue, 29 Aug 2023, Alex Deucher wrote: On Tue, Aug 29, 2023 at 6:48 AM Jani Nikula wrote: On Wed, 23 Aug 2023, Jani Nikula wrote: On Tue, 22 Aug 2023, Alex Hung wrote: On 2023-08-22 06:01, Jani Nikula wrote: Over the past years I've been trying to unify the override and firmware EDID handling as well as EDID property updates. It won't work if drivers do their own random things. Let's check how to replace these references by appropriate ones or fork the function as reverting these patches causes regressions. I think the fundamental problem you have is conflating connector forcing with EDID override. They're orthogonal. The .force callback has no business basing the decisions on connector->edid_override. Force is force, override is override. The driver isn't even supposed to know or care if the EDID originates from the firmware loader or override EDID debugfs. drm_get_edid() will handle that for you transparently. It'll return the EDID, and you shouldn't look at connector->edid_blob_ptr either. Using that will make future work in drm_edid.c harder. You can't fix that with minor tweaks. I think you'll be better off starting from scratch. Also, connector->edid_override is debugfs. You actually can change the behaviour. If your userspace, whatever it is, has been written to assume connector forcing if EDID override is set, you *do* have to fix that, and set both. Any updates on fixing this, or shall we proceed with the reverts? There is a patch under internal reviews. It removes calls edid_override and drm_edid_override_connector_update as intended in this patchset but does not remove the functionality. While I am happy to hear there's progress, I'm somewhat baffled the review is internal. The commits that I suggested to revert were also only reviewed internally, as far as I can see... And that's kind of the problem. Upstream code should be reviewed in public. Hi Jani, All patches are sent for public reviews, the progress is summarized as the followings: == internal == 1. a patch or patches are tested by CI. 2. internal technical and IP reviews are performed to ensure no concerns before patches are merged to internal branch. == public == 3. a regression test and IP reviews are performed by engineers before sending to public mailing lists. 4. the patchset is sent for public reviews ex. https://patchwork.freedesktop.org/series/122498/ 5. patches are merged to public repo. BR, Jani. With the patch. both following git grep commands return nothing in amd-staging-drm-next. $ git grep drm_edid_override_connector_update -- drivers/gpu/drm/amd $ git grep edid_override -- drivers/gpu/drm/amd Best regards, Alex Hung What is the goal of the reverts? I don't disagree that we may be using the interfaces wrong, but reverting them will regess functionality in the driver. The commits are in v6.5-rc1, but not yet in a release. No user depends on them yet. I'd strongly prefer them not reaching v6.5 final and users. Sorry for confusion here, that's obviously come and gone already. :( The firmware EDID, override EDID, connector forcing, the EDID property, etc. have been and somewhat still are a hairy mess that we must keep untangling, and this isn't helping. I've put in crazy amounts of work on this, and I've added kernel-doc comments about stuff that should and should not be done, but they go unread and ignored. I really don't want to end up having to clean this up myself before I can embark on further cleanups and refactoring. And again, if the functionality in the driver depends on conflating two things that should be separate, it's probably not such a hot idea to let it reach users either. Even if it's just debugfs. BR, Jani.
Re: [Intel-gfx] WQ_UNBOUND warning since recent workqueue refactoring
On 30.08.2023 20:56, Imre Deak wrote:
> On Wed, Aug 30, 2023 at 07:51:13AM -1000, Tejun Heo wrote:
> Hi,
>
>> Hello,
>>
>> (cc'ing i915 folks)
>>
>> On Wed, Aug 30, 2023 at 04:57:42PM +0200, Heiner Kallweit wrote:
>>> Recently I started to see the following warning on linux-next and presumably
>>> this may be related to the refactoring of the workqueue core code.
>>>
>>> [ 56.900223] workqueue: output_poll_execute [drm_kms_helper] hogged CPU
>>> for >1us 4 times, consider switching to WQ_UNBOUND
>>> [ 56.923226] workqueue: i915_hpd_poll_init_work [i915] hogged CPU for
>>> >1us 4 times, consider switching to WQ_UNBOUND
>>> [ 97.860430] workqueue: output_poll_execute [drm_kms_helper] hogged CPU
>>> for >1us 8 times, consider switching to WQ_UNBOUND
>>> [ 97.884453] workqueue: i915_hpd_poll_init_work [i915] hogged CPU for
>>> >1us 8 times, consider switching to WQ_UNBOUND
>>>
>>> Adding WQ_UNBOUND to these queues didn't change the behavior.
>>
>> That should have made them go away as the code path isn't active at all for
>> WQ_UNBOUND workqueues. Can you please double check?
>>
I tried the patch given below and double-checked. No change in behavior.
>>> Maybe relevant: I run the affected system headless.
>>
>> i915 folks, workqueue recently added debug warnings which trigger when a
>> per-cpu work item hogs the CPU for too long - 10ms in this case. This is
>> problematic because such work item can stall other per-cpu work items.
>>
>> * Is it expected for the above two work functions to occupy the CPU for over
>> 10ms repeatedly?
>
> No, this shouldn't happen.
>
> I assume it happens in
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
> after cfd48ad8c4a9 ("drm/i915: Fix HPD polling, reenabling the output poll
> work as needed")
>
> which could result in the above problem.
>
> Could you give a try to
> https://lore.kernel.org/all/20230809104307.1218058-1-imre.d...@intel.com/
>
Didn't help
> and if that doesn't help provide more information/logs, by opening a
> ticket at:
> https://gitlab.freedesktop.org/drm/intel/-/issues/new
>
> Thanks,
> Imre
>
>> * If so, can we make them use an unbound workqueue instead?
>>
>> Thanks.
>>
>> --
>> tejun
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 3f479483d..ac28b8d0f 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -279,7 +279,7 @@ static void reschedule_output_poll_work(struct drm_device
*dev)
*/
delay = HZ;
- schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
+ queue_delayed_work(system_unbound_wq,
&dev->mode_config.output_poll_work, delay);
}
/**
@@ -614,7 +614,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
*/
dev->mode_config.delayed_event = true;
if (dev->mode_config.poll_enabled)
- mod_delayed_work(system_wq,
+ mod_delayed_work(system_unbound_wq,
&dev->mode_config.output_poll_work,
0);
}
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index ec4d26b3c..c0592b77b 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -138,7 +138,7 @@ static int i915_workqueues_init(struct drm_i915_private
*dev_priv)
* to be scheduled on the system_wq before moving to a driver
* instance due deprecation of flush_scheduled_work().
*/
- dev_priv->unordered_wq = alloc_workqueue("i915-unordered", 0, 0);
+ dev_priv->unordered_wq = alloc_workqueue("i915-unordered", WQ_UNBOUND,
0);
if (dev_priv->unordered_wq == NULL)
goto out_free_dp_wq;
--
2.42.0
Re: [Intel-gfx] [PATCH 4/6] drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid
On 24/08/2023 15:46, Jani Nikula wrote:
> Connectors have source physical address available in display
> info. There's no need to parse the EDID again for this. Add
> drm_dp_cec_attach() to do this.
>
> Seems like the set_edid/unset_edid naming is a bit specific now that
> there's no need to pass the EDID at all, so aim for attach/detach going
> forward.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/display/drm_dp_cec.c | 22 +++---
> include/drm/display/drm_dp_helper.h | 6 ++
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_cec.c
> b/drivers/gpu/drm/display/drm_dp_cec.c
> index ae39dc794190..da7a7d357446 100644
> --- a/drivers/gpu/drm/display/drm_dp_cec.c
> +++ b/drivers/gpu/drm/display/drm_dp_cec.c
> @@ -297,7 +297,7 @@ static void drm_dp_cec_unregister_work(struct work_struct
> *work)
> * were unchanged and just update the CEC physical address. Otherwise
> * unregister the old CEC adapter and create a new one.
> */
> -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address)
> {
> struct drm_connector *connector = aux->cec.connector;
> u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> @@ -339,7 +339,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (aux->cec.adap->capabilities == cec_caps &&
> aux->cec.adap->available_log_addrs == num_las) {
> /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(adap, source_physical_address, false);
As the kernel test robot indicated, this does not compile, this should
be aux->cec.adap.
> goto unlock;
> }
> /*
> @@ -370,11 +370,27 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>* from drm_dp_cec_register_connector() edid == NULL, so in
>* that case the phys addr is just invalidated.
>*/
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(adap, source_physical_address, false);
> }
> unlock:
> mutex_unlock(&aux->cec.lock);
> }
> +EXPORT_SYMBOL(drm_dp_cec_attach);
> +
> +/*
> + * Note: Prefer calling drm_dp_cec_attach() with
> + * connector->display_info.source_physical_address if possible.
> + */
> +void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +{
> + u16 source_physical_address = CEC_PHYS_ADDR_INVALID;
> +
> + if (edid && edid->extensions)
And this source needs to include , also as found by
the kernel test robot.
Regards,
Hans
> + pa = cec_get_edid_phys_addr((const u8 *)edid,
> + EDID_LENGTH * (edid->extensions +
> 1), NULL);
> +
> + drm_dp_cec_attach(aux, source_physical_address);
> +}
> EXPORT_SYMBOL(drm_dp_cec_set_edid);
>
> /*
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 86f24a759268..3369104e2d25 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -699,6 +699,7 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux);
> void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> struct drm_connector *connector);
> void drm_dp_cec_unregister_connector(struct drm_dp_aux *aux);
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address);
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid);
> void drm_dp_cec_unset_edid(struct drm_dp_aux *aux);
> #else
> @@ -716,6 +717,11 @@ static inline void
> drm_dp_cec_unregister_connector(struct drm_dp_aux *aux)
> {
> }
>
> +static inline void drm_dp_cec_attach(struct drm_dp_aux *aux,
> + u16 source_physical_address)
> +{
> +}
> +
> static inline void drm_dp_cec_set_edid(struct drm_dp_aux *aux,
> const struct edid *edid)
> {
Re: [Intel-gfx] [PATCH 0/6] drm, cec and edid updates
On 31/08/2023 20:51, Jani Nikula wrote: > On Thu, 24 Aug 2023, Jani Nikula wrote: >> Avoid accessing the raw edid directly. Pre-parse the source physical >> address during normal EDID parsing and use that for CEC. >> >> Jani Nikula (6): >> drm/edid: add drm_edid_is_digital() >> drm/i915/display: use drm_edid_is_digital() >> drm/edid: parse source physical address >> drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid >> drm/i915/cec: switch to setting physical address directly > > Maarten, Maxime, Thomas, ack for merging patches 1, 3 and 4 via via > drm-intel? > >> media: cec: core: add note about *_from_edid() function usage in drm > > Hans, while there's no build dependency here, I think it would make > sense to merge this together with patches 3 and 4. Ack for merging via > drm-intel? That's fine, it makes sense to do that. If you need it, for this series: Acked-by: Hans Verkuil Regards, Hans > > Thanks, > Jani. > > >> >> drivers/gpu/drm/display/drm_dp_cec.c | 22 +++--- >> drivers/gpu/drm/drm_edid.c| 22 -- >> drivers/gpu/drm/i915/display/intel_crt.c | 11 --- >> drivers/gpu/drm/i915/display/intel_dp.c | 7 ++- >> drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++- >> drivers/gpu/drm/i915/display/intel_sdvo.c | 7 ++- >> drivers/media/cec/core/cec-adap.c | 4 >> drivers/media/cec/core/cec-notifier.c | 4 >> include/drm/display/drm_dp_helper.h | 6 ++ >> include/drm/drm_connector.h | 8 >> include/drm/drm_edid.h| 1 + >> 11 files changed, 73 insertions(+), 27 deletions(-) >
Re: [Intel-gfx] [PATCH 3/6] drm/edid: parse source physical address
On 24/08/2023 15:46, Jani Nikula wrote:
> CEC needs the source physical address. Parsing it is trivial with the
> existing EDID CEA DB infrastructure.
>
> Default to CEC_PHYS_ADDR_INVALID (0x) instead of 0 to cater for
> easier CEC usage.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/gpu/drm/drm_edid.c | 5 +
> include/drm/drm_connector.h | 8
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 1dbb15439468..39dd3f694544 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -29,6 +29,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -6192,6 +6193,8 @@ drm_parse_hdmi_vsdb_video(struct drm_connector
> *connector, const u8 *db)
>
> info->is_hdmi = true;
>
> + info->source_physical_address = (db[4] << 8) | db[5];
> +
> if (len >= 6)
> info->dvi_dual = db[6] & 1;
> if (len >= 7)
> @@ -6470,6 +6473,8 @@ static void drm_reset_display_info(struct drm_connector
> *connector)
> info->vics_len = 0;
>
> info->quirks = 0;
> +
> + info->source_physical_address = CEC_PHYS_ADDR_INVALID;
> }
>
> static void update_displayid_info(struct drm_connector *connector,
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index d300fde6c1a4..40a5e7acf2fa 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -816,6 +816,14 @@ struct drm_display_info {
>* @quirks: EDID based quirks. Internal to EDID parsing.
>*/
> u32 quirks;
> +
> + /**
> + * @source_physical_address: Source Physical Address from HDMI
> + * Vendor-Specific Data Block, for CEC usage.
> + *
> + * Defaults to CEC_PHYS_ADDR_INVALID (0x).
> + */
> + u16 source_physical_address;
> };
>
> int drm_display_info_set_bus_formats(struct drm_display_info *info,
[Intel-gfx] [PATCH -next] drm/i915/gvt: Use list_for_each_entry() helper
Convert list_for_each() to list_for_each_entry() so that the pos
list_head pointer and list_entry() call are no longer needed, which
can reduce a few lines of code. No functional changed.
Signed-off-by: Jinjie Ruan
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index 6834f9fe40cf..f136ce140a2b 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -340,13 +340,11 @@ static struct intel_vgpu_dmabuf_obj *
pick_dmabuf_by_info(struct intel_vgpu *vgpu,
struct intel_vgpu_fb_info *latest_info)
{
- struct list_head *pos;
struct intel_vgpu_fb_info *fb_info;
struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
struct intel_vgpu_dmabuf_obj *ret = NULL;
- list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
+ list_for_each_entry(dmabuf_obj, &vgpu->dmabuf_obj_list_head, list) {
if (!dmabuf_obj->info)
continue;
@@ -369,12 +367,10 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
static struct intel_vgpu_dmabuf_obj *
pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
{
- struct list_head *pos;
struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
struct intel_vgpu_dmabuf_obj *ret = NULL;
- list_for_each(pos, &vgpu->dmabuf_obj_list_head) {
- dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
+ list_for_each_entry(dmabuf_obj, &vgpu->dmabuf_obj_list_head, list) {
if (dmabuf_obj->dmabuf_id == id) {
ret = dmabuf_obj;
break;
--
2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/guc: fix compile issue of guc_klvs_abi.h
On 8/29/2023 5:42 AM, Michal Wajdeczko wrote: On 25.08.2023 07:50, Linyu Yuan wrote: On 8/25/2023 1:37 PM, Jani Nikula wrote: On Fri, 25 Aug 2023, Linyu Yuan wrote: GCC report GUC_KLV_0_KEY and GUC_KLV_0_LEN is not constant when do preprocessing. Please paste the actual compiler warning. CC drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o In file included from :0:0: In function ‘__guc_context_policy_add_priority.isra.47’, inlined from ‘__guc_context_set_prio.isra.48’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3332:3, inlined from ‘guc_context_set_prio’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3360:2: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in expansion of macro ‘FIELD_PREP’ FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2469:1: note: in expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ MAKE_CONTEXT_POLICY_ADD(priority, SCHEDULING_PRIORITY) ^~~ In function ‘__guc_context_policy_add_preemption_timeout.isra.51’, inlined from ‘__guc_context_set_preemption_timeout’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3005:3: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1793’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in expansion of macro ‘FIELD_PREP’ FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2468:1: note: in expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ MAKE_CONTEXT_POLICY_ADD(preemption_timeout, PREEMPTION_TIMEOUT) ^~~ In function ‘__guc_context_policy_add_priority.isra.47’, inlined from ‘__guc_add_request’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2503:2: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: n
Re: [Intel-gfx] [PATCH 6/6] media: cec: core: add note about *_from_edid() function usage in drm
On 24/08/2023 15:46, Jani Nikula wrote:
> In the drm subsystem, the source physical address is, in most cases,
> available without having to parse the EDID again. Add notes about
> preferring to use the pre-parsed address instead.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/media/cec/core/cec-adap.c | 4
> drivers/media/cec/core/cec-notifier.c | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/media/cec/core/cec-adap.c
> b/drivers/media/cec/core/cec-adap.c
> index 241b1621b197..2c627ed611ed 100644
> --- a/drivers/media/cec/core/cec-adap.c
> +++ b/drivers/media/cec/core/cec-adap.c
> @@ -1688,6 +1688,10 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16
> phys_addr, bool block)
> }
> EXPORT_SYMBOL_GPL(cec_s_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling cec_s_phys_addr() with
> + * connector->display_info.source_physical_address if possible.
> + */
I would rephrase this:
/*
* Note: in the drm subsystem, prefer calling (if possible):
*
* cec_s_phys_addr(adap, connector->display_info.source_physical_address,
false);
*/
I think it is important to indicate that the last argument should be 'false'.
> void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
> const struct edid *edid)
> {
> diff --git a/drivers/media/cec/core/cec-notifier.c
> b/drivers/media/cec/core/cec-notifier.c
> index 389dc664b211..13f043b3025b 100644
> --- a/drivers/media/cec/core/cec-notifier.c
> +++ b/drivers/media/cec/core/cec-notifier.c
> @@ -195,6 +195,10 @@ void cec_notifier_set_phys_addr(struct cec_notifier *n,
> u16 pa)
> }
> EXPORT_SYMBOL_GPL(cec_notifier_set_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling cec_notifier_set_phys_addr()
> with
> + * connector->display_info.source_physical_address if possible.
> + */
This comment is fine, there is no similar last argument here. But perhaps
it is good to use a similar format as above. Up to you.
> void cec_notifier_set_phys_addr_from_edid(struct cec_notifier *n,
> const struct edid *edid)
> {
Regards,
Hans
Re: [Intel-gfx] WQ_UNBOUND warning since recent workqueue refactoring
On 30.08.2023 20:56, Imre Deak wrote:
> On Wed, Aug 30, 2023 at 07:51:13AM -1000, Tejun Heo wrote:
> Hi,
>
>> Hello,
>>
>> (cc'ing i915 folks)
>>
>> On Wed, Aug 30, 2023 at 04:57:42PM +0200, Heiner Kallweit wrote:
>>> Recently I started to see the following warning on linux-next and presumably
>>> this may be related to the refactoring of the workqueue core code.
>>>
>>> [ 56.900223] workqueue: output_poll_execute [drm_kms_helper] hogged CPU
>>> for >1us 4 times, consider switching to WQ_UNBOUND
>>> [ 56.923226] workqueue: i915_hpd_poll_init_work [i915] hogged CPU for
>>> >1us 4 times, consider switching to WQ_UNBOUND
>>> [ 97.860430] workqueue: output_poll_execute [drm_kms_helper] hogged CPU
>>> for >1us 8 times, consider switching to WQ_UNBOUND
>>> [ 97.884453] workqueue: i915_hpd_poll_init_work [i915] hogged CPU for
>>> >1us 8 times, consider switching to WQ_UNBOUND
>>>
>>> Adding WQ_UNBOUND to these queues didn't change the behavior.
>>
>> That should have made them go away as the code path isn't active at all for
>> WQ_UNBOUND workqueues. Can you please double check?
>>
>>> Maybe relevant: I run the affected system headless.
>>
>> i915 folks, workqueue recently added debug warnings which trigger when a
>> per-cpu work item hogs the CPU for too long - 10ms in this case. This is
>> problematic because such work item can stall other per-cpu work items.
>>
>> * Is it expected for the above two work functions to occupy the CPU for over
>> 10ms repeatedly?
>
> No, this shouldn't happen.
>
> I assume it happens in
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
> after cfd48ad8c4a9 ("drm/i915: Fix HPD polling, reenabling the output poll
> work as needed")
>
> which could result in the above problem.
>
> Could you give a try to
> https://lore.kernel.org/all/20230809104307.1218058-1-imre.d...@intel.com/
>
> and if that doesn't help provide more information/logs, by opening a
> ticket at:
> https://gitlab.freedesktop.org/drm/intel/-/issues/new
>
Done
https://gitlab.freedesktop.org/drm/intel/-/issues/9245
> Thanks,
> Imre
>
>> * If so, can we make them use an unbound workqueue instead?
>>
>> Thanks.
>>
>> --
>> tejun
Re: [Intel-gfx] [PATCH] drm/i915/guc: fix compile issue of guc_klvs_abi.h
On 8/29/2023 5:42 AM, Michal Wajdeczko wrote: On 25.08.2023 07:50, Linyu Yuan wrote: On 8/25/2023 1:37 PM, Jani Nikula wrote: On Fri, 25 Aug 2023, Linyu Yuan wrote: GCC report GUC_KLV_0_KEY and GUC_KLV_0_LEN is not constant when do preprocessing. Please paste the actual compiler warning. CC drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o In file included from :0:0: In function ‘__guc_context_policy_add_priority.isra.47’, inlined from ‘__guc_context_set_prio.isra.48’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3332:3, inlined from ‘guc_context_set_prio’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3360:2: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in expansion of macro ‘FIELD_PREP’ FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2469:1: note: in expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ MAKE_CONTEXT_POLICY_ADD(priority, SCHEDULING_PRIORITY) ^~~ In function ‘__guc_context_policy_add_preemption_timeout.isra.51’, inlined from ‘__guc_context_set_preemption_timeout’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3005:3: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1793’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in expansion of macro ‘FIELD_PREP’ FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2468:1: note: in expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ MAKE_CONTEXT_POLICY_ADD(preemption_timeout, PREEMPTION_TIMEOUT) ^~~ In function ‘__guc_context_policy_add_priority.isra.47’, inlined from ‘__guc_add_request’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2503:2: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: n
Re: [Intel-gfx] [PATCH v4 16/29] KVM: x86: Reject memslot MOVE operations if KVMGT is attached
On 31/8/2023 4:50 am, Sean Christopherson wrote:
On Wed, Aug 30, 2023, Like Xu wrote:
On 2023/7/29 09:35, Sean Christopherson wrote:
Disallow moving memslots if the VM has external page-track users, i.e. if
KVMGT is being used to expose a virtual GPU to the guest, as KVMGT doesn't
correctly handle moving memory regions.
Note, this is potential ABI breakage! E.g. userspace could move regions
that aren't shadowed by KVMGT without harming the guest. However, the
only known user of KVMGT is QEMU, and QEMU doesn't move generic memory
This change breaks two kvm selftests:
- set_memory_region_test;
- memslot_perf_test;
It shoudn't. As of this patch, KVM doesn't register itself as a page-track
user,
i.e. KVMGT is the only remaining caller to kvm_page_track_register_notifier().
Unless I messed up, the only way kvm_page_track_has_external_user() can return
true is if KVMGT is attached to the VM. The selftests most definitely don't do
anything with KVMGT, so I don't see how they can fail.
Are you seeing actually failures?
$ set_memory_region_test
Testing KVM_RUN with zero added memory regions
Allowed number of memory slots: 32764
Adding slots 0..32763, each memory region with 2048K size
Testing MOVE of in-use region, 10 loops
Test Assertion Failure
lib/kvm_util.c:1163: !ret
pid=52788 tid=52788 errno=22 - Invalid argument
1 0x00405ede: vm_mem_region_move at kvm_util.c:1161
2 0x0040272a: test_move_memory_region at
set_memory_region_test.c:195
3 (inlined by) main at set_memory_region_test.c:412
4 0x7f087423ad84: ?? ??:0
5 0x004029ed: _start at ??:?
KVM_SET_USER_MEMORY_REGION failed
ret: -1 errno: 22 slot: 10 new_gpa: 0xb000
$ memslot_perf_test
Testing map performance with 1 runs, 5 seconds each
Memslot count too high for this test, decrease the cap (max is 8209)
Testing unmap performance with 1 runs, 5 seconds each
Test took 1.698964001s for slot setup + 5.020164088s all iterations
Done 43 iterations, avg 0.116748002s each
Best runtime result was 0.116748002s per iteration (with 43 iterations)
Testing unmap chunked performance with 1 runs, 5 seconds each
Test took 1.709885279s for slot setup + 5.028875257s all iterations
Done 44 iterations, avg 0.114292619s each
Best runtime result was 0.114292619s per iteration (with 44 iterations)
Testing move active area performance with 1 runs, 5 seconds each
Test Assertion Failure
lib/kvm_util.c:1163: !ret
pid=52779 tid=52779 errno=22 - Invalid argument
1 0x00406b4e: vm_mem_region_move at kvm_util.c:1161
2 0x00403686: test_memslot_move_loop at memslot_perf_test.c:624
3 0x00402c1c: test_execute at memslot_perf_test.c:828
4 (inlined by) test_loop at memslot_perf_test.c:1039
5 (inlined by) main at memslot_perf_test.c:1115
6 0x7fe01cc3ad84: ?? ??:0
7 0x00402fdd: _start at ??:?
KVM_SET_USER_MEMORY_REGION failed
ret: -1 errno: 22 slot: 32763 new_gpa: 0x3001
At one point I wondered if some of the less common kconfig's were enabled,
but the above two test failures could be easily fixed with the following diff:
diff --git a/arch/x86/kvm/mmu/page_track.h b/arch/x86/kvm/mmu/page_track.h
index 62f98c6c5af3..d4d72ed999b1 100644
--- a/arch/x86/kvm/mmu/page_track.h
+++ b/arch/x86/kvm/mmu/page_track.h
@@ -32,7 +32,7 @@ void kvm_page_track_delete_slot(struct kvm *kvm, struct
kvm_memory_slot *slot);
static inline bool kvm_page_track_has_external_user(struct kvm *kvm)
{
- return hlist_empty(&kvm->arch.track_notifier_head.track_notifier_list);
+ return !hlist_empty(&kvm->arch.track_notifier_head.track_notifier_list);
}
#else
static inline int kvm_page_track_init(struct kvm *kvm) { return 0; }
, so I guess it's pretty obvious what's going on here.
Please help confirm if the tests/doc needs to be updated,
or if the assumption needs to be further clarified.
What assumption?
regions. KVM's own support for moving memory regions was also broken for
multiple years (albeit for an edge case, but arguably moving RAM is
itself an edge case), e.g. see commit edd4fa37baa6 ("KVM: x86: Allocate
new rmap and large page tracking when moving memslot").
Reviewed-by: Yan Zhao
Tested-by: Yongwei Ma
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 3 +++
arch/x86/kvm/mmu/page_track.c | 5 +
arch/x86/kvm/x86.c| 7 +++
3 files changed, 15 insertions(+)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 8c4d216e3b2b..f744682648e7 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -75,4 +75,7 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
int bytes);
void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memor
Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()
[AMD Official Use Only - General] + Charlie -Original Message- From: Jani Nikula Sent: Tuesday, August 29, 2023 6:49 AM To: Hung, Alex ; dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org Cc: Li, Sun peng (Leo) ; David Airlie ; intel-gfx@lists.freedesktop.org; Siqueira, Rodrigo ; Wheeler, Daniel ; Wu, Hersen ; Daniel Vetter ; Chien, WenChieh (Jay) ; Deucher, Alexander ; Wentland, Harry Subject: Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update() On Wed, 23 Aug 2023, Jani Nikula wrote: > On Tue, 22 Aug 2023, Alex Hung wrote: >> On 2023-08-22 06:01, Jani Nikula wrote: >>> Over the past years I've been trying to unify the override and >>> firmware EDID handling as well as EDID property updates. It won't >>> work if drivers do their own random things. >> Let's check how to replace these references by appropriate ones or >> fork the function as reverting these patches causes regressions. > > I think the fundamental problem you have is conflating connector > forcing with EDID override. They're orthogonal. The .force callback > has no business basing the decisions on connector->edid_override. > Force is force, override is override. > > The driver isn't even supposed to know or care if the EDID originates > from the firmware loader or override EDID debugfs. drm_get_edid() will > handle that for you transparently. It'll return the EDID, and you > shouldn't look at connector->edid_blob_ptr either. Using that will > make future work in drm_edid.c harder. > > You can't fix that with minor tweaks. I think you'll be better off > starting from scratch. > > Also, connector->edid_override is debugfs. You actually can change the > behaviour. If your userspace, whatever it is, has been written to > assume connector forcing if EDID override is set, you *do* have to fix > that, and set both. Any updates on fixing this, or shall we proceed with the reverts? BR, Jani. > > BR, > Jani. > > >> >> Cheers, >> Alex >> >>> >>> BR, >>> Jani. >>> >>> >>> Cc: Alex Deucher >>> Cc: Alex Hung >>> Cc: Chao-kai Wang >>> Cc: Daniel Wheeler >>> Cc: Harry Wentland >>> Cc: Hersen Wu >>> Cc: Leo Li >>> Cc: Rodrigo Siqueira >>> Cc: Wenchieh Chien >>> Cc: David Airlie >>> Cc: Daniel Vetter >>> >>> Jani Nikula (4): >>>Revert "drm/amd/display: drop unused count variable in >>> create_eml_sink()" >>>Revert "drm/amd/display: assign edid_blob_ptr with edid from debugfs" >>>Revert "drm/amd/display: mark amdgpu_dm_connector_funcs_force static" >>>Revert "drm/amd/display: implement force function in >>> amdgpu_dm_connector_funcs" >>> >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 44 +++ >>> 1 file changed, 5 insertions(+), 39 deletions(-) >>> -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid
Hi Jani,
Sorry, I missed the v2.
On 25/08/2023 15:01, Jani Nikula wrote:
> Connectors have source physical address available in display
> info. There's no need to parse the EDID again for this. Add
> drm_dp_cec_attach() to do this.
>
> Seems like the set_edid/unset_edid naming is a bit specific now that
> there's no need to pass the EDID at all, so aim for attach/detach going
> forward.
>
> v2: Fix the embarrashing build failures
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/gpu/drm/display/drm_dp_cec.c | 23 ---
> include/drm/display/drm_dp_helper.h | 6 ++
> 2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_cec.c
> b/drivers/gpu/drm/display/drm_dp_cec.c
> index ae39dc794190..007ceb281d00 100644
> --- a/drivers/gpu/drm/display/drm_dp_cec.c
> +++ b/drivers/gpu/drm/display/drm_dp_cec.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * Unfortunately it turns out that we have a chicken-and-egg situation
> @@ -297,7 +298,7 @@ static void drm_dp_cec_unregister_work(struct work_struct
> *work)
> * were unchanged and just update the CEC physical address. Otherwise
> * unregister the old CEC adapter and create a new one.
> */
> -void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address)
> {
> struct drm_connector *connector = aux->cec.connector;
> u32 cec_caps = CEC_CAP_DEFAULTS | CEC_CAP_NEEDS_HPD |
> @@ -339,7 +340,7 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
> if (aux->cec.adap->capabilities == cec_caps &&
> aux->cec.adap->available_log_addrs == num_las) {
> /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(aux->cec.adap, source_physical_address,
> false);
> goto unlock;
> }
> /*
> @@ -370,11 +371,27 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>* from drm_dp_cec_register_connector() edid == NULL, so in
>* that case the phys addr is just invalidated.
>*/
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + cec_s_phys_addr(aux->cec.adap, source_physical_address, false);
> }
> unlock:
> mutex_unlock(&aux->cec.lock);
> }
> +EXPORT_SYMBOL(drm_dp_cec_attach);
> +
> +/*
> + * Note: Prefer calling drm_dp_cec_attach() with
> + * connector->display_info.source_physical_address if possible.
> + */
> +void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid)
> +{
> + u16 pa = CEC_PHYS_ADDR_INVALID;
> +
> + if (edid && edid->extensions)
> + pa = cec_get_edid_phys_addr((const u8 *)edid,
> + EDID_LENGTH * (edid->extensions +
> 1), NULL);
> +
> + drm_dp_cec_attach(aux, pa);
> +}
> EXPORT_SYMBOL(drm_dp_cec_set_edid);
>
> /*
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 86f24a759268..3369104e2d25 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -699,6 +699,7 @@ void drm_dp_cec_irq(struct drm_dp_aux *aux);
> void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> struct drm_connector *connector);
> void drm_dp_cec_unregister_connector(struct drm_dp_aux *aux);
> +void drm_dp_cec_attach(struct drm_dp_aux *aux, u16 source_physical_address);
> void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const struct edid *edid);
> void drm_dp_cec_unset_edid(struct drm_dp_aux *aux);
> #else
> @@ -716,6 +717,11 @@ static inline void
> drm_dp_cec_unregister_connector(struct drm_dp_aux *aux)
> {
> }
>
> +static inline void drm_dp_cec_attach(struct drm_dp_aux *aux,
> + u16 source_physical_address)
> +{
> +}
> +
> static inline void drm_dp_cec_set_edid(struct drm_dp_aux *aux,
> const struct edid *edid)
> {
Re: [Intel-gfx] [PATCH v2] media: cec: core: add note about *_from_edid() function usage in drm
On 31/08/2023 12:51, Jani Nikula wrote:
> In the drm subsystem, the source physical address is, in most cases,
> available without having to parse the EDID again. Add notes about
> preferring to use the pre-parsed address instead.
>
> Cc: Hans Verkuil
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Jani Nikula
Reviewed-by: Hans Verkuil
Thanks!
Hans
>
> ---
>
> v2: rephrase comments, in particular indicate cec_s_phys_addr() should
> be false (Hans)
> ---
> drivers/media/cec/core/cec-adap.c | 5 +
> drivers/media/cec/core/cec-notifier.c | 5 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/media/cec/core/cec-adap.c
> b/drivers/media/cec/core/cec-adap.c
> index 241b1621b197..1109af525c35 100644
> --- a/drivers/media/cec/core/cec-adap.c
> +++ b/drivers/media/cec/core/cec-adap.c
> @@ -1688,6 +1688,11 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16
> phys_addr, bool block)
> }
> EXPORT_SYMBOL_GPL(cec_s_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling (if possible):
> + *
> + * cec_s_phys_addr(adap, connector->display_info.source_physical_address,
> false);
> + */
> void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
> const struct edid *edid)
> {
> diff --git a/drivers/media/cec/core/cec-notifier.c
> b/drivers/media/cec/core/cec-notifier.c
> index 389dc664b211..d600be0f7b67 100644
> --- a/drivers/media/cec/core/cec-notifier.c
> +++ b/drivers/media/cec/core/cec-notifier.c
> @@ -195,6 +195,11 @@ void cec_notifier_set_phys_addr(struct cec_notifier *n,
> u16 pa)
> }
> EXPORT_SYMBOL_GPL(cec_notifier_set_phys_addr);
>
> +/*
> + * Note: In the drm subsystem, prefer calling (if possible):
> + *
> + * cec_notifier_set_phys_addr(n,
> connector->display_info.source_physical_address);
> + */
> void cec_notifier_set_phys_addr_from_edid(struct cec_notifier *n,
> const struct edid *edid)
> {
Re: [Intel-gfx] [PATCH 5/6] drm/i915/cec: switch to setting physical address directly
On 24/08/2023 15:46, Jani Nikula wrote: > Avoid parsing the EDID again for source physical address. Also gets rids > of a few remaining raw EDID usages. > > Cc: Hans Verkuil > Cc: linux-me...@vger.kernel.org > Signed-off-by: Jani Nikula Reviewed-by: Hans Verkuil Regards, Hans > --- > drivers/gpu/drm/i915/display/intel_dp.c | 7 ++- > drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++--- > 2 files changed, 4 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index 7067ee3a4bd3..c4b8e0e74c15 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -5198,7 +5198,6 @@ intel_dp_set_edid(struct intel_dp *intel_dp) > struct drm_i915_private *i915 = dp_to_i915(intel_dp); > struct intel_connector *connector = intel_dp->attached_connector; > const struct drm_edid *drm_edid; > - const struct edid *edid; > bool vrr_capable; > > intel_dp_unset_edid(intel_dp); > @@ -5216,10 +5215,8 @@ intel_dp_set_edid(struct intel_dp *intel_dp) > intel_dp_update_dfp(intel_dp, drm_edid); > intel_dp_update_420(intel_dp); > > - /* FIXME: Get rid of drm_edid_raw() */ > - edid = drm_edid_raw(drm_edid); > - > - drm_dp_cec_set_edid(&intel_dp->aux, edid); > + drm_dp_cec_attach(&intel_dp->aux, > + connector->base.display_info.source_physical_address); > } > > static void > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c > b/drivers/gpu/drm/i915/display/intel_hdmi.c > index aa9915098dda..5d6255ee8b54 100644 > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > @@ -2482,9 +2482,8 @@ intel_hdmi_set_edid(struct drm_connector *connector) > > intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref); > > - /* FIXME: Get rid of drm_edid_raw() */ > - cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, > - drm_edid_raw(drm_edid)); > + cec_notifier_set_phys_addr(intel_hdmi->cec_notifier, > + > connector->display_info.source_physical_address); > > return connected; > }
Re: [Intel-gfx] [PATCH v4 16/29] KVM: x86: Reject memslot MOVE operations if KVMGT is attached
On 2023/7/29 09:35, Sean Christopherson wrote:
Disallow moving memslots if the VM has external page-track users, i.e. if
KVMGT is being used to expose a virtual GPU to the guest, as KVMGT doesn't
correctly handle moving memory regions.
Note, this is potential ABI breakage! E.g. userspace could move regions
that aren't shadowed by KVMGT without harming the guest. However, the
only known user of KVMGT is QEMU, and QEMU doesn't move generic memory
This change breaks two kvm selftests:
- set_memory_region_test;
- memslot_perf_test;
Please help confirm if the tests/doc needs to be updated,
or if the assumption needs to be further clarified.
regions. KVM's own support for moving memory regions was also broken for
multiple years (albeit for an edge case, but arguably moving RAM is
itself an edge case), e.g. see commit edd4fa37baa6 ("KVM: x86: Allocate
new rmap and large page tracking when moving memslot").
Reviewed-by: Yan Zhao
Tested-by: Yongwei Ma
Signed-off-by: Sean Christopherson
---
arch/x86/include/asm/kvm_page_track.h | 3 +++
arch/x86/kvm/mmu/page_track.c | 5 +
arch/x86/kvm/x86.c| 7 +++
3 files changed, 15 insertions(+)
diff --git a/arch/x86/include/asm/kvm_page_track.h
b/arch/x86/include/asm/kvm_page_track.h
index 8c4d216e3b2b..f744682648e7 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -75,4 +75,7 @@ kvm_page_track_unregister_notifier(struct kvm *kvm,
void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
int bytes);
void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot);
+
+bool kvm_page_track_has_external_user(struct kvm *kvm);
+
#endif
diff --git a/arch/x86/kvm/mmu/page_track.c b/arch/x86/kvm/mmu/page_track.c
index 891e5cc52b45..e6de9638e560 100644
--- a/arch/x86/kvm/mmu/page_track.c
+++ b/arch/x86/kvm/mmu/page_track.c
@@ -303,3 +303,8 @@ void kvm_page_track_flush_slot(struct kvm *kvm, struct
kvm_memory_slot *slot)
n->track_flush_slot(kvm, slot, n);
srcu_read_unlock(&head->track_srcu, idx);
}
+
+bool kvm_page_track_has_external_user(struct kvm *kvm)
+{
+ return hlist_empty(&kvm->arch.track_notifier_head.track_notifier_list);
+}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 059571d5abed..4394bb49051f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -12606,6 +12606,13 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *new,
enum kvm_mr_change change)
{
+ /*
+* KVM doesn't support moving memslots when there are external page
+* trackers attached to the VM, i.e. if KVMGT is in use.
+*/
+ if (change == KVM_MR_MOVE && kvm_page_track_has_external_user(kvm))
+ return -EINVAL;
+
if (change == KVM_MR_CREATE || change == KVM_MR_MOVE) {
if ((new->base_gfn + new->npages - 1) > kvm_mmu_max_gfn())
return -EINVAL;
Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()
[AMD Official Use Only - General] + Charlie Wang -Original Message- From: Alex Deucher Sent: Tuesday, August 29, 2023 11:44 AM To: Jani Nikula Cc: Hung, Alex ; dri-de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Li, Sun peng (Leo) ; intel-gfx@lists.freedesktop.org; Siqueira, Rodrigo ; Wheeler, Daniel ; Wu, Hersen ; Chien, WenChieh (Jay) ; Deucher, Alexander Subject: Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update() On Tue, Aug 29, 2023 at 6:48 AM Jani Nikula wrote: > > On Wed, 23 Aug 2023, Jani Nikula wrote: > > On Tue, 22 Aug 2023, Alex Hung wrote: > >> On 2023-08-22 06:01, Jani Nikula wrote: > >>> Over the past years I've been trying to unify the override and > >>> firmware EDID handling as well as EDID property updates. It won't > >>> work if drivers do their own random things. > >> Let's check how to replace these references by appropriate ones or > >> fork the function as reverting these patches causes regressions. > > > > I think the fundamental problem you have is conflating connector > > forcing with EDID override. They're orthogonal. The .force callback > > has no business basing the decisions on connector->edid_override. > > Force is force, override is override. > > > > The driver isn't even supposed to know or care if the EDID > > originates from the firmware loader or override EDID debugfs. > > drm_get_edid() will handle that for you transparently. It'll return > > the EDID, and you shouldn't look at connector->edid_blob_ptr either. > > Using that will make future work in drm_edid.c harder. > > > > You can't fix that with minor tweaks. I think you'll be better off > > starting from scratch. > > > > Also, connector->edid_override is debugfs. You actually can change > > the behaviour. If your userspace, whatever it is, has been written > > to assume connector forcing if EDID override is set, you *do* have > > to fix that, and set both. > > Any updates on fixing this, or shall we proceed with the reverts? What is the goal of the reverts? I don't disagree that we may be using the interfaces wrong, but reverting them will regess functionality in the driver. Alex
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave and Daniel, Only a single patch towards -rc1. I noticed that you already sent this week's PR, but sending this just in case. Otherwise I believe it could wait for the regular fixes cycle. Here goes drm-intel-next-fixes-2023-08-31: - Mark requests for GuC virtual engines to avoid use-after-free (Andrzej). Thanks, Rodrigo. The following changes since commit 3698a75f5a98d0a6599e2878ab25d30a82dd836a: Merge tag 'drm-intel-next-fixes-2023-08-24' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2023-08-25 12:55:55 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-08-31 for you to fetch changes up to 5eefc5307c983b59344a4cb89009819f580c84fa: drm/i915: mark requests for GuC virtual engines to avoid use-after-free (2023-08-30 11:32:48 -0400) - Mark requests for GuC virtual engines to avoid use-after-free (Andrzej). Andrzej Hajda (1): drm/i915: mark requests for GuC virtual engines to avoid use-after-free drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 +++ drivers/gpu/drm/i915/i915_request.c | 7 ++- 3 files changed, 6 insertions(+), 5 deletions(-)
[Intel-gfx] [PATCH] drm/i915/guc: Update GUC_KLV_0_KEY definition
While building ARCH=x86 with GCC 7.5.0 we get compilation errors: CC drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o In file included from :0:0: In function ‘__guc_context_policy_add_priority.isra.47’, inlined from ‘__guc_context_set_prio.isra.48’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3332:3, inlined from ‘guc_context_set_prio’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3360:2: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix();\ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in expansion of macro ‘FIELD_PREP’ FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~ This is due to our GUC_KLV_0_KEY definition that uses signed mask in shift operator, which may lead to undefined behavior on 32-bit system. Use unsigned mask to enforce expected integer promotion. Reported-by: Linyu Yuan Signed-off-by: Michal Wajdeczko Cc: Linyu Yuan Cc: Jani Nikula --- drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h index 58012edd4eb0..8e821aefb164 100644 --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h @@ -29,7 +29,7 @@ */ #define GUC_KLV_LEN_MIN1u -#define GUC_KLV_0_KEY (0x << 16) +#define GUC_KLV_0_KEY (0xu << 16) #define GUC_KLV_0_LEN (0x << 0) #define GUC_KLV_n_VALUE(0x << 0) -- 2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/cx0: Check and increase msgbus timeout threshold (rev3)
== Series Details == Series: drm/i915/cx0: Check and increase msgbus timeout threshold (rev3) URL : https://patchwork.freedesktop.org/series/122982/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13579_full -> Patchwork_122982v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122982v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122982v3_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122982v3_full: ### IGT changes ### Possible regressions * igt@perf_pmu@busy-idle@rcs0: - shard-rkl: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-rkl-4/igt@perf_pmu@busy-i...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-rkl-1/igt@perf_pmu@busy-i...@rcs0.html Known issues Here are the changes found in Patchwork_122982v3_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][3] ([i915#8411]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-dg2-8/igt@api_intel...@object-reloc-keep-cache.html * igt@device_reset@unbind-cold-reset-rebind: - shard-dg2: NOTRUN -> [SKIP][4] ([i915#7701]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-dg2-1/igt@device_re...@unbind-cold-reset-rebind.html * igt@drm_fdinfo@busy-idle@bcs0: - shard-mtlp: NOTRUN -> [SKIP][5] ([i915#8414]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-mtlp-1/igt@drm_fdinfo@busy-i...@bcs0.html * igt@drm_fdinfo@busy@ccs0: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#8414]) +9 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-dg2-1/igt@drm_fdinfo@b...@ccs0.html * igt@feature_discovery@display-3x: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#1839]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-dg2-8/igt@feature_discov...@display-3x.html * igt@gem_ctx_persistence@hang: - shard-dg2: NOTRUN -> [SKIP][8] ([i915#8555]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-dg2-8/igt@gem_ctx_persiste...@hang.html * igt@gem_ctx_persistence@legacy-engines-cleanup@vebox: - shard-mtlp: [PASS][9] -> [ABORT][10] ([i915#8311]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-mtlp-5/igt@gem_ctx_persistence@legacy-engines-clea...@vebox.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-mtlp-3/igt@gem_ctx_persistence@legacy-engines-clea...@vebox.html * igt@gem_eio@hibernate: - shard-dg1: [PASS][11] -> [ABORT][12] ([i915#7975] / [i915#8213]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-dg1-19/igt@gem_...@hibernate.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-dg1-14/igt@gem_...@hibernate.html * igt@gem_eio@reset-stress: - shard-dg1: [PASS][13] -> [FAIL][14] ([i915#5784]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-dg1-17/igt@gem_...@reset-stress.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-dg1-19/igt@gem_...@reset-stress.html * igt@gem_exec_balancer@invalid-bonds: - shard-mtlp: NOTRUN -> [SKIP][15] ([i915#4036]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-mtlp-1/igt@gem_exec_balan...@invalid-bonds.html * igt@gem_exec_fair@basic-deadline: - shard-rkl: [PASS][16] -> [FAIL][17] ([i915#2846]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-rkl-4/igt@gem_exec_f...@basic-deadline.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-rkl-4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/shard-glk9/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-rkl: [PASS][20] -> [FAIL][21] ([i915#2842]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-rkl-7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
On 8/31/2023 7:40 PM, Matt Roper wrote:
On Thu, Aug 31, 2023 at 08:09:54AM -0700, Jonathan Cavitt wrote:
From: Nirmoy Das
Apply WABB blit for Wa_16018031267 / Wa_16018063123.
Additionally, update the lrc selftest to exercise the new
WABB changes.
Co-developed-by: Nirmoy Das
Drive-by comment: since Nirmoy is already listed as the author of this
patch, we probably don't need a c-d-b here. However we do need his
s-o-b line.
This needed to be amended with git commit --amend --author=Jonathan
Cavitt --no-edit
I wanted Jonathan to take over the authorship as Jonathan is working it.
Regards,
Nirmoy
Matt
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +
drivers/gpu/drm/i915/gt/intel_gt.h | 4 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 107 +++-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 65
5 files changed, 160 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 6b9d9f8376692..2e06bea73297a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
#define CCID_EXTENDED_STATE_RESTORE BIT(2)
#define CCID_EXTENDED_STATE_SAVEBIT(3)
#define RING_BB_PER_CTX_PTR(base) _MMIO((base) + 0x1c0) /* gen8+
*/
+#define PER_CTX_BB_FORCE BIT(2)
+#define PER_CTX_BB_VALID BIT(0)
+
#define RING_INDIRECT_CTX(base) _MMIO((base) + 0x1c4)
/* gen8+ */
#define RING_INDIRECT_CTX_OFFSET(base)_MMIO((base) + 0x1c8)
/* gen8+ */
#define ECOSKPD(base) _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 239848bcb2a42..40cc0005dd735 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -83,6 +83,10 @@ struct drm_printer;
##__VA_ARGS__); \
} while (0)
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+ IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+ engine->class == COPY_ENGINE_CLASS)
+
static inline bool gt_is_root(struct intel_gt *gt)
{
return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index def7dd0eb6f19..4917633f299dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -307,6 +307,8 @@ enum intel_gt_scratch_field {
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
+
+ INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT = 384,
};
#define intel_gt_support_legacy_fencing(gt) ((gt)->ggtt->num_fences > 0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 967fe4d77a874..1e0c1438f2cd1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct
intel_engine_cs *engine)
return 0;
}
+static void
+lrc_setup_bb_per_ctx(u32 *regs,
+const struct intel_engine_cs *engine,
+u32 ctx_bb_ggtt_addr)
+{
+ GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+ regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+ ctx_bb_ggtt_addr |
+ PER_CTX_BB_FORCE |
+ PER_CTX_BB_VALID;
+}
+
static void
lrc_setup_indirect_ctx(u32 *regs,
const struct intel_engine_cs *engine,
@@ -997,7 +1009,13 @@ static u32 context_wa_bb_offset(const struct
intel_context *ce)
return PAGE_SIZE * ce->wa_bb_page;
}
-static u32 *context_indirect_bb(const struct intel_context *ce)
+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB. When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
{
void *ptr;
@@ -1006,6 +1024,7 @@ static u32 *context_indirect_bb(const struct intel_context *ce)
ptr = ce->lrc_reg_state;
ptr -= LRC_STATE_OFFSET; /* back to start of context image */
ptr += context_wa_bb_offset(ce);
+ ptr += per_ctx ? PAGE_SIZE : 0;
return ptr;
}
@@ -1082,7 +1101,8 @@ __lrc_alloc_state(struct intel_context *ce, struct
intel_engine_cs *engine)
if (GRAPHICS_VER(engine->i915) >= 12) {
ce->wa_bb_page = context_size / PAGE_SIZE;
- context_size += PAGE_SIZE;
+ /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+ context_size += PAGE_SIZE * 2;
}
if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
Re: [Intel-gfx] [PATCH 0/6] drm, cec and edid updates
On Thu, 24 Aug 2023, Jani Nikula wrote: > Avoid accessing the raw edid directly. Pre-parse the source physical > address during normal EDID parsing and use that for CEC. > > Jani Nikula (6): > drm/edid: add drm_edid_is_digital() > drm/i915/display: use drm_edid_is_digital() > drm/edid: parse source physical address > drm/cec: add drm_dp_cec_attach() as the non-edid version of set edid > drm/i915/cec: switch to setting physical address directly Maarten, Maxime, Thomas, ack for merging patches 1, 3 and 4 via via drm-intel? > media: cec: core: add note about *_from_edid() function usage in drm Hans, while there's no build dependency here, I think it would make sense to merge this together with patches 3 and 4. Ack for merging via drm-intel? Thanks, Jani. > > drivers/gpu/drm/display/drm_dp_cec.c | 22 +++--- > drivers/gpu/drm/drm_edid.c| 22 -- > drivers/gpu/drm/i915/display/intel_crt.c | 11 --- > drivers/gpu/drm/i915/display/intel_dp.c | 7 ++- > drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++- > drivers/gpu/drm/i915/display/intel_sdvo.c | 7 ++- > drivers/media/cec/core/cec-adap.c | 4 > drivers/media/cec/core/cec-notifier.c | 4 > include/drm/display/drm_dp_helper.h | 6 ++ > include/drm/drm_connector.h | 8 > include/drm/drm_edid.h| 1 + > 11 files changed, 73 insertions(+), 27 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm, cec and edid updates (rev3)
== Series Details == Series: drm, cec and edid updates (rev3) URL : https://patchwork.freedesktop.org/series/122841/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13579_full -> Patchwork_122841v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122841v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122841v3_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122841v3_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@pi@vcs1: - shard-tglu: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-tglu-8/igt@gem_exec_capture@p...@vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-tglu-8/igt@gem_exec_capture@p...@vcs1.html * igt@kms_plane_lowres@tiling-y@pipe-a-hdmi-a-1: - shard-rkl: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-rkl-7/igt@kms_plane_lowres@tilin...@pipe-a-hdmi-a-1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-rkl-7/igt@kms_plane_lowres@tilin...@pipe-a-hdmi-a-1.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-dg2: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-dg2-3/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-dg2-5/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html Known issues Here are the changes found in Patchwork_122841v3_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#8411]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-dg2-8/igt@api_intel...@object-reloc-keep-cache.html * igt@device_reset@unbind-cold-reset-rebind: - shard-dg2: NOTRUN -> [SKIP][8] ([i915#7701]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-dg2-3/igt@device_re...@unbind-cold-reset-rebind.html * igt@drm_fdinfo@busy-idle@bcs0: - shard-mtlp: NOTRUN -> [SKIP][9] ([i915#8414]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-mtlp-2/igt@drm_fdinfo@busy-i...@bcs0.html * igt@drm_fdinfo@busy@ccs0: - shard-dg2: NOTRUN -> [SKIP][10] ([i915#8414]) +9 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-dg2-3/igt@drm_fdinfo@b...@ccs0.html * igt@feature_discovery@display-3x: - shard-dg2: NOTRUN -> [SKIP][11] ([i915#1839]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-dg2-8/igt@feature_discov...@display-3x.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglu: [PASS][12] -> [FAIL][13] ([i915#6268]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-tglu-6/igt@gem_ctx_e...@basic-nohangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-tglu-6/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_persistence@hang: - shard-dg2: NOTRUN -> [SKIP][14] ([i915#8555]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-dg2-8/igt@gem_ctx_persiste...@hang.html * igt@gem_eio@reset-stress: - shard-dg1: [PASS][15] -> [FAIL][16] ([i915#5784]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-dg1-17/igt@gem_...@reset-stress.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-dg1-17/igt@gem_...@reset-stress.html * igt@gem_exec_balancer@invalid-bonds: - shard-mtlp: NOTRUN -> [SKIP][17] ([i915#4036]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-mtlp-2/igt@gem_exec_balan...@invalid-bonds.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#2842]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/shard-glk7/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-rkl: [PASS][20] -> [FAIL][21] ([i915#2842]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/shard-rkl-2/igt@gem_exec_fair@basic-p...@vcs0.html [21]: https://i
Re: [Intel-gfx] [PATCH 1/1] drm/i915/gt: Wait longer for tasks in migrate selftest
Hi Jonathan, On Mon, Aug 28, 2023 at 12:28:52PM -0700, Jonathan Cavitt wrote: > The thread_global_copy subtest of the live migrate selftest creates a > large number of threads and waits 10ms for them all to start. This is > not enough time to wait for the threaded tasks to start, as some may > need to wait for additional ring space to be granted. Threads that do > so are at risk of getting stopped (signaled) in the middle of waiting > for additional space, which can result in ERESTARTSYS getting reported > erroneously by i915_request_wait. > > Instead of waiting a flat 10ms for the threads to start, wait 10ms per > thread. This grants enough of a buffer for each thread to wait for > additional ring space when needed. > > Signed-off-by: Jonathan Cavitt Applied to drm-intel-gt-next. Thanks, Andi
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
On Thu, Aug 31, 2023 at 08:09:54AM -0700, Jonathan Cavitt wrote:
> From: Nirmoy Das
>
> Apply WABB blit for Wa_16018031267 / Wa_16018063123.
> Additionally, update the lrc selftest to exercise the new
> WABB changes.
>
> Co-developed-by: Nirmoy Das
Drive-by comment: since Nirmoy is already listed as the author of this
patch, we probably don't need a c-d-b here. However we do need his
s-o-b line.
Matt
> Signed-off-by: Jonathan Cavitt
> ---
> drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +
> drivers/gpu/drm/i915/gt/intel_gt.h | 4 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 107 +++-
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 65
> 5 files changed, 160 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> index 6b9d9f8376692..2e06bea73297a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> @@ -118,6 +118,9 @@
> #define CCID_EXTENDED_STATE_RESTOREBIT(2)
> #define CCID_EXTENDED_STATE_SAVE BIT(3)
> #define RING_BB_PER_CTX_PTR(base)_MMIO((base) + 0x1c0) /* gen8+
> */
> +#define PER_CTX_BB_FORCE BIT(2)
> +#define PER_CTX_BB_VALID BIT(0)
> +
> #define RING_INDIRECT_CTX(base) _MMIO((base) + 0x1c4)
> /* gen8+ */
> #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8)
> /* gen8+ */
> #define ECOSKPD(base)_MMIO((base) + 0x1d0)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 239848bcb2a42..40cc0005dd735 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -83,6 +83,10 @@ struct drm_printer;
> ##__VA_ARGS__); \
> } while (0)
>
> +#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
> + IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
> + engine->class == COPY_ENGINE_CLASS)
> +
> static inline bool gt_is_root(struct intel_gt *gt)
> {
> return !gt->info.id;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index def7dd0eb6f19..4917633f299dd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -307,6 +307,8 @@ enum intel_gt_scratch_field {
>
> /* 8 bytes */
> INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
> +
> + INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT = 384,
> };
>
> #define intel_gt_support_legacy_fencing(gt) ((gt)->ggtt->num_fences > 0)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 967fe4d77a874..1e0c1438f2cd1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct
> intel_engine_cs *engine)
> return 0;
> }
>
> +static void
> +lrc_setup_bb_per_ctx(u32 *regs,
> + const struct intel_engine_cs *engine,
> + u32 ctx_bb_ggtt_addr)
> +{
> + GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
> + regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
> + ctx_bb_ggtt_addr |
> + PER_CTX_BB_FORCE |
> + PER_CTX_BB_VALID;
> +}
> +
> static void
> lrc_setup_indirect_ctx(u32 *regs,
> const struct intel_engine_cs *engine,
> @@ -997,7 +1009,13 @@ static u32 context_wa_bb_offset(const struct
> intel_context *ce)
> return PAGE_SIZE * ce->wa_bb_page;
> }
>
> -static u32 *context_indirect_bb(const struct intel_context *ce)
> +/*
> + * per_ctx below determines which WABB section is used.
> + * When true, the function returns the location of the
> + * PER_CTX_BB. When false, the function returns the
> + * location of the INDIRECT_CTX.
> + */
> +static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
> {
> void *ptr;
>
> @@ -1006,6 +1024,7 @@ static u32 *context_indirect_bb(const struct
> intel_context *ce)
> ptr = ce->lrc_reg_state;
> ptr -= LRC_STATE_OFFSET; /* back to start of context image */
> ptr += context_wa_bb_offset(ce);
> + ptr += per_ctx ? PAGE_SIZE : 0;
>
> return ptr;
> }
> @@ -1082,7 +1101,8 @@ __lrc_alloc_state(struct intel_context *ce, struct
> intel_engine_cs *engine)
>
> if (GRAPHICS_VER(engine->i915) >= 12) {
> ce->wa_bb_page = context_size / PAGE_SIZE;
> - context_size += PAGE_SIZE;
> + /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
> + context_size += PAGE_SIZE * 2;
> }
>
> if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
> @@ -1370,12 +1390,92 @@ gen12_emit_indirect_ctx_xcs
Re: [Intel-gfx] [PATCH 2/6] drm/i915/display: use drm_edid_is_digital()
On Thu, Aug 24, 2023 at 04:46:03PM +0300, Jani Nikula wrote:
> Reduce the use of struct edid and drm_edid_raw().
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 11 ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 9 -
> drivers/gpu/drm/i915/display/intel_sdvo.c | 7 ++-
> 3 files changed, 10 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index f66340b4caf0..310670bb6c25 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -657,21 +657,18 @@ static bool intel_crt_detect_ddc(struct drm_connector
> *connector)
> drm_edid = intel_crt_get_edid(connector, i2c);
>
> if (drm_edid) {
> - const struct edid *edid = drm_edid_raw(drm_edid);
> - bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL;
> -
> /*
>* This may be a DVI-I connector with a shared DDC
>* link between analog and digital outputs, so we
>* have to check the EDID input spec of the attached device.
>*/
> - if (!is_digital) {
> + if (drm_edid_is_digital(drm_edid)) {
> drm_dbg_kms(&dev_priv->drm,
> - "CRT detected via DDC:0x50 [EDID]\n");
> - ret = true;
> + "CRT not detected via DDC:0x50 [EDID
> reports a digital panel]\n");
> } else {
> drm_dbg_kms(&dev_priv->drm,
> - "CRT not detected via DDC:0x50 [EDID
> reports a digital panel]\n");
> + "CRT detected via DDC:0x50 [EDID]\n");
> + ret = true;
Inverting the check made the diff a bit confusing, but looks
correct in the end.
Reviewed-by: Ville Syrjälä
> }
> } else {
> drm_dbg_kms(&dev_priv->drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 9442bf43550e..aa9915098dda 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2452,7 +2452,6 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> struct intel_hdmi *intel_hdmi =
> intel_attached_hdmi(to_intel_connector(connector));
> intel_wakeref_t wakeref;
> const struct drm_edid *drm_edid;
> - const struct edid *edid;
> bool connected = false;
> struct i2c_adapter *i2c;
>
> @@ -2475,9 +2474,7 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>
> to_intel_connector(connector)->detect_edid = drm_edid;
>
> - /* FIXME: Get rid of drm_edid_raw() */
> - edid = drm_edid_raw(drm_edid);
> - if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
> + if (drm_edid_is_digital(drm_edid)) {
> intel_hdmi_dp_dual_mode_detect(connector);
>
> connected = true;
> @@ -2485,7 +2482,9 @@ intel_hdmi_set_edid(struct drm_connector *connector)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref);
>
> - cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, edid);
> + /* FIXME: Get rid of drm_edid_raw() */
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier,
> + drm_edid_raw(drm_edid));
>
> return connected;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 7d25a64698e2..917771e19e38 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2094,10 +2094,8 @@ intel_sdvo_tmds_sink_detect(struct drm_connector
> *connector)
>
> status = connector_status_unknown;
> if (drm_edid) {
> - const struct edid *edid = drm_edid_raw(drm_edid);
> -
> /* DDC bus is shared, match EDID to connector type */
> - if (edid && edid->input & DRM_EDID_INPUT_DIGITAL)
> + if (drm_edid_is_digital(drm_edid))
> status = connector_status_connected;
> else
> status = connector_status_disconnected;
> @@ -2111,8 +2109,7 @@ static bool
> intel_sdvo_connector_matches_edid(struct intel_sdvo_connector *sdvo,
> const struct drm_edid *drm_edid)
> {
> - const struct edid *edid = drm_edid_raw(drm_edid);
> - bool monitor_is_digital = !!(edid->input & DRM_EDID_INPUT_DIGITAL);
> + bool monitor_is_digital = drm_edid_is_digital(drm_edid);
> bool connector_is_digital = !!IS_DIGITAL(sdvo);
>
> DRM_DEBUG_KMS("connector_is_digital? %d, monitor_is_digital? %d\n",
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/6] drm/edid: add drm_edid_is_digital()
On Thu, Aug 24, 2023 at 04:46:02PM +0300, Jani Nikula wrote:
> Checking edid->input & DRM_EDID_INPUT_DIGITAL is common enough to
> deserve a helper that also lets us abstract the raw EDID a bit better.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 17 +++--
> include/drm/drm_edid.h | 1 +
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 340da8257b51..1dbb15439468 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3110,7 +3110,7 @@ drm_monitor_supports_rb(const struct drm_edid *drm_edid)
> return ret;
> }
>
> - return ((drm_edid->edid->input & DRM_EDID_INPUT_DIGITAL) != 0);
> + return drm_edid_is_digital(drm_edid);
> }
>
> static void
> @@ -6519,7 +6519,7 @@ static void update_display_info(struct drm_connector
> *connector,
> if (edid->revision < 3)
> goto out;
>
> - if (!(edid->input & DRM_EDID_INPUT_DIGITAL))
> + if (!drm_edid_is_digital(drm_edid))
> goto out;
>
> info->color_formats |= DRM_COLOR_FORMAT_RGB444;
> @@ -7335,3 +7335,16 @@ static void _drm_update_tile_info(struct drm_connector
> *connector,
> connector->tile_group = NULL;
> }
> }
> +
> +/**
> + * drm_edid_is_digital - is digital?
> + * @drm_edid: The EDID
> + *
> + * Return true if input is digital.
> + */
> +bool drm_edid_is_digital(const struct drm_edid *drm_edid)
> +{
> + return drm_edid && drm_edid->edid &&
> + drm_edid->edid->input & DRM_EDID_INPUT_DIGITAL;
> +}
> +EXPORT_SYMBOL(drm_edid_is_digital);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 48e93f909ef6..882d2638708e 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -612,6 +612,7 @@ const struct drm_edid *drm_edid_read_switcheroo(struct
> drm_connector *connector,
> int drm_edid_connector_update(struct drm_connector *connector,
> const struct drm_edid *edid);
> int drm_edid_connector_add_modes(struct drm_connector *connector);
> +bool drm_edid_is_digital(const struct drm_edid *drm_edid);
>
> const u8 *drm_find_edid_extension(const struct drm_edid *drm_edid,
> int ext_id, int *ext_index);
> --
> 2.39.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH] drm/i915: Add Wa_14015150844
On Thu, Aug 31, 2023 at 09:29:25PM +0530, Shekhar Chauhan wrote:
> Disables Atomic-chaining of Typed Writes.
>
> BSpec: 54040
> Signed-off-by: Shekhar Chauhan
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 0e4c638fcbbf..82b533aa0c03 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1218,6 +1218,8 @@
>
> #define XEHP_HDC_CHICKEN0MCR_REG(0xe5f0)
> #define LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK REG_GENMASK(13,
> 11)
> +#define ATOMIC_CHAINING_TYPED_WRITES REG_BIT(3)
Since a value of "1" for this bit disables something in the hardware,
we'd often put "DIS" or "DISABLE" in the name somewhere. E.g., the
name we used for this bit in the Xe driver is
"DIS_ATOMIC_CHAINING_TYPED_WRITES" which helps clarify the semantics a
bit.
> +
> #define ICL_HDC_MODE MCR_REG(0xe5f4)
>
> #define EU_PERF_CNTL2PERF_REG(0xe658)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 864d41bcf6bb..d853f228fabd 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2327,6 +2327,14 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>
> LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK);
> }
>
> + if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
> + IS_DG2(i915)) {
> + /* Wa_14015150844 */
> + wa_mcr_add(wal, XEHP_HDC_CHICKEN0, 0,
> +_MASKED_BIT_DISABLE(ATOMIC_CHAINING_TYPED_WRITES),
_MASKED_BIT_DISABLE will disable the bit (i.e., set it to 0), which will
enable the behavior in hardware (and a value of 0 is also the hardware
default in this case). Since the workaround description is asking us to
set the chicken bit (thus disabling the hardware behavior), I think we
want _MASKED_BIT_ENABLE here.
It's always a bit confusing when enabling a bit disables a behavior and
vice versa, but it's a pretty common pattern for hardware chicken bits
like these.
Matt
> +0, true);
> + }
> +
> if (IS_DG2_G11(i915) || IS_DG2_G10(i915)) {
> /* Wa_22014600077:dg2 */
> wa_mcr_add(wal, GEN10_CACHE_MODE_SS, 0,
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH v5 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP
On Thu, Aug 31, 2023 at 07:16:55PM +0300, Jani Nikula wrote:
> On Mon, 21 Aug 2023, Matt Roper wrote:
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index a408ec2d3958..4566c95da1ca 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -20,6 +20,7 @@
> > #include "skl_scaler.h"
> > #include "skl_universal_plane.h"
> > #include "skl_watermark.h"
> > +#include "gt/intel_gt.h"
> > #include "pxp/intel_pxp.h"
> >
> > static const u32 skl_plane_formats[] = {
> > @@ -2169,8 +2170,8 @@ static bool skl_plane_has_rc_ccs(struct
> > drm_i915_private *i915,
> > enum pipe pipe, enum plane_id plane_id)
> > {
> > /* Wa_14017240301 */
> > - if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> > - IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
> > + if (IS_GFX_GT_IP_STEP(to_gt(i915), IP_VER(12, 70), STEP_A0, STEP_B0) ||
> > + IS_GFX_GT_IP_STEP(to_gt(i915), IP_VER(12, 71), STEP_A0, STEP_B0))
> > return false;
>
> This seems to be the only user of IS_GFX_GT_IP_STEP() under display/,
> and it kind of seems wrong to have display code check for GT
> versions. Is there a clean way to move this out of display?
If I remember correctly, this one literally is tied to the graphics IP
rather than the display IP. There's something busted with how the
graphics GT is trying to generate compressed buffers that causes them to
not decompress properly in the display controller (although GT<->GT
compression/decompression is okay since both sides are broken in the
same way). So the workaround is to not advertise our display planes as
having support for compressed buffers when the GT is A-step, because we
know they're going to show up in the wrong format. That still allows
compression to be used for the non-display use cases, but avoids
possible display corruption.
Honestly the simplest solution might be to just go ahead and delete this
workaround since it's only relevant to pre-production hardware. I know
our general policy has always been to hang on to workarounds for
pre-production steppings in the driver until the n+1 platform/IP is
pretty far along, but in this case it looks like our CI machines are
already on B0 GT stepping, and even if some internal people are still
working with older boards, this is still kind of a corner case that
probably won't impact most usage.
Matt
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] [PATCH] drm/i915: Use vblank worker to unpin old legacy cursor fb safely
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased accessing it. The simplest approach is to just use a vblank
work here to do the delayed unpin.
Not 100% sure it's a good idea to put this onto the same high
priority vblank worker as eg. our timing critical gamma updates.
But let's keep it simple for now, and it we later discover that
this is causing problems we can think about adding a lower
priority worker for such things.
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 25 +--
.../drm/i915/display/intel_display_types.h| 3 +++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
b/drivers/gpu/drm/i915/display/intel_cursor.c
index b342fad180ca..2bd1a79c6955 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -603,6 +603,16 @@ static bool intel_cursor_format_mod_supported(struct
drm_plane *_plane,
return format == DRM_FORMAT_ARGB;
}
+static void intel_cursor_unpin_work(struct kthread_work *base)
+{
+ struct drm_vblank_work *work = to_drm_vblank_work(base);
+ struct intel_plane_state *plane_state =
+ container_of(work, typeof(*plane_state), unpin_work);
+
+ intel_plane_unpin_fb(plane_state);
+ intel_plane_destroy_state(plane_state->uapi.plane, &plane_state->uapi);
+}
+
static int
intel_legacy_cursor_update(struct drm_plane *_plane,
struct drm_crtc *_crtc,
@@ -730,14 +740,25 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
local_irq_enable();
- intel_plane_unpin_fb(old_plane_state);
+ if (old_plane_state->hw.fb != new_plane_state->hw.fb) {
+ drm_vblank_work_init(&old_plane_state->unpin_work, &crtc->base,
+intel_cursor_unpin_work);
+
+ drm_vblank_work_schedule(&old_plane_state->unpin_work,
+
drm_crtc_accurate_vblank_count(&crtc->base) + 1,
+false);
+
+ old_plane_state = NULL;
+ } else {
+ intel_plane_unpin_fb(old_plane_state);
+ }
out_free:
if (new_crtc_state)
intel_crtc_destroy_state(&crtc->base, &new_crtc_state->uapi);
if (ret)
intel_plane_destroy_state(&plane->base, &new_plane_state->uapi);
- else
+ else if (old_plane_state)
intel_plane_destroy_state(&plane->base, &old_plane_state->uapi);
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c62f4ec315e8..07394a33e747 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -702,6 +702,9 @@ struct intel_plane_state {
struct intel_fb_view view;
+ /* for legacy cursor fb unpin */
+ struct drm_vblank_work unpin_work;
+
/* Plane pxp decryption state */
bool decrypt;
--
2.41.0
Re: [Intel-gfx] [PATCH v5 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP
On Mon, 21 Aug 2023, Matt Roper wrote:
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index a408ec2d3958..4566c95da1ca 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -20,6 +20,7 @@
> #include "skl_scaler.h"
> #include "skl_universal_plane.h"
> #include "skl_watermark.h"
> +#include "gt/intel_gt.h"
> #include "pxp/intel_pxp.h"
>
> static const u32 skl_plane_formats[] = {
> @@ -2169,8 +2170,8 @@ static bool skl_plane_has_rc_ccs(struct
> drm_i915_private *i915,
>enum pipe pipe, enum plane_id plane_id)
> {
> /* Wa_14017240301 */
> - if (IS_MTL_GRAPHICS_STEP(i915, M, STEP_A0, STEP_B0) ||
> - IS_MTL_GRAPHICS_STEP(i915, P, STEP_A0, STEP_B0))
> + if (IS_GFX_GT_IP_STEP(to_gt(i915), IP_VER(12, 70), STEP_A0, STEP_B0) ||
> + IS_GFX_GT_IP_STEP(to_gt(i915), IP_VER(12, 71), STEP_A0, STEP_B0))
> return false;
This seems to be the only user of IS_GFX_GT_IP_STEP() under display/,
and it kind of seems wrong to have display code check for GT
versions. Is there a clean way to move this out of display?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: add minimal i915_gem_object_frontbuffer.h
On Wed, 30 Aug 2023, "Hogander, Jouni" wrote: > On Wed, 2023-08-30 at 11:51 +0300, Jani Nikula wrote: >> Split out frontbuffer related declarations and static inlines from >> gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h. >> >> The main goal is to reduce header interdependencies. With >> gem/i915_gem_object.h including display/intel_frontbuffer.h, >> modification of the latter causes a whopping 300+ objects to be >> rebuilt, >> while many of the source files actually needing it aren't explicitly >> including it at all. >> >> After the change, only 21 objects depend on >> display/intel_frontbuffer.h, >> directly or indirectly. >> >> Cc: Jouni Högander >> Signed-off-by: Jani Nikula > > Reviewed-by: Jouni Högander Thanks, pushed to drm-intel-next. BR, Jani. > >> >> --- >> >> Side note: Many of the files including intel_frontbuffer.h implicitly >> failed to build on xe without adding the explicit include. This >> should >> address that as well. >> --- >> drivers/gpu/drm/i915/display/i9xx_plane.c | 1 + >> drivers/gpu/drm/i915/display/intel_drrs.c | 1 + >> drivers/gpu/drm/i915/display/intel_fb.c | 1 + >> .../gpu/drm/i915/display/intel_frontbuffer.c | 1 + >> drivers/gpu/drm/i915/display/intel_overlay.c | 1 + >> .../drm/i915/display/intel_plane_initial.c| 1 + >> drivers/gpu/drm/i915/display/intel_psr.c | 1 + >> drivers/gpu/drm/i915/display/intel_sprite.c | 1 + >> .../drm/i915/display/skl_universal_plane.c| 1 + >> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 3 +- >> drivers/gpu/drm/i915/gem/i915_gem_domain.c| 2 +- >> drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 + >> drivers/gpu/drm/i915/gem/i915_gem_object.h| 89 --- >> .../i915/gem/i915_gem_object_frontbuffer.h| 103 >> ++ >> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 1 + >> drivers/gpu/drm/i915/i915_gem.c | 2 +- >> drivers/gpu/drm/i915/i915_vma.c | 1 + >> 17 files changed, 118 insertions(+), 93 deletions(-) >> create mode 100644 >> drivers/gpu/drm/i915/gem/i915_gem_object_frontbuffer.h >> >> diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c >> b/drivers/gpu/drm/i915/display/i9xx_plane.c >> index b10488324457..91f2bc405cba 100644 >> --- a/drivers/gpu/drm/i915/display/i9xx_plane.c >> +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c >> @@ -17,6 +17,7 @@ >> #include "intel_display_types.h" >> #include "intel_fb.h" >> #include "intel_fbc.h" >> +#include "intel_frontbuffer.h" >> #include "intel_sprite.h" >> >> /* Primary plane formats for gen <= 3 */ >> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c >> b/drivers/gpu/drm/i915/display/intel_drrs.c >> index 0d35b6be5b6a..6282ec0fc9b4 100644 >> --- a/drivers/gpu/drm/i915/display/intel_drrs.c >> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c >> @@ -9,6 +9,7 @@ >> #include "intel_de.h" >> #include "intel_display_types.h" >> #include "intel_drrs.h" >> +#include "intel_frontbuffer.h" >> #include "intel_panel.h" >> >> /** >> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c >> b/drivers/gpu/drm/i915/display/intel_fb.c >> index 446bbf7986b6..b1bfbbef89b5 100644 >> --- a/drivers/gpu/drm/i915/display/intel_fb.c >> +++ b/drivers/gpu/drm/i915/display/intel_fb.c >> @@ -12,6 +12,7 @@ >> #include "intel_display_types.h" >> #include "intel_dpt.h" >> #include "intel_fb.h" >> +#include "intel_frontbuffer.h" >> >> #define check_array_bounds(i915, a, i) drm_WARN_ON(&(i915)->drm, (i) >> >= ARRAY_SIZE(a)) >> >> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c >> b/drivers/gpu/drm/i915/display/intel_frontbuffer.c >> index 22392f94b626..54ddb69eca66 100644 >> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c >> +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c >> @@ -55,6 +55,7 @@ >> * cancelled as soon as busyness is detected. >> */ >> >> +#include "gem/i915_gem_object_frontbuffer.h" >> #include "i915_drv.h" >> #include "intel_display_trace.h" >> #include "intel_display_types.h" >> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c >> b/drivers/gpu/drm/i915/display/intel_overlay.c >> index dea3050d2c9c..2b1392d5a902 100644 >> --- a/drivers/gpu/drm/i915/display/intel_overlay.c >> +++ b/drivers/gpu/drm/i915/display/intel_overlay.c >> @@ -29,6 +29,7 @@ >> #include >> >> #include "gem/i915_gem_internal.h" >> +#include "gem/i915_gem_object_frontbuffer.h" >> #include "gem/i915_gem_pm.h" >> #include "gt/intel_gpu_commands.h" >> #include "gt/intel_ring.h" >> diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c >> b/drivers/gpu/drm/i915/display/intel_plane_initial.c >> index 736072a8b2b0..451a642e106e 100644 >> --- a/drivers/gpu/drm/i915/display/intel_plane_initial.c >> +++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c >> @@ -9,6 +9,7 @@ >> #include "intel_display.h" >> #include "intel_display_types.h" >> #include "intel_fb.h" >> +#include "intel_frontbuffer.h" >> #include "i
Re: [Intel-gfx] [PATCH v4 16/29] KVM: x86: Reject memslot MOVE operations if KVMGT is attached
On Thu, Aug 31, 2023, Like Xu wrote:
> On 31/8/2023 4:50 am, Sean Christopherson wrote:
> > On Wed, Aug 30, 2023, Like Xu wrote:
> > > On 2023/7/29 09:35, Sean Christopherson wrote:
> > > > Disallow moving memslots if the VM has external page-track users, i.e.
> > > > if
> > > > KVMGT is being used to expose a virtual GPU to the guest, as KVMGT
> > > > doesn't
> > > > correctly handle moving memory regions.
> > > >
> > > > Note, this is potential ABI breakage! E.g. userspace could move regions
> > > > that aren't shadowed by KVMGT without harming the guest. However, the
> > > > only known user of KVMGT is QEMU, and QEMU doesn't move generic memory
> > >
> > > This change breaks two kvm selftests:
> > >
> > > - set_memory_region_test;
> > > - memslot_perf_test;
> >
> > It shoudn't. As of this patch, KVM doesn't register itself as a page-track
> > user,
> > i.e. KVMGT is the only remaining caller to
> > kvm_page_track_register_notifier().
> > Unless I messed up, the only way kvm_page_track_has_external_user() can
> > return
> > true is if KVMGT is attached to the VM. The selftests most definitely
> > don't do
> > anything with KVMGT, so I don't see how they can fail.
> >
> > Are you seeing actually failures?
>
> $ set_memory_region_test
...
> At one point I wondered if some of the less common kconfig's were enabled,
> but the above two test failures could be easily fixed with the following diff:
Argh, none of the configs I actually ran selftests on selected
CONFIG_KVM_EXTERNAL_WRITE_TRACKING=y.
> diff --git a/arch/x86/kvm/mmu/page_track.h b/arch/x86/kvm/mmu/page_track.h
> index 62f98c6c5af3..d4d72ed999b1 100644
> --- a/arch/x86/kvm/mmu/page_track.h
> +++ b/arch/x86/kvm/mmu/page_track.h
> @@ -32,7 +32,7 @@ void kvm_page_track_delete_slot(struct kvm *kvm, struct
> kvm_memory_slot *slot);
>
> static inline bool kvm_page_track_has_external_user(struct kvm *kvm)
> {
> - return hlist_empty(&kvm->arch.track_notifier_head.track_notifier_list);
> + return !hlist_empty(&kvm->arch.track_notifier_head.track_notifier_list);
> }
> #else
> static inline int kvm_page_track_init(struct kvm *kvm) { return 0; }
>
> , so I guess it's pretty obvious what's going on here.
Yes. I'll rerun tests today and get the above posted on your behalf (unless you
don't want me to do that).
Sorry for yet another screw up, and thanks for testing!
[Intel-gfx] [PATCH] drm/i915: Add Wa_14015150844
Disables Atomic-chaining of Typed Writes.
BSpec: 54040
Signed-off-by: Shekhar Chauhan
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 ++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 0e4c638fcbbf..82b533aa0c03 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1218,6 +1218,8 @@
#define XEHP_HDC_CHICKEN0 MCR_REG(0xe5f0)
#define LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK REG_GENMASK(13,
11)
+#define ATOMIC_CHAINING_TYPED_WRITES REG_BIT(3)
+
#define ICL_HDC_MODE MCR_REG(0xe5f4)
#define EU_PERF_CNTL2 PERF_REG(0xe658)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 864d41bcf6bb..d853f228fabd 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2327,6 +2327,14 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK);
}
+ if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
+ IS_DG2(i915)) {
+ /* Wa_14015150844 */
+ wa_mcr_add(wal, XEHP_HDC_CHICKEN0, 0,
+ _MASKED_BIT_DISABLE(ATOMIC_CHAINING_TYPED_WRITES),
+ 0, true);
+ }
+
if (IS_DG2_G11(i915) || IS_DG2_G10(i915)) {
/* Wa_22014600077:dg2 */
wa_mcr_add(wal, GEN10_CACHE_MODE_SS, 0,
--
2.34.1
Re: [Intel-gfx] [PATCH i-g-t] tests/i915_pm_freq_api: Test s2idle instead of S3
> -Original Message- > From: Belgaumkar, Vinay > Sent: Thursday, August 31, 2023 5:09 AM > To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org > Cc: Belgaumkar, Vinay ; Gupta, Anshuman > > Subject: [PATCH i-g-t] tests/i915_pm_freq_api: Test s2idle instead of S3 > > Test skips whenever S3 is not supported, use s2idle instead, which is widely > enabled. > > Cc: Anshuman Gupta > Signed-off-by: Vinay Belgaumkar Reviewed-by: Anshuman Gupta > --- > tests/i915/i915_pm_freq_api.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c > index 2912287c4..03bd0d05b 100644 > --- a/tests/i915/i915_pm_freq_api.c > +++ b/tests/i915/i915_pm_freq_api.c > @@ -125,7 +125,7 @@ static void test_suspend(int i915, int dirfd, int gt) > igt_assert_eq(req_freq, rpn); > > /* Manually trigger a suspend */ > - igt_system_suspend_autoresume(SUSPEND_STATE_S3, > + igt_system_suspend_autoresume(SUSPEND_STATE_FREEZE, > SUSPEND_TEST_NONE); > > req_freq = get_freq(dirfd, RPS_CUR_FREQ_MHZ); > -- > 2.38.1
[Intel-gfx] [PATCH v4 0/2] Apply Wa_16018031267 / Wa_16018063123
Apply Wa_16018031267 / Wa_16018063123. This necessitates submitting a fastcolor blit as WABB and setting the copy engine arbitration to round-robin mode. v2: - Rename old platform check in second patch to match declaration in first patch. - Refactor second patch name to match first patch. v3: - Move NEEDS_FASTCOLOR_BLT_WABB to intel_gt.h. - Refactor NEEDS_FASTCOLOR_BLT_WABB to make it more streamlined to use. - Stop dividing PAGE_SIZE by sizeof(u32) when computing ctx_bb_ggtt_addr for lrc_setup_bb_per_ctx. - Reduce comment complexity. - Fix several checkpatch warnings. v4: - Actually stop dividing PAGE_SIZE by sizeof(u32) when computing ctx_bb_ggtt_addr for lrc_setup_bb_per_ctx. Signed-off-by: Nirmoy Das Signed-off-by: Jonathan Cavitt CC: Joonas Lahtinen CC: Rodrigo Vivi CC: Tomasz Mistat CC: Gregory F Germano CC: Matt Roper CC: James Ausmus Nirmoy Das (2): drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123 drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123 drivers/gpu/drm/i915/gt/intel_engine_regs.h | 6 ++ drivers/gpu/drm/i915/gt/intel_gt.h | 4 + drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 + drivers/gpu/drm/i915/gt/intel_lrc.c | 107 +++- drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + drivers/gpu/drm/i915/gt/selftest_lrc.c | 65 6 files changed, 168 insertions(+), 21 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v4 1/2] drm/i915: Add WABB blit for Wa_16018031267 / Wa_16018063123
From: Nirmoy Das
Apply WABB blit for Wa_16018031267 / Wa_16018063123.
Additionally, update the lrc selftest to exercise the new
WABB changes.
Co-developed-by: Nirmoy Das
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +
drivers/gpu/drm/i915/gt/intel_gt.h | 4 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 107 +++-
drivers/gpu/drm/i915/gt/selftest_lrc.c | 65
5 files changed, 160 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 6b9d9f8376692..2e06bea73297a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -118,6 +118,9 @@
#define CCID_EXTENDED_STATE_RESTORE BIT(2)
#define CCID_EXTENDED_STATE_SAVE BIT(3)
#define RING_BB_PER_CTX_PTR(base) _MMIO((base) + 0x1c0) /* gen8+
*/
+#define PER_CTX_BB_FORCE BIT(2)
+#define PER_CTX_BB_VALID BIT(0)
+
#define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4)
/* gen8+ */
#define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+
*/
#define ECOSKPD(base) _MMIO((base) + 0x1d0)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 239848bcb2a42..40cc0005dd735 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -83,6 +83,10 @@ struct drm_printer;
##__VA_ARGS__); \
} while (0)
+#define NEEDS_FASTCOLOR_BLT_WABB(engine) ( \
+ IS_GFX_GT_IP_RANGE(engine->gt, IP_VER(12, 55), IP_VER(12, 71)) && \
+ engine->class == COPY_ENGINE_CLASS)
+
static inline bool gt_is_root(struct intel_gt *gt)
{
return !gt->info.id;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index def7dd0eb6f19..4917633f299dd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -307,6 +307,8 @@ enum intel_gt_scratch_field {
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
+
+ INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT = 384,
};
#define intel_gt_support_legacy_fencing(gt) ((gt)->ggtt->num_fences > 0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 967fe4d77a874..1e0c1438f2cd1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -828,6 +828,18 @@ lrc_ring_indirect_offset_default(const struct
intel_engine_cs *engine)
return 0;
}
+static void
+lrc_setup_bb_per_ctx(u32 *regs,
+const struct intel_engine_cs *engine,
+u32 ctx_bb_ggtt_addr)
+{
+ GEM_BUG_ON(lrc_ring_wa_bb_per_ctx(engine) == -1);
+ regs[lrc_ring_wa_bb_per_ctx(engine) + 1] =
+ ctx_bb_ggtt_addr |
+ PER_CTX_BB_FORCE |
+ PER_CTX_BB_VALID;
+}
+
static void
lrc_setup_indirect_ctx(u32 *regs,
const struct intel_engine_cs *engine,
@@ -997,7 +1009,13 @@ static u32 context_wa_bb_offset(const struct
intel_context *ce)
return PAGE_SIZE * ce->wa_bb_page;
}
-static u32 *context_indirect_bb(const struct intel_context *ce)
+/*
+ * per_ctx below determines which WABB section is used.
+ * When true, the function returns the location of the
+ * PER_CTX_BB. When false, the function returns the
+ * location of the INDIRECT_CTX.
+ */
+static u32 *context_wabb(const struct intel_context *ce, bool per_ctx)
{
void *ptr;
@@ -1006,6 +1024,7 @@ static u32 *context_indirect_bb(const struct
intel_context *ce)
ptr = ce->lrc_reg_state;
ptr -= LRC_STATE_OFFSET; /* back to start of context image */
ptr += context_wa_bb_offset(ce);
+ ptr += per_ctx ? PAGE_SIZE : 0;
return ptr;
}
@@ -1082,7 +1101,8 @@ __lrc_alloc_state(struct intel_context *ce, struct
intel_engine_cs *engine)
if (GRAPHICS_VER(engine->i915) >= 12) {
ce->wa_bb_page = context_size / PAGE_SIZE;
- context_size += PAGE_SIZE;
+ /* INDIRECT_CTX and PER_CTX_BB need separate pages. */
+ context_size += PAGE_SIZE * 2;
}
if (intel_context_is_parent(ce) && intel_engine_uses_guc(engine)) {
@@ -1370,12 +1390,92 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
*ce, u32 *cs)
return gen12_emit_aux_table_inv(ce->engine, cs);
}
+static u32 *xehp_emit_fastcolor_blt_wabb(const struct intel_context *ce, u32
*cs)
+{
+ struct intel_gt *gt = ce->engine->gt;
+ int mocs = gt->mocs.uc_index << 1;
+ u32 addr = intel_gt_scratch_offset(gt,
INTEL_GT_SCRATCH_FIELD_DUMMY_BLIT);
+
+ /**
+* Wa_16018031267 / Wa_16018063123 requ
[Intel-gfx] [PATCH v4 2/2] drm/i915: Set copy engine arbitration for Wa_16018031267 / Wa_16018063123
From: Nirmoy Das Set copy engine arbitration into round robin mode for part of Wa_16018031267 / Wa_16018063123 mitigation. Signed-off-by: Nirmoy Das Signed-off-by: Jonathan Cavitt --- drivers/gpu/drm/i915/gt/intel_engine_regs.h | 3 +++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h b/drivers/gpu/drm/i915/gt/intel_engine_regs.h index 2e06bea73297a..823c6c40213f5 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h @@ -124,6 +124,9 @@ #define RING_INDIRECT_CTX(base)_MMIO((base) + 0x1c4) /* gen8+ */ #define RING_INDIRECT_CTX_OFFSET(base) _MMIO((base) + 0x1c8) /* gen8+ */ #define ECOSKPD(base) _MMIO((base) + 0x1d0) +#define XEHP_BLITTER_SCHEDULING_MODE_MASKREG_GENMASK(12, 11) +#define XEHP_BLITTER_ROUND_ROBIN_MODE\ + REG_FIELD_PREP(XEHP_BLITTER_SCHEDULING_MODE_MASK, 1) #define ECO_CONSTANT_BUFFER_SR_DISABLE REG_BIT(4) #define ECO_GATING_CX_ONLY REG_BIT(3) #define GEN6_BLITTER_FBC_NOTIFY REG_BIT(3) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 864d41bcf6bbe..e891e7c8c0787 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2769,6 +2769,11 @@ xcs_engine_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal) RING_SEMA_WAIT_POLL(engine->mmio_base), 1); } + /* Wa_16018031267, Wa_16018063123 */ + if (NEEDS_FASTCOLOR_BLT_WABB(engine)) + wa_masked_field_set(wal, ECOSKPD(engine->mmio_base), + XEHP_BLITTER_SCHEDULING_MODE_MASK, + XEHP_BLITTER_ROUND_ROBIN_MODE); } static void -- 2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cx0: Check and increase msgbus timeout threshold (rev3)
== Series Details ==
Series: drm/i915/cx0: Check and increase msgbus timeout threshold (rev3)
URL : https://patchwork.freedesktop.org/series/122982/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13579 -> Patchwork_122982v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/index.html
Participating hosts (39 -> 39)
--
Additional (2): bat-adlp-11 fi-bsw-n3050
Missing(2): bat-rpls-2 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_122982v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html
* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg2-9: [PASS][2] -> [INCOMPLETE][3] ([i915#6311])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050: NOTRUN -> [SKIP][4] ([fdo#109271]) +18 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-adlp-11/igt@gem_tiled_pread_basic.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][6] ([i915#7978] / [i915#8668])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#4103]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-11:NOTRUN -> [SKIP][8] ([i915#4093]) +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-5:
- bat-adlp-11:NOTRUN -> [ABORT][9] ([i915#8668])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-dp-5.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: [FAIL][10] ([fdo#103375]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-rpls-1: [INCOMPLETE][12] ([i915#7677]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
* igt@vgem_basic@debugfs:
- fi-kbl-soraka: [INCOMPLETE][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-kbl-soraka/igt@vgem_ba...@debugfs.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v3/fi-kbl-soraka/igt@vgem_ba...@debugfs.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#4093]: https://gitlab.freedesktop.org/drm/intel/issues/4093
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
[i915#7677]: https://gitlab.freedesktop.org/drm/intel/issues/7677
[i915#7952]: https://gitlab.freedesktop.org/drm/intel/issues/7952
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
Build changes
-
* Linux: CI_DRM_13579 -> Patchwork_122982v3
CI-20190529: 20190529
CI_DRM_13579: 27896186d81a305aab16bf1a3b964a321d00ed38 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7460: 30b4034ea562952039ba6af58106791d5c3e
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/cx0: Check and increase msgbus timeout threshold (rev3)
== Series Details == Series: drm/i915/cx0: Check and increase msgbus timeout threshold (rev3) URL : https://patchwork.freedesktop.org/series/122982/ State : warning == Summary == Error: dim checkpatch failed e8aaebe5ef58 drm/i915/cx0: Check and increase msgbus timeout threshold -:110: WARNING:LONG_LINE: line length of 115 exceeds 100 columns #110: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:118: + _XELPDP_PORT_MSGBUS_TIMER_LN0_A, \ -:111: WARNING:LONG_LINE: line length of 115 exceeds 100 columns #111: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:119: + _XELPDP_PORT_MSGBUS_TIMER_LN0_B, \ -:112: WARNING:LONG_LINE: line length of 119 exceeds 100 columns #112: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:120: + _XELPDP_PORT_MSGBUS_TIMER_LN0_USBC1, \ -:113: WARNING:LONG_LINE: line length of 131 exceeds 100 columns #113: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:121: + _XELPDP_PORT_MSGBUS_TIMER_LN0_USBC2) + (lane) * 4) -:116: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #116: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:124: +#define XELPDP_PORT_MSGBUS_TIMER_VAL(val) REG_FIELD_PREP(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, val) total: 0 errors, 5 warnings, 0 checks, 76 lines checked
Re: [Intel-gfx] [PATCH 1/1] drm/i915/gt: Wait longer for tasks in migrate selftest
Hi Jonathan,
On Mon, Aug 28, 2023 at 12:28:52PM -0700, Jonathan Cavitt wrote:
> The thread_global_copy subtest of the live migrate selftest creates a
> large number of threads and waits 10ms for them all to start. This is
> not enough time to wait for the threaded tasks to start, as some may
> need to wait for additional ring space to be granted. Threads that do
> so are at risk of getting stopped (signaled) in the middle of waiting
> for additional space, which can result in ERESTARTSYS getting reported
> erroneously by i915_request_wait.
>
> Instead of waiting a flat 10ms for the threads to start, wait 10ms per
> thread. This grants enough of a buffer for each thread to wait for
> additional ring space when needed.
>
> Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Andi
> ---
> drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
> b/drivers/gpu/drm/i915/gt/selftest_migrate.c
> index 3def5ca72dec..1a34cbe04fb6 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_migrate.c
> @@ -710,7 +710,7 @@ static int threaded_migrate(struct intel_migrate *migrate,
> thread[i].tsk = tsk;
> }
>
> - msleep(10); /* start all threads before we kthread_stop() */
> + msleep(10 * n_cpus); /* start all threads before we kthread_stop() */
>
> for (i = 0; i < n_cpus; ++i) {
> struct task_struct *tsk = thread[i].tsk;
> --
> 2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm, cec and edid updates (rev3)
== Series Details ==
Series: drm, cec and edid updates (rev3)
URL : https://patchwork.freedesktop.org/series/122841/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13579 -> Patchwork_122841v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/index.html
Participating hosts (39 -> 40)
--
Additional (2): bat-adlp-11 fi-bsw-n3050
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_122841v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html
* igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050: NOTRUN -> [SKIP][2] ([fdo#109271]) +18 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#3282])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-adlp-11/igt@gem_tiled_pread_basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][4] -> [DMESG-FAIL][5] ([i915#5334])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][6] ([i915#7978] / [i915#8668])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#4103]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-11:NOTRUN -> [SKIP][8] ([i915#4093]) +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-5:
- bat-adlp-11:NOTRUN -> [ABORT][9] ([i915#8668])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-dp-5.html
* igt@kms_psr@primary_mmap_gtt:
- bat-rplp-1: NOTRUN -> [SKIP][10] ([i915#1072]) +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [ABORT][11] ([i915#8260] / [i915#8668])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: [FAIL][12] ([fdo#103375]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-rpls-1: [INCOMPLETE][14] ([i915#7677]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
* igt@vgem_basic@debugfs:
- fi-kbl-soraka: [INCOMPLETE][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-kbl-soraka/igt@vgem_ba...@debugfs.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/fi-kbl-soraka/igt@vgem_ba...@debugfs.html
Warnings
* igt@kms_psr@cursor_plane_move:
- bat-rplp-1: [ABORT][18] ([i915#8469] / [i915#8668] / [i915#9243])
-> [SKIP][19] ([i915#1072])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122841v3/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1072]: https://gitlab.freedesk
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm, cec and edid updates (rev3)
== Series Details == Series: drm, cec and edid updates (rev3) URL : https://patchwork.freedesktop.org/series/122841/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Populate connector->ddc always (rev2)
== Series Details ==
Series: drm/i915: Populate connector->ddc always (rev2)
URL : https://patchwork.freedesktop.org/series/123006/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13579 -> Patchwork_123006v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_123006v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_123006v2, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/index.html
Participating hosts (39 -> 40)
--
Additional (2): bat-adlp-11 fi-bsw-n3050
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_123006v2:
### IGT changes ###
Possible regressions
* igt@kms_addfb_basic@unused-pitches:
- fi-apl-guc: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-apl-guc/igt@kms_addfb_ba...@unused-pitches.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/fi-apl-guc/igt@kms_addfb_ba...@unused-pitches.html
Known issues
Here are the changes found in Patchwork_123006v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#7456])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html
* igt@gem_exec_suspend@basic-s0@lmem0:
- bat-dg2-9: [PASS][4] -> [INCOMPLETE][5] ([i915#6311])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html
* igt@gem_lmem_swapping@random-engines:
- fi-bsw-n3050: NOTRUN -> [SKIP][6] ([fdo#109271]) +18 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/fi-bsw-n3050/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_tiled_pread_basic:
- bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#3282])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-adlp-11/igt@gem_tiled_pread_basic.html
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][8] -> [DMESG-WARN][9] ([i915#7699])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-1: NOTRUN -> [ABORT][10] ([i915#7978] / [i915#8668])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-11:NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-11:NOTRUN -> [SKIP][12] ([i915#4093]) +3 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-5:
- bat-adlp-11:NOTRUN -> [ABORT][13] ([i915#8668])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-dp-5.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: [FAIL][14] ([fdo#103375]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-rpls-1: [INCOMPLETE][16] ([i915#7677]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html
* igt@vgem_basic@debugfs:
- fi-kbl-soraka: [INCOMPLETE][18] -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13579/fi-kbl-soraka/igt@vgem_ba...@debugfs.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_123006v2/fi-kbl-soraka/igt@vgem_ba...@debugfs.html
{name}: This element is
Re: [Intel-gfx] [PATCH v5] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset
Hi,
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index a0e3ef1c65d2..600388c849f7 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -1359,7 +1359,16 @@ static void guc_enable_busyness_worker(struct
> > > > intel_guc *guc)
> > > >static void guc_cancel_busyness_worker(struct intel_guc *guc)
> > > >{
> > > > - cancel_delayed_work_sync(&guc->timestamp.work);
> > > > + /*
> > > > +* When intel_gt_reset was called, task will hold a lock.
> > > > +* To cacel delayed work here, the _sync version will also
> > > > acquire a lock, which might
> > > > +* trigger the possible cirular locking dependency warning.
> > > > +* Check the reset_in_progress flag, call async verion if reset
> > > > is in progress.
> > > > +*/
> > > This needs to explain in much more detail what is going on and why it is
> > > not
> > > a problem. E.g.:
> > >
> > > The busyness worker needs to be cancelled. In general that means
> > > using the synchronous cancel version to ensure that an in-progress
> > > worker will not keep executing beyond whatever is happening that
> > > needs the cancel. E.g. suspend, driver unload, etc. However, in the
> > > case of a reset, the synchronous version is not required and can
> > > trigger a false deadlock detection warning.
> > >
> > > The business worker takes the reset mutex to protect against resets
> > > interfering with it. However, it does a trylock and bails out if the
> > > reset lock is already acquired. Thus there is no actual deadlock or
> > > other concern with the worker running concurrently with a reset. So
> > > an asynchronous cancel is safe in the case of a reset rather than a
> > > driver unload or suspend type operation. On the other hand, if the
> > > cancel_sync version is used when a reset is in progress then the
> > > mutex deadlock detection sees the mutex being acquired through
> > > multiple paths and complains.
> > >
> > > So just don't bother. That keeps the detection code happy and is
> > > safe because of the trylock code described above.
> > So why do we even need to cancel anything if it doesn't do anything while
> > the reset is in progress?
> It still needs to be cancelled. The worker only aborts if it is actively
> executing concurrently with the reset. It might not start to execute until
> after the reset has completed. And there is presumably a reason why the
> cancel is being called, a reason not necessarily related to resets at all.
> Leaving the worker to run arbitrarily after the driver is expecting it to be
> stopped will lead to much worse things than a fake lockdep splat, e.g. a use
> after free pointer deref.
I was actually thinking why not leave things as they are and just
disable lockdep from CI. This doesn't look like a relevant report
to me.
Andi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Populate connector->ddc always (rev2)
== Series Details == Series: drm/i915: Populate connector->ddc always (rev2) URL : https://patchwork.freedesktop.org/series/123006/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/inc
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Populate connector->ddc always (rev2)
== Series Details == Series: drm/i915: Populate connector->ddc always (rev2) URL : https://patchwork.freedesktop.org/series/123006/ State : warning == Summary == Error: dim checkpatch failed 47a1e16097f5 drm: Reorder drm_sysfs_connector_remove() vs. drm_debugfs_connector_remove() 2ac1ee4c65aa drm/sysfs: Register "ddc" symlink later f0193be71b51 drm/i915: Call the DDC bus i2c adapter "ddc" 43e09a3902ce drm/i915/lvds: Populate connector->ddc 6b3844d1cca8 drm/i915/crt: Populate connector->ddc 5d50373b61f7 drm/i915/dvo: Populate connector->ddc be8dd2ee3da3 drm/i915/dp: Populate connector->ddc fcbd58896620 drm/i915/mst: Populate connector->ddc -:14: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use 'Link:' or 'Closes:' instead #14: References: https://gitlab.freedesktop.org/drm/intel/-/issues/3605 total: 0 errors, 1 warnings, 0 checks, 12 lines checked 52dcff2e47f8 drm/i915/hdmi: Use connector->ddc everwhere b7da451d677e drm/i915/hdmi: Nuke hdmi->ddc_bus e6b491317b4d drm/i915/hdmi: Remove old i2c symlink 55695e375316 drm/i915/sdvo: Constify mapping structs
[Intel-gfx] ✓ Fi.CI.IGT: success for Add DSC PPS readout (rev12)
== Series Details == Series: Add DSC PPS readout (rev12) URL : https://patchwork.freedesktop.org/series/120456/ State : success == Summary == CI Bug Log - changes from CI_DRM_13569_full -> Patchwork_120456v12_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_120456v12_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@blit-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][1] ([i915#8411]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-dg2-11/igt@api_intel...@blit-reloc-keep-cache.html * igt@drm_fdinfo@most-busy-check-all@bcs0: - shard-dg2: NOTRUN -> [SKIP][2] ([i915#8414]) +9 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-dg2-1/igt@drm_fdinfo@most-busy-check-...@bcs0.html * igt@drm_fdinfo@most-busy-check-all@rcs0: - shard-rkl: [PASS][3] -> [FAIL][4] ([i915#7742]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html * igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0: - shard-dg2: [PASS][5] -> [INCOMPLETE][6] ([i915#6311] / [i915#7297]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-dg2-11/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-dg2-3/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html * igt@gem_close_race@multigpu-basic-process: - shard-mtlp: NOTRUN -> [SKIP][7] ([i915#7697]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-mtlp-8/igt@gem_close_r...@multigpu-basic-process.html * igt@gem_create@create-ext-set-pat: - shard-rkl: NOTRUN -> [SKIP][8] ([i915#8562]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-rkl-2/igt@gem_cre...@create-ext-set-pat.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-rkl: [PASS][9] -> [FAIL][10] ([i915#6268]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-rkl-6/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_param@set-priority-not-supported: - shard-dg2: NOTRUN -> [SKIP][11] ([fdo#109314]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-dg2-8/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_sseu@invalid-args: - shard-mtlp: NOTRUN -> [SKIP][13] ([i915#280]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-mtlp-8/igt@gem_ctx_s...@invalid-args.html * igt@gem_eio@in-flight-contexts-1us: - shard-mtlp: [PASS][14] -> [ABORT][15] ([i915#8503]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-mtlp-4/igt@gem_...@in-flight-contexts-1us.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-mtlp-3/igt@gem_...@in-flight-contexts-1us.html * igt@gem_exec_balancer@bonded-sync: - shard-mtlp: NOTRUN -> [SKIP][16] ([i915#4771]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-mtlp-2/igt@gem_exec_balan...@bonded-sync.html * igt@gem_exec_capture@pi@rcs0: - shard-mtlp: [PASS][17] -> [FAIL][18] ([i915#4475]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-mtlp-2/igt@gem_exec_capture@p...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-mtlp-5/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-none: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#3539] / [i915#4852]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-dg2-8/igt@gem_exec_f...@basic-none.html * igt@gem_exec_fair@basic-pace: - shard-dg2: NOTRUN -> [SKIP][20] ([i915#3539]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/shard-dg2-1/igt@gem_exec_f...@basic-pace.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#2842]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-glk2/igt@gem_exec_fair@basic-p...@rcs0.html [22]: htt
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915_pm_freq_api: Test s2idle instead of S3
On 8/31/2023 5:08 AM, Vinay Belgaumkar wrote: Test skips whenever S3 is not supported, use s2idle instead, which is widely enabled. Cc: Anshuman Gupta Signed-off-by: Vinay Belgaumkar Looks good to me Reviewed-by: Riana Tauro --- tests/i915/i915_pm_freq_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/i915_pm_freq_api.c b/tests/i915/i915_pm_freq_api.c index 2912287c4..03bd0d05b 100644 --- a/tests/i915/i915_pm_freq_api.c +++ b/tests/i915/i915_pm_freq_api.c @@ -125,7 +125,7 @@ static void test_suspend(int i915, int dirfd, int gt) igt_assert_eq(req_freq, rpn); /* Manually trigger a suspend */ - igt_system_suspend_autoresume(SUSPEND_STATE_S3, + igt_system_suspend_autoresume(SUSPEND_STATE_FREEZE, SUSPEND_TEST_NONE); req_freq = get_freq(dirfd, RPS_CUR_FREQ_MHZ);
Re: [Intel-gfx] [PATCH v2] drm/i915/cx0: Check and increase msgbus timeout threshold
> -Original Message-
> From: Sousa, Gustavo
> Sent: Wednesday, August 30, 2023 3:15 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; Kahola, Mika
> ; Nikula, Jani
>
> Subject: [PATCH v2] drm/i915/cx0: Check and increase msgbus timeout threshold
>
> We have experienced timeout issues when going through the sequence to access
> C20 SRAM registers. Experimentation showed
> that bumping the message bus timer threshold helped on getting display Type-C
> connection on the C20 PHY to work.
>
> While the timeout is still under investigation with the HW team, having logic
> to allow forward progress (with the proper warnings)
> seems useful.
> Thus, let's bump the threshold when a timeout is detected.
>
> The bumped value of 0x200 pclk cycles was somewhat arbitrary - 2x the default
> value. That value was successfully tested on real
> hardware that was displaying timeouts otherwise.
>
> v2:
> - Reword commit message to indicate that access to C20 SRAM registers
> is not direct. (Radhakrishna)
> - Prefer not to use REG_FIELD_PREP() in intel_cx0_phy.c.
> (Radhakrishna)
> - Simplify intel_cx0_bus_check_and_bump_timer() to use a fixed bumped
> value instead of progressively increasing the threshold. (Mika)
>
> BSpec: 65156
> Cc: Radhakrishna Sripada
> Cc: Mika Kahola
Looks ok to me.
Reviewed-by: Mika Kahola
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 39 +++
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 13
> +++
> 2 files changed, 52 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index dd489b50ad60..ffc6b54be12b 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -29,6 +29,8 @@
> #define INTEL_CX0_LANE1 BIT(1)
> #define INTEL_CX0_BOTH_LANES (INTEL_CX0_LANE1 | INTEL_CX0_LANE0)
>
> +#define INTEL_CX0_MSGBUS_TIMER_BUMPED_VAL0x200
> +
> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy) {
> if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C) @@ -119,6
> +121,42 @@ static void
> intel_cx0_bus_reset(struct drm_i915_private *i915, enum port port, i
> intel_clear_response_ready_flag(i915, port, lane); }
>
> +/*
> + * Check if there was a timeout detected by the hardware in the message
> +bus
> + * and bump the threshold if so.
> + */
> +static void intel_cx0_bus_check_and_bump_timer(struct drm_i915_private *i915,
> +enum port port, int lane)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> + i915_reg_t reg;
> + u32 val;
> + u32 timer_val;
> +
> + reg = XELPDP_PORT_MSGBUS_TIMER(port, lane);
> + val = intel_de_read(i915, reg);
> +
> + if (!(val & XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT)) {
> + drm_warn(&i915->drm,
> + "PHY %c lane %d: hardware did not detect a timeout\n",
> + phy_name(phy), lane);
> + return;
> + }
> +
> + timer_val = REG_FIELD_GET(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, val);
> +
> + if (timer_val == INTEL_CX0_MSGBUS_TIMER_BUMPED_VAL)
> + return;
> +
> + val &= ~XELPDP_PORT_MSGBUS_TIMER_VAL_MASK;
> + val |=
> +XELPDP_PORT_MSGBUS_TIMER_VAL(INTEL_CX0_MSGBUS_TIMER_BUMPED_VAL);
> +
> + drm_dbg_kms(&i915->drm,
> + "PHY %c lane %d: increasing msgbus timer threshold to
> %#x\n",
> + phy_name(phy), lane, INTEL_CX0_MSGBUS_TIMER_BUMPED_VAL);
> + intel_de_write(i915, reg, val);
> +}
> +
> static int intel_cx0_wait_for_ack(struct drm_i915_private *i915, enum port
> port,
> int command, int lane, u32 *val)
> {
> @@ -132,6 +170,7 @@ static int intel_cx0_wait_for_ack(struct drm_i915_private
> *i915, enum port port,
>XELPDP_MSGBUS_TIMEOUT_SLOW, val)) {
> drm_dbg_kms(&i915->drm, "PHY %c Timeout waiting for message
> ACK. Status: 0x%x\n",
> phy_name(phy), *val);
> + intel_cx0_bus_check_and_bump_timer(i915, port, lane);
> intel_cx0_bus_reset(i915, port, lane);
> return -ETIMEDOUT;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> index cb5d1be2ba19..b2db4cc366d6 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> @@ -110,6 +110,19 @@
> #define CX0_P4PG_STATE_DISABLE 0xC
> #define CX0_P2_STATE_RESET 0x2
>
> +#define _XELPDP_PORT_MSGBUS_TIMER_LN0_A 0x640d8
> +#define _XELPDP_PORT_MSGBUS_TIMER_LN0_B 0x641d8
> +#define _XELPDP_PORT_MSGBUS_TIMER_LN0_USBC1 0x16f258
> +#define _XELPDP_PO
Re: [Intel-gfx] [PATCH 6/6] media: cec: core: add note about *_from_edid() function usage in drm
On Wed, 30 Aug 2023, Hans Verkuil wrote:
> On 24/08/2023 15:46, Jani Nikula wrote:
>> In the drm subsystem, the source physical address is, in most cases,
>> available without having to parse the EDID again. Add notes about
>> preferring to use the pre-parsed address instead.
>>
>> Cc: Hans Verkuil
>> Cc: linux-me...@vger.kernel.org
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/media/cec/core/cec-adap.c | 4
>> drivers/media/cec/core/cec-notifier.c | 4
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/drivers/media/cec/core/cec-adap.c
>> b/drivers/media/cec/core/cec-adap.c
>> index 241b1621b197..2c627ed611ed 100644
>> --- a/drivers/media/cec/core/cec-adap.c
>> +++ b/drivers/media/cec/core/cec-adap.c
>> @@ -1688,6 +1688,10 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16
>> phys_addr, bool block)
>> }
>> EXPORT_SYMBOL_GPL(cec_s_phys_addr);
>>
>> +/*
>> + * Note: In the drm subsystem, prefer calling cec_s_phys_addr() with
>> + * connector->display_info.source_physical_address if possible.
>> + */
>
> I would rephrase this:
>
> /*
> * Note: in the drm subsystem, prefer calling (if possible):
> *
> * cec_s_phys_addr(adap, connector->display_info.source_physical_address,
> false);
> */
>
> I think it is important to indicate that the last argument should be 'false'.
Agreed.
>
>> void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
>> const struct edid *edid)
>> {
>> diff --git a/drivers/media/cec/core/cec-notifier.c
>> b/drivers/media/cec/core/cec-notifier.c
>> index 389dc664b211..13f043b3025b 100644
>> --- a/drivers/media/cec/core/cec-notifier.c
>> +++ b/drivers/media/cec/core/cec-notifier.c
>> @@ -195,6 +195,10 @@ void cec_notifier_set_phys_addr(struct cec_notifier *n,
>> u16 pa)
>> }
>> EXPORT_SYMBOL_GPL(cec_notifier_set_phys_addr);
>>
>> +/*
>> + * Note: In the drm subsystem, prefer calling cec_notifier_set_phys_addr()
>> with
>> + * connector->display_info.source_physical_address if possible.
>> + */
>
> This comment is fine, there is no similar last argument here. But perhaps
> it is good to use a similar format as above. Up to you.
Thanks, rephrased both in v2.
BR,
Jani.
>
>> void cec_notifier_set_phys_addr_from_edid(struct cec_notifier *n,
>>const struct edid *edid)
>> {
>
> Regards,
>
> Hans
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH v2] media: cec: core: add note about *_from_edid() function usage in drm
In the drm subsystem, the source physical address is, in most cases,
available without having to parse the EDID again. Add notes about
preferring to use the pre-parsed address instead.
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
Signed-off-by: Jani Nikula
---
v2: rephrase comments, in particular indicate cec_s_phys_addr() should
be false (Hans)
---
drivers/media/cec/core/cec-adap.c | 5 +
drivers/media/cec/core/cec-notifier.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/drivers/media/cec/core/cec-adap.c
b/drivers/media/cec/core/cec-adap.c
index 241b1621b197..1109af525c35 100644
--- a/drivers/media/cec/core/cec-adap.c
+++ b/drivers/media/cec/core/cec-adap.c
@@ -1688,6 +1688,11 @@ void cec_s_phys_addr(struct cec_adapter *adap, u16
phys_addr, bool block)
}
EXPORT_SYMBOL_GPL(cec_s_phys_addr);
+/*
+ * Note: In the drm subsystem, prefer calling (if possible):
+ *
+ * cec_s_phys_addr(adap, connector->display_info.source_physical_address,
false);
+ */
void cec_s_phys_addr_from_edid(struct cec_adapter *adap,
const struct edid *edid)
{
diff --git a/drivers/media/cec/core/cec-notifier.c
b/drivers/media/cec/core/cec-notifier.c
index 389dc664b211..d600be0f7b67 100644
--- a/drivers/media/cec/core/cec-notifier.c
+++ b/drivers/media/cec/core/cec-notifier.c
@@ -195,6 +195,11 @@ void cec_notifier_set_phys_addr(struct cec_notifier *n,
u16 pa)
}
EXPORT_SYMBOL_GPL(cec_notifier_set_phys_addr);
+/*
+ * Note: In the drm subsystem, prefer calling (if possible):
+ *
+ * cec_notifier_set_phys_addr(n,
connector->display_info.source_physical_address);
+ */
void cec_notifier_set_phys_addr_from_edid(struct cec_notifier *n,
const struct edid *edid)
{
--
2.39.2
[Intel-gfx] [PATCH v2 03/12] drm/i915: Call the DDC bus i2c adapter "ddc"
From: Ville Syrjälä
Rename the various names we've used for the DDC bus
i2c adapter ("i2c", "adapter", etc.) to just "ddc".
This differentiates it from the various other i2c
busses we might have (DSI panel stuff, DVO control bus, etc.).
v2: Don't add a bogus drm_get_edid() call (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_connector.c| 6 +--
.../gpu/drm/i915/display/intel_connector.h| 2 +-
drivers/gpu/drm/i915/display/intel_crt.c | 32 ++--
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 51 ---
drivers/gpu/drm/i915/display/intel_lspcon.c | 14 ++---
6 files changed, 51 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index ff3bcadebe59..c65887870ddc 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -192,17 +192,17 @@ int intel_connector_update_modes(struct drm_connector
*connector,
/**
* intel_ddc_get_modes - get modelist from monitor
* @connector: DRM connector device to use
- * @adapter: i2c adapter
+ * @ddc: DDC bus i2c adapter
*
* Fetch the EDID information from @connector using the DDC bus.
*/
int intel_ddc_get_modes(struct drm_connector *connector,
- struct i2c_adapter *adapter)
+ struct i2c_adapter *ddc)
{
const struct drm_edid *drm_edid;
int ret;
- drm_edid = drm_edid_read_ddc(connector, adapter);
+ drm_edid = drm_edid_read_ddc(connector, ddc);
if (!drm_edid)
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h
b/drivers/gpu/drm/i915/display/intel_connector.h
index aaf7281462dc..bafde3f11ff4 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -26,7 +26,7 @@ bool intel_connector_get_hw_state(struct intel_connector
*connector);
enum pipe intel_connector_get_pipe(struct intel_connector *connector);
int intel_connector_update_modes(struct drm_connector *connector,
const struct drm_edid *drm_edid);
-int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
+int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *ddc);
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index f66340b4caf0..8145511bd5c3 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -610,18 +610,18 @@ static bool intel_crt_detect_hotplug(struct drm_connector
*connector)
}
static const struct drm_edid *intel_crt_get_edid(struct drm_connector
*connector,
-struct i2c_adapter *i2c)
+struct i2c_adapter *ddc)
{
const struct drm_edid *drm_edid;
- drm_edid = drm_edid_read_ddc(connector, i2c);
+ drm_edid = drm_edid_read_ddc(connector, ddc);
- if (!drm_edid && !intel_gmbus_is_forced_bit(i2c)) {
+ if (!drm_edid && !intel_gmbus_is_forced_bit(ddc)) {
drm_dbg_kms(connector->dev,
"CRT GMBUS EDID read failed, retry using GPIO
bit-banging\n");
- intel_gmbus_force_bit(i2c, true);
- drm_edid = drm_edid_read_ddc(connector, i2c);
- intel_gmbus_force_bit(i2c, false);
+ intel_gmbus_force_bit(ddc, true);
+ drm_edid = drm_edid_read_ddc(connector, ddc);
+ intel_gmbus_force_bit(ddc, false);
}
return drm_edid;
@@ -629,12 +629,12 @@ static const struct drm_edid *intel_crt_get_edid(struct
drm_connector *connector
/* local version of intel_ddc_get_modes() to use intel_crt_get_edid() */
static int intel_crt_ddc_get_modes(struct drm_connector *connector,
- struct i2c_adapter *adapter)
+ struct i2c_adapter *ddc)
{
const struct drm_edid *drm_edid;
int ret;
- drm_edid = intel_crt_get_edid(connector, adapter);
+ drm_edid = intel_crt_get_edid(connector, ddc);
if (!drm_edid)
return 0;
@@ -650,11 +650,11 @@ static bool intel_crt_detect_ddc(struct drm_connector
*connector)
struct intel_crt *crt =
intel_attached_crt(to_intel_connector(connector));
struct drm_i915_private *dev_priv = to_i915(crt->base.base.dev);
const struct drm_edid *drm_edid;
- struct i2c_adapter *i2c;
+ struct i2c_adapter *ddc;
bool ret = false;
- i2c = intel_gmbu
Re: [Intel-gfx] [PATCH 11/12] drm/i915/hdmi: Remove old i2c symlink
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the i915 specific i2c-N symlink from HDMI connectors.
> This was added to sort of mirror the DP connectors that alreayd
> had their aux ch based i2c adapter sitting beneath them in the
> sysfs hierarchy. But now that we have the standard "ddc" symlink
> approach provided by the core let's switch to that fully.
> I don't think anything beyond igt depends on this.
I hope nobody notices or cares. I see that you've already fixed igt to
prefer ddc.
Reviewed-by: Jani Nikula
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 25 ---
> 1 file changed, 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 6b8754290304..e9dcd3d5f6e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2544,28 +2544,6 @@ static int intel_hdmi_get_modes(struct drm_connector
> *connector)
> return drm_edid_connector_add_modes(connector);
> }
>
> -static void intel_hdmi_create_i2c_symlink(struct drm_connector *connector)
> -{
> - struct drm_i915_private *i915 = to_i915(connector->dev);
> - struct i2c_adapter *ddc = connector->ddc;
> - struct kobject *i2c_kobj = &ddc->dev.kobj;
> - struct kobject *connector_kobj = &connector->kdev->kobj;
> - int ret;
> -
> - ret = sysfs_create_link(connector_kobj, i2c_kobj, i2c_kobj->name);
> - if (ret)
> - drm_err(&i915->drm, "Failed to create i2c symlink (%d)\n", ret);
> -}
> -
> -static void intel_hdmi_remove_i2c_symlink(struct drm_connector *connector)
> -{
> - struct i2c_adapter *ddc = connector->ddc;
> - struct kobject *i2c_kobj = &ddc->dev.kobj;
> - struct kobject *connector_kobj = &connector->kdev->kobj;
> -
> - sysfs_remove_link(connector_kobj, i2c_kobj->name);
> -}
> -
> static int
> intel_hdmi_connector_register(struct drm_connector *connector)
> {
> @@ -2575,8 +2553,6 @@ intel_hdmi_connector_register(struct drm_connector
> *connector)
> if (ret)
> return ret;
>
> - intel_hdmi_create_i2c_symlink(connector);
> -
> return ret;
> }
>
> @@ -2586,7 +2562,6 @@ static void intel_hdmi_connector_unregister(struct
> drm_connector *connector)
>
> cec_notifier_conn_unregister(n);
>
> - intel_hdmi_remove_i2c_symlink(connector);
> intel_connector_unregister(connector);
> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 10/12] drm/i915/hdmi: Nuke hdmi->ddc_bus
On Tue, 29 Aug 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the mostly redundant hdmi->ddc_bus. The only thing that needs
> it anymore is get_encoder_by_ddc_bus(), but that can be replaced with
> a slight detour through attached_connector+intel_gmbus_get_adapter().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 -
> drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index c62f4ec315e8..363b6573a5f9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1581,7 +1581,6 @@ struct intel_watermark_params {
>
> struct intel_hdmi {
> i915_reg_t hdmi_reg;
> - int ddc_bus;
> struct {
> enum drm_dp_dual_mode_type type;
> int max_tmds_clock;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index efa9bb93cfb1..6b8754290304 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2900,13 +2900,17 @@ get_encoder_by_ddc_pin(struct intel_encoder *encoder,
> u8 ddc_pin)
> struct intel_encoder *other;
>
> for_each_intel_encoder(&i915->drm, other) {
> + struct intel_connector *connector;
> +
> if (other == encoder)
> continue;
>
> if (!intel_encoder_is_dig_port(other))
> continue;
>
> - if (enc_to_dig_port(other)->hdmi.ddc_bus == ddc_pin)
> + connector = enc_to_dig_port(other)->hdmi.attached_connector;
> +
> + if (connector && connector->base.ddc ==
> intel_gmbus_get_adapter(i915, ddc_pin))
> return other;
> }
>
> @@ -3000,6 +3004,7 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *dig_port,
> struct drm_i915_private *dev_priv = to_i915(dev);
> enum port port = intel_encoder->port;
> struct cec_connector_info conn_info;
> + u8 ddc_pin;
>
> drm_dbg_kms(&dev_priv->drm,
> "Adding HDMI connector on [ENCODER:%d:%s]\n",
> @@ -3014,14 +3019,14 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *dig_port,
>intel_encoder->base.name))
> return;
>
> - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(intel_encoder);
> - if (!intel_hdmi->ddc_bus)
> + ddc_pin = intel_hdmi_ddc_pin(intel_encoder);
> + if (!ddc_pin)
> return;
>
> drm_connector_init_with_ddc(dev, connector,
> &intel_hdmi_connector_funcs,
> DRM_MODE_CONNECTOR_HDMIA,
> - intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus));
> + intel_gmbus_get_adapter(dev_priv, ddc_pin));
>
> drm_connector_helper_add(connector, &intel_hdmi_connector_helper_funcs);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout threshold
> -Original Message-
> From: Sousa, Gustavo
> Sent: Wednesday, August 30, 2023 3:19 PM
> To: Kahola, Mika ; Sripada, Radhakrishna
> ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus
> timeout threshold
>
> Quoting Gustavo Sousa (2023-08-29 08:45:41-03:00)
> >Quoting Kahola, Mika (2023-08-29 06:35:17-03:00)
> >>> -Original Message-
> >>> From: Intel-gfx On Behalf
> >>> Of Sripada, Radhakrishna
> >>> Sent: Tuesday, August 29, 2023 1:54 AM
> >>> To: Sousa, Gustavo ;
> >>> intel-gfx@lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase
> >>> msgbus timeout threshold
> >>>
> >>> Hi Gustavo,
> >>>
> >>> > -Original Message-
> >>> > From: Sousa, Gustavo
> >>> > Sent: Monday, August 28, 2023 2:46 PM
> >>> > To: Sripada, Radhakrishna ; intel-
> >>> > g...@lists.freedesktop.org
> >>> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase
> >>> > msgbus timeout threshold
> >>> >
> >>> > Quoting Sripada, Radhakrishna (2023-08-28 17:30:19-03:00)
> >>> > >Hi Gustavo,
> >>> >
> >>> > Hi, RK.
> >>> >
> >>> > Thanks for the feedback! Please, see my replies below.
> >>> >
> >>> > >
> >>> > >> -Original Message-
> >>> > >> From: Intel-gfx On
> >>> > >> Behalf Of
> >>> > Gustavo
> >>> > >> Sousa
> >>> > >> Sent: Monday, August 28, 2023 10:34 AM
> >>> > >> To: intel-gfx@lists.freedesktop.org
> >>> > >> Subject: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase
> >>> > >> msgbus
> >>> > timeout
> >>> > >> threshold
> >>> > >>
> >>> > >> We have experienced timeout issues when accessing C20 SRAM registers.
> >>> > >This wording is misleading. It seems to imply that we directly
> >>> > >access SRAM registers via msg bus but the reads/writes go through
> >>> > >intermediate registers and it is this read/write that is failing.
> >>> > >Adding extra clarity here would be helpful.
> >>> >
> >>> > Hm... Okay. I thought that would already be implied to someone
> >>> > familiar with the code. What about:
> >>> >
> >>> > s/when accessing/when going through the sequence to access/
> >>> This is better to indicate that it is not direct access.
> >>>
> >>> >
> >>> > ?
> >>> >
> >>> > >
> >>> > >> Experimentation showed that bumping the message bus timer
> >>> > >> threshold helped on getting display Type-C connection on the C20 PHY
> >>> > >> to work.
> >>> > >>
> >>> > >> While the timeout is still under investigation with the HW
> >>> > >> team, having logic to allow forward progress (with the proper
> >>> > >> warnings) seems useful.
> >>> > >> Thus, let's bump the threshold when a timeout is detected.
> >>> > >>
> >>> > >> The maximum value of 0x200 pclk cycles was somewhat arbitrary -
> >>> > >> 2x the default value. That value was successfully tested on
> >>> > >> real hardware that was displaying timeouts otherwise.
> >>> > >>
> >>> > >> BSpec: 65156
> >>> > >> Signed-off-by: Gustavo Sousa
> >>> > >> ---
> >>> > >> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 41
> >>> > >> +++
> >>> > >> +++ .../gpu/drm/i915/display/intel_cx0_phy_regs
> >>> > >> +++ .h
> >>> > >> | 12 ++
> >>> > >> 2 files changed, 53 insertions(+)
> >>> > >>
> >>> > >> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >>> > >> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >>> > >> index dd489b50ad60..55d2333032e3 100644
> >>> > >> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >>> > >> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >>> > >> @@ -5,6 +5,7 @@
> >>> > >>
> >>> > >> #include
> >>> > >> #include
> >>> > >> +#include
> >>> > >> #include "i915_reg.h"
> >>> > >> #include "intel_cx0_phy.h"
> >>> > >> #include "intel_cx0_phy_regs.h"
> >>> > >> @@ -29,6 +30,8 @@
> >>> > >> #define INTEL_CX0_LANE1BIT(1)
> >>> > >> #define INTEL_CX0_BOTH_LANES(INTEL_CX0_LANE1 |
> >>> > >> INTEL_CX0_LANE0)
> >>> > >>
> >>> > >> +#define INTEL_CX0_MSGBUS_TIMER_VAL_MAX0x200
> >>> > >> +
> >>> > >> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy
> >>> > >> phy) {
> >>> > >> if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy <
> >>> > >> PHY_C) @@ -119,6 +122,43 @@ static void
> >>> > >> intel_cx0_bus_reset(struct
> >>> > drm_i915_private
> >>> > >> *i915, enum port port, i
> >>> > >> intel_clear_response_ready_flag(i915, port, lane); }
> >>> > >>
> >>> > >> +/*
> >>> > >> + * Check if there was a timeout detected by the hardware in
> >>> > >> +the message bus
> >>> > >> + * and bump the threshold if so.
> >>
> >>Just a thought but wouldn't it be simpler if we just set the timeout to
> >>it's maximum and discard the check here?
> >
> >I'm not sure which exactly check you are talking about here:
> >
> > 1) The check on the XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT.
> >
> > I think this could give us useful debugging info, for example, if our
> > code
> > thinks the
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dp: Drop redundant AUX power get/put in intel_dp_force()
On Wed, Aug 30, 2023 at 05:29:09PM -0400, Rodrigo Vivi wrote: > On Wed, Aug 30, 2023 at 05:04:20PM +0300, Imre Deak wrote: > > intel_dp_force() takes the AUX power reference as required by the DP AUX > > transactions in intel_dp_set_edid(). However the low level AUX handler > > you mean intel_dp_aux_xfer right? Yes, intel_dp_set_edid() -> intel_dp_aux_xfer(), the same way as in intel_dp_detect(). > > takes this reference already so the get/put in intel_dp_force() can be > > dropped. This also fixes a problem where the TC port mode changed while > > the AUX power well was enabled. > > > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8779 > > Signed-off-by: Imre Deak > > It makes sense to get that in lower levels, so > > Reviewed-by: Rodrigo Vivi Thanks, I pushed the patches. > > --- > > drivers/gpu/drm/i915/display/intel_dp.c | 7 --- > > 1 file changed, 7 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > > b/drivers/gpu/drm/i915/display/intel_dp.c > > index 9d303caf969e0..16fb12d187a29 100644 > > --- a/drivers/gpu/drm/i915/display/intel_dp.c > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > > @@ -5365,9 +5365,6 @@ intel_dp_force(struct drm_connector *connector) > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > > struct intel_encoder *intel_encoder = &dig_port->base; > > struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev); > > - enum intel_display_power_domain aux_domain = > > - intel_aux_power_domain(dig_port); > > - intel_wakeref_t wakeref; > > > > drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s]\n", > > connector->base.id, connector->name); > > @@ -5376,11 +5373,7 @@ intel_dp_force(struct drm_connector *connector) > > if (connector->status != connector_status_connected) > > return; > > > > - wakeref = intel_display_power_get(dev_priv, aux_domain); > > - > > intel_dp_set_edid(intel_dp); > > - > > - intel_display_power_put(dev_priv, aux_domain, wakeref); > > } > > > > static int intel_dp_get_modes(struct drm_connector *connector) > > -- > > 2.37.2 > >
