[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Store DSC DPCD capabilities in the connector (rev9)
== Series Details == Series: drm/i915: Store DSC DPCD capabilities in the connector (rev9) URL : https://patchwork.freedesktop.org/series/124723/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13751_full -> Patchwork_124723v9_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_124723v9_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_124723v9_full, please notify your bug team (lgci.bug.fil...@intel.com) to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_124723v9_full: ### IGT changes ### Possible regressions * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1: - shard-apl: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-apl6/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html Known issues Here are the changes found in Patchwork_124723v9_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_fdinfo@virtual-busy: - shard-mtlp: NOTRUN -> [SKIP][2] ([i915#8414]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-mtlp-8/igt@drm_fdi...@virtual-busy.html * igt@gem_ccs@block-copy-compressed: - shard-mtlp: NOTRUN -> [SKIP][3] ([i915#3555]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-mtlp-2/igt@gem_...@block-copy-compressed.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-rkl: [PASS][4] -> [FAIL][5] ([i915#6268]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13751/shard-rkl-3/igt@gem_ctx_e...@basic-nohangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-rkl-2/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_freq@sysfs@gt0: - shard-dg2: NOTRUN -> [FAIL][6] ([i915#6786]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-dg2-7/igt@gem_ctx_freq@sy...@gt0.html * igt@gem_ctx_persistence@heartbeat-hang: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#8555]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-dg2-11/igt@gem_ctx_persiste...@heartbeat-hang.html * igt@gem_exec_balancer@bonded-dual: - shard-mtlp: NOTRUN -> [SKIP][8] ([i915#4771]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-mtlp-2/igt@gem_exec_balan...@bonded-dual.html * igt@gem_exec_balancer@bonded-true-hang: - shard-dg2: NOTRUN -> [SKIP][9] ([i915#4812]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-dg2-11/igt@gem_exec_balan...@bonded-true-hang.html * igt@gem_exec_balancer@noheartbeat: - shard-mtlp: NOTRUN -> [SKIP][10] ([i915#8555]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-mtlp-8/igt@gem_exec_balan...@noheartbeat.html * igt@gem_exec_capture@capture-invisible@lmem0: - shard-dg2: NOTRUN -> [SKIP][11] ([i915#6334]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-dg2-11/igt@gem_exec_capture@capture-invisi...@lmem0.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglu: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13751/shard-tglu-2/igt@gem_exec_fair@basic-f...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-tglu-2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-sync: - shard-dg2: NOTRUN -> [SKIP][14] ([i915#3539]) +2 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-dg2-7/igt@gem_exec_f...@basic-sync.html * igt@gem_exec_fence@submit67: - shard-mtlp: NOTRUN -> [SKIP][15] ([i915#4812]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-mtlp-8/igt@gem_exec_fe...@submit67.html * igt@gem_exec_flush@basic-uc-ro-default: - shard-dg2: NOTRUN -> [SKIP][16] ([i915#3539] / [i915#4852]) +1 other test skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-dg2-7/igt@gem_exec_fl...@basic-uc-ro-default.html * igt@gem_exec_reloc@basic-cpu-wc-active: - shard-mtlp: NOTRUN -> [SKIP][17] ([i915#3281]) +8 other tests skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124723v9/shard-mtlp-2/igt@gem_exec_re...@basic-cpu-wc-active.html * igt@gem_exec_reloc@basic-wc-cpu-active: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#3281]) +1 other test skip [18]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: make some error capture functions static (rev2)
== Series Details == Series: series starting with [1/3] drm/i915: make some error capture functions static (rev2) URL : https://patchwork.freedesktop.org/series/124993/ State : success == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_124993v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts New tests - New tests have been introduced between CI_DRM_13749_full and Patchwork_124993v2_full: ### New IGT tests (1) ### * igt@kms_content_protection@atomic@pipe-a-dp-4: - Statuses : 1 timeout(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_124993v2_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [FAIL][11], [PASS][12], [FAIL][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]) ([i915#8293]) -> ([PASS][26], [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]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk3/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk4/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk4/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk4/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124993v2/shard-glk6/boot.html [40]:
[Intel-gfx] ✓ Fi.CI.BAT: success for Resolve suspend-resume racing with GuC destroy-context-worker (rev5)
== Series Details ==
Series: Resolve suspend-resume racing with GuC destroy-context-worker (rev5)
URL : https://patchwork.freedesktop.org/series/121916/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13754 -> Patchwork_121916v5
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/index.html
Participating hosts (38 -> 36)
--
Additional (1): fi-kbl-soraka
Missing(3): bat-dg2-9 fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_121916v5 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-6: NOTRUN -> [SKIP][1] ([i915#9318])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html
* igt@gem_exec_suspend@basic-s3@smem:
- bat-mtlp-8: [PASS][2] -> [ABORT][3] ([i915#8213] / [i915#9262])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.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_121916v5/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
other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- bat-adlp-6: NOTRUN -> [SKIP][6] ([i915#3282])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/bat-adlp-6/igt@gem_tiled_pread_basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-6: NOTRUN -> [SKIP][8] ([i915#4103] / [i915#5608]) +1
other test skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_dsc@dsc-basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271]) +9 other tests skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/fi-kbl-soraka/igt@kms_...@dsc-basic.html
- bat-adlp-6: NOTRUN -> [SKIP][10] ([i915#3555] / [i915#3840])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/bat-adlp-6/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-6: NOTRUN -> [SKIP][11] ([fdo#109285])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html
Possible fixes
* igt@i915_module_load@load:
- bat-adlp-6: [INCOMPLETE][12] ([i915#8449]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-adlp-6/igt@i915_module_l...@load.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v5/bat-adlp-6/igt@i915_module_l...@load.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5608]: https://gitlab.freedesktop.org/drm/intel/issues/5608
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#8213]: https://gitlab.freedesktop.org/drm/intel/issues/8213
[i915#8449]: https://gitlab.freedesktop.org/drm/intel/issues/8449
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8981]: https://gitlab.freedesktop.org/drm/intel/issues/8981
[i915#9262]: https://gitlab.freedesktop.org/drm/intel/issues/9262
[i915#9318]: https://gitlab.freedesktop.org/drm/intel/issues/9318
Build changes
-
* Linux: CI_DRM_13754 -> Patchwork_121916v5
CI-20190529: 20190529
CI_DRM_13754: 3801f98312c4ae0e31edc6dc69eced1dabbcc694 @
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Resolve suspend-resume racing with GuC destroy-context-worker (rev5)
== Series Details == Series: Resolve suspend-resume racing with GuC destroy-context-worker (rev5) URL : https://patchwork.freedesktop.org/series/121916/ 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.IGT: failure for drm/i915: stop including i915_utils.h from intel_runtime_pm.h (rev2)
== Series Details == Series: drm/i915: stop including i915_utils.h from intel_runtime_pm.h (rev2) URL : https://patchwork.freedesktop.org/series/124989/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_124989v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_124989v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_124989v2_full, please notify your bug team (lgci.bug.fil...@intel.com) 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_124989v2/index.html Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_124989v2_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@reset: - shard-mtlp: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-mtlp-8/igt@i915_selftest@l...@reset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124989v2/shard-mtlp-5/igt@i915_selftest@l...@reset.html * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip: - shard-snb: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-snb2/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124989v2/shard-snb5/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1: - shard-apl: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-apl6/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124989v2/shard-apl4/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-dg1: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-dg1-13/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124989v2/shard-dg1-19/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html Known issues Here are the changes found in Patchwork_124989v2_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [FAIL][19], [PASS][20], [FAIL][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]) ([i915#8293]) -> ([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], [PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56], [PASS][57], [PASS][58]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk7/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk7/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk5/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk5/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [27]:
[Intel-gfx] [PATCH v5 2/3] drm/i915/guc: Close deregister-context race against CT-loss
If we are at the end of suspend or very early in resume
its possible an async fence signal (via rcu_call) is triggered
to free_engines which could lead us to the execution of
the context destruction worker (after a prior worker flush).
Thus, when suspending, insert rcu_barriers at the start
of i915_gem_suspend (part of driver's suspend prepare) and
again in i915_gem_suspend_late so that all such cases have
completed and context destruction list isn't missing anything.
In destroyed_worker_func, close the race against CT-loss
by checking that CT is enabled before calling into
deregister_destroyed_contexts.
Based on testing, guc_lrc_desc_unpin may still race and fail
as we traverse the GuC's context-destroy list because the
CT could be disabled right before calling GuC's CT send function.
We've witnessed this race condition once every ~6000-8000
suspend-resume cycles while ensuring workloads that render
something onscreen is continuously started just before
we suspend (and the workload is small enough to complete
and trigger the queued engine/context free-up either very
late in suspend or very early in resume).
In such a case, we need to unroll the entire process because
guc-lrc-unpin takes a gt wakeref which only gets released in
the G2H IRQ reply that never comes through in this corner
case. Without the unroll, the taken wakeref is leaked and will
cascade into a kernel hang later at the tail end of suspend in
this function:
intel_wakeref_wait_for_idle(>wakeref)
(called by) - intel_gt_pm_wait_for_idle
(called by) - wait_for_suspend
Thus, do an unroll in guc_lrc_desc_unpin and deregister_destroyed_-
contexts if guc_lrc_desc_unpin fails due to CT send falure.
When unrolling, keep the context in the GuC's destroy-list so
it can get picked up on the next destroy worker invocation
(if suspend aborted) or get fully purged as part of a GuC
sanitization (end of suspend) or a reset flow.
Signed-off-by: Alan Previn
Signed-off-by: Anshuman Gupta
Tested-by: Mousumi Jana
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ---
2 files changed, 80 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 0d812f4d787d..3b27218aabe2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -28,6 +28,13 @@ void i915_gem_suspend(struct drm_i915_private *i915)
GEM_TRACE("%s\n", dev_name(i915->drm.dev));
intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
+ /*
+* On rare occasions, we've observed the fence completion triggers
+* free_engines asynchronously via rcu_call. Ensure those are done.
+* This path is only called on suspend, so it's an acceptable cost.
+*/
+ rcu_barrier();
+
flush_workqueue(i915->wq);
/*
@@ -160,6 +167,9 @@ void i915_gem_suspend_late(struct drm_i915_private *i915)
* machine in an unusable condition.
*/
+ /* Like i915_gem_suspend, flush tasks staged from fence triggers */
+ rcu_barrier();
+
for_each_gt(gt, i915, i)
intel_gt_suspend_late(gt);
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 a5b68f77e494..9806b33c8561 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -235,6 +235,13 @@ set_context_destroyed(struct intel_context *ce)
ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
}
+static inline void
+clr_context_destroyed(struct intel_context *ce)
+{
+ lockdep_assert_held(>guc_state.lock);
+ ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED;
+}
+
static inline bool context_pending_disable(struct intel_context *ce)
{
return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
@@ -612,6 +619,8 @@ static int guc_submission_send_busy_loop(struct intel_guc
*guc,
u32 g2h_len_dw,
bool loop)
{
+ int ret;
+
/*
* We always loop when a send requires a reply (i.e. g2h_len_dw > 0),
* so we don't handle the case where we don't get a reply because we
@@ -622,7 +631,11 @@ static int guc_submission_send_busy_loop(struct intel_guc
*guc,
if (g2h_len_dw)
atomic_inc(>outstanding_submission_g2h);
- return intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
+ ret = intel_guc_send_busy_loop(guc, action, len, g2h_len_dw, loop);
+ if (ret)
+ atomic_dec(>outstanding_submission_g2h);
+
+ return ret;
}
int intel_guc_wait_for_pending_msg(struct intel_guc *guc,
@@ -3205,12 +3218,13 @@ static void guc_context_close(struct intel_context *ce)
spin_unlock_irqrestore(>guc_state.lock, flags);
}
-static inline
[Intel-gfx] [PATCH v5 0/3] Resolve suspend-resume racing with GuC destroy-context-worker
This series is the result of debugging issues root caused to races between the GuC's destroyed_worker_func being triggered vs repeating suspend-resume cycles with concurrent delayed fence signals for engine-freeing. The reproduction steps require that an app is launched right before the start of the suspend cycle where it creates a new gem context and submits a tiny workload that would complete in the middle of the suspend cycle. However this app uses dma-buffer sharing or dma-fence with non-GPU objects or signals that eventually triggers a FENCE_FREE via__i915_sw_fence_notify that connects to engines_notify -> free_engines_rcu -> intel_context_put -> kref_put(>ref..) that queues the worker after the GuCs CTB has been disabled (i.e. after i915-gem's suspend-late). This sequence is a corner-case and required repeating this app->suspend->resume cycle ~1500 times across 4 identical systems to see it once. That said, based on above callstack, it is clear that merely flushing the context destruction worker, which is obviously missing and needed, isn't sufficient. Because of that, this series adds additional patches besides the obvious (Patch #1) flushing of the worker during the suspend flows. It also includes (Patch #2) closing a race between sending the context-deregistration H2G vs the CTB getting disabled in the midst of it (by detecing the failure and unrolling the guc-lrc-unpin flow) and (Patch #32) not infinitely waiting in intel_gt_pm_wait_timeout_for_idle when in the suspend-flow. NOTE: We are still observing one more wakeref leak from gt but not necessarilty guc. We are still debugging this so this series will very likely get rev'd up again. Changes from prior revs: v4: - In Patch #2, change the position of the calls into rcu_barrier based on latest testing data. (Alan/Anshuman). - In Patch #3, fix the timeout value selection for the final gt-pm idle-wait that was incorrectly using a 'ns' #define as a milisec timeout. v3: - In Patch #3, when deregister_context fails, instead of calling intel_gt_pm_put(that might sleep), call __intel_wakeref_put (without ASYNC flag) (Rodrigo/Anshuman). - In wait_for_suspend add an rcu_barrier before we proceed to wait for idle. (Anshuman) v2: - Patch #2 Restructure code in guc_lrc_desc_unpin so it's more readible to differentiate (1)direct guc-id cleanup ..vs (2) sending the H2G ctx-destroy action .. vs (3) the unrolling steps if the H2G fails. - Patch #2 Add a check to close the race sooner by checking for intel_guc_is_ready from destroyed_worker_func. - Patch #2 When guc_submission_send_busy_loop gets a failure from intel_guc_send_busy_loop, we need to undo i.e. decrement the outstanding_submission_g2h. - Patch #3 In wait_for_suspend, fix checking of return from intel_gt_pm_wait_timeout_for_idle to now use -ETIMEDOUT and add documentation for intel_wakeref_wait_for_idle. (Rodrigo). Alan Previn (3): drm/i915/guc: Flush context destruction worker at suspend drm/i915/guc: Close deregister-context race against CT-loss drm/i915/gt: Timeout when waiting for idle in suspending drivers/gpu/drm/i915/gem/i915_gem_pm.c| 10 +++ drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 7 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 7 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 86 --- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 + drivers/gpu/drm/i915/intel_wakeref.c | 14 ++- drivers/gpu/drm/i915/intel_wakeref.h | 6 +- 9 files changed, 116 insertions(+), 20 deletions(-) base-commit: 13e6d61391ba3da0e26ce5c788d1fe26e036294c -- 2.39.0
[Intel-gfx] [PATCH v5 1/3] drm/i915/guc: Flush context destruction worker at suspend
When suspending, flush the context-guc-id
deregistration worker at the final stages of
intel_gt_suspend_late when we finally call gt_sanitize
that eventually leads down to __uc_sanitize so that
the deregistration worker doesn't fire off later as
we reset the GuC microcontroller.
Signed-off-by: Alan Previn
Reviewed-by: Rodrigo Vivi
Tested-by: Mousumi Jana
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 2 ++
3 files changed, 9 insertions(+)
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 2cce5ec1ff00..a5b68f77e494 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1610,6 +1610,11 @@ static void guc_flush_submissions(struct intel_guc *guc)
spin_unlock_irqrestore(_engine->lock, flags);
}
+void intel_guc_submission_flush_work(struct intel_guc *guc)
+{
+ flush_work(>submission_state.destroyed_worker);
+}
+
static void guc_flush_destroyed_contexts(struct intel_guc *guc);
void intel_guc_submission_reset_prepare(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index c57b29cdb1a6..b6df75622d3b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -38,6 +38,8 @@ int intel_guc_wait_for_pending_msg(struct intel_guc *guc,
bool interruptible,
long timeout);
+void intel_guc_submission_flush_work(struct intel_guc *guc);
+
static inline bool intel_guc_submission_is_supported(struct intel_guc *guc)
{
return guc->submission_supported;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 98b103375b7a..eb3554cb5ea4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -693,6 +693,8 @@ void intel_uc_suspend(struct intel_uc *uc)
return;
}
+ intel_guc_submission_flush_work(guc);
+
with_intel_runtime_pm(_to_gt(uc)->i915->runtime_pm, wakeref) {
err = intel_guc_suspend(guc);
if (err)
--
2.39.0
[Intel-gfx] [PATCH v5 3/3] drm/i915/gt: Timeout when waiting for idle in suspending
When suspending, add a timeout when calling
intel_gt_pm_wait_for_idle else if we have a lost
G2H event that holds a wakeref (which would be
indicative of a bug elsewhere in the driver),
driver will at least complete the suspend-resume
cycle, (albeit not hitting all the targets for
low power hw counters), instead of hanging in the kernel.
Signed-off-by: Alan Previn
Reviewed-by: Rodrigo Vivi
Tested-by: Mousumi Jana
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 7 ++-
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 7 ++-
drivers/gpu/drm/i915/intel_wakeref.c | 14 ++
drivers/gpu/drm/i915/intel_wakeref.h | 6 --
5 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 179d9546865b..4b45a8f7fe5a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -686,7 +686,7 @@ void intel_engines_release(struct intel_gt *gt)
if (!engine->release)
continue;
- intel_wakeref_wait_for_idle(>wakeref);
+ intel_wakeref_wait_for_idle(>wakeref, 0);
GEM_BUG_ON(intel_engine_pm_is_awake(engine));
engine->release(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index f5899d503e23..25cb39ba9fdf 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -306,6 +306,8 @@ int intel_gt_resume(struct intel_gt *gt)
static void wait_for_suspend(struct intel_gt *gt)
{
+ int final_timeout_ms = (I915_GT_SUSPEND_IDLE_TIMEOUT * 10);
+
if (!intel_gt_pm_is_awake(gt))
return;
@@ -318,7 +320,10 @@ static void wait_for_suspend(struct intel_gt *gt)
intel_gt_retire_requests(gt);
}
- intel_gt_pm_wait_for_idle(gt);
+ /* we are suspending, so we shouldn't be waiting forever */
+ if (intel_gt_pm_wait_timeout_for_idle(gt, final_timeout_ms) ==
-ETIMEDOUT)
+ gt_warn(gt, "bailing from %s after %d milisec timeout\n",
+ __func__, final_timeout_ms);
}
void intel_gt_suspend_prepare(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index b1eeb5b33918..1757ca4c3077 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -68,7 +68,12 @@ static inline void intel_gt_pm_might_put(struct intel_gt *gt)
static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
{
- return intel_wakeref_wait_for_idle(>wakeref);
+ return intel_wakeref_wait_for_idle(>wakeref, 0);
+}
+
+static inline int intel_gt_pm_wait_timeout_for_idle(struct intel_gt *gt, int
timeout_ms)
+{
+ return intel_wakeref_wait_for_idle(>wakeref, timeout_ms);
}
void intel_gt_pm_init_early(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/intel_wakeref.c
b/drivers/gpu/drm/i915/intel_wakeref.c
index 623a69089386..f2611c65246b 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -113,14 +113,20 @@ void __intel_wakeref_init(struct intel_wakeref *wf,
"wakeref.work", >work, 0);
}
-int intel_wakeref_wait_for_idle(struct intel_wakeref *wf)
+int intel_wakeref_wait_for_idle(struct intel_wakeref *wf, int timeout_ms)
{
- int err;
+ int err = 0;
might_sleep();
- err = wait_var_event_killable(>wakeref,
- !intel_wakeref_is_active(wf));
+ if (!timeout_ms)
+ err = wait_var_event_killable(>wakeref,
+ !intel_wakeref_is_active(wf));
+ else if (wait_var_event_timeout(>wakeref,
+ !intel_wakeref_is_active(wf),
+ msecs_to_jiffies(timeout_ms)) < 1)
+ err = -ETIMEDOUT;
+
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/intel_wakeref.h
b/drivers/gpu/drm/i915/intel_wakeref.h
index ec881b097368..302694a780d2 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.h
+++ b/drivers/gpu/drm/i915/intel_wakeref.h
@@ -251,15 +251,17 @@ __intel_wakeref_defer_park(struct intel_wakeref *wf)
/**
* intel_wakeref_wait_for_idle: Wait until the wakeref is idle
* @wf: the wakeref
+ * @timeout_ms: Timeout in ms, 0 means never timeout.
*
* Wait for the earlier asynchronous release of the wakeref. Note
* this will wait for any third party as well, so make sure you only wait
* when you have control over the wakeref and trust no one else is acquiring
* it.
*
- * Return: 0 on success, error code if killed.
+ * Returns 0 on success, -ETIMEDOUT upon a timeout, or the unlikely
+ * error propagation from wait_var_event_killable if timeout_ms is 0.
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3)
== Series Details == Series: fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3) URL : https://patchwork.freedesktop.org/series/125063/ 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 fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3)
== Series Details ==
Series: fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3)
URL : https://patchwork.freedesktop.org/series/125063/
State : warning
== Summary ==
Error: dim checkpatch failed
df3a4914f745 test-dyndbg: fixup CLASSMAP usage error
c097f28a3829 dyndbg: reword "class unknown, " to "class:_UNKNOWN_"
33ca08f3314b dyndbg: make ddebug_class_param union members same size
69bab57255ad dyndbg: replace classmap list with a vector
b225d958132b dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
e3a881f9de6d dyndbg: split param_set_dyndbg_classes to module/wrapper fns
435b8a49034f dyndbg: drop NUM_TYPE_ARRAY
63eed7f0611a dyndbg: reduce verbose/debug clutter
bb69bc12e6d1 dyndbg: silence debugs with no-change updates
2899baeed672 dyndbg: tighten ddebug_class_name() 1st arg type
9da2adc44b68 dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
a5ddc635a9b3 dyndbg: reduce verbose=3 messages in ddebug_add_module
5dd696ea1ec3 dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
be64775bdd73 dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:451: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_var' - possible
side-effects?
#451: FILE: include/linux/dynamic_debug.h:121:
+#define DYNDBG_CLASSMAP_USE_(_var, _uname) \
+ extern struct ddebug_class_map _var;\
+ static struct ddebug_class_user __aligned(8) __used \
+ __section("__dyndbg_class_users") _uname = {\
+ .user_mod_name = KBUILD_MODNAME,\
+ .map = &_var, \
}
-:771: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#771: FILE: lib/dynamic_debug.c:1254:
+ for (i = 0, cli = di->class_users; i < di->num_class_users; i++, cli++)
{
+
-:776: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#776: FILE: lib/dynamic_debug.c:1259:
+ if (!strcmp(cli->user_mod_name, dt->mod_name)) {
+
-:877: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'base' may be better as
'(base)' to avoid precedence issues
#877: FILE: lib/test_dynamic_debug.c:36:
+#define CLASSMAP_BITMASK(width, base) (((1UL << (width)) - 1) << base)
-:1010: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#1010:
new file mode 100644
total: 0 errors, 1 warnings, 4 checks, 756 lines checked
7eb2b750e277 dyndbg: add for_each_boxed_vector
-:19: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_box' - possible
side-effects?
#19: FILE: lib/dynamic_debug.c:161:
+#define for_each_boxed_vector(_box, _vec, _len, _ct, _curs)\
+ for (_ct = 0, _curs = (_box)->_vec; _ct < (_box)->_len; _ct++, _curs++)
-:19: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '_vec' may be better as
'(_vec)' to avoid precedence issues
#19: FILE: lib/dynamic_debug.c:161:
+#define for_each_boxed_vector(_box, _vec, _len, _ct, _curs)\
+ for (_ct = 0, _curs = (_box)->_vec; _ct < (_box)->_len; _ct++, _curs++)
-:19: CHECK:MACRO_ARG_PRECEDENCE: Macro argument '_len' may be better as
'(_len)' to avoid precedence issues
#19: FILE: lib/dynamic_debug.c:161:
+#define for_each_boxed_vector(_box, _vec, _len, _ct, _curs)\
+ for (_ct = 0, _curs = (_box)->_vec; _ct < (_box)->_len; _ct++, _curs++)
-:19: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_ct' - possible side-effects?
#19: FILE: lib/dynamic_debug.c:161:
+#define for_each_boxed_vector(_box, _vec, _len, _ct, _curs)\
+ for (_ct = 0, _curs = (_box)->_vec; _ct < (_box)->_len; _ct++, _curs++)
-:19: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_curs' - possible
side-effects?
#19: FILE: lib/dynamic_debug.c:161:
+#define for_each_boxed_vector(_box, _vec, _len, _ct, _curs)\
+ for (_ct = 0, _curs = (_box)->_vec; _ct < (_box)->_len; _ct++, _curs++)
total: 0 errors, 0 warnings, 5 checks, 71 lines checked
3d7f2809c9fb dyndbg: refactor ddebug_classparam_clamp_input
c82f3557a675 dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
0b7c1b3e7516 dyndbg-doc: add classmap info to howto
bbd018a63091 dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED
-:30: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#30: FILE: include/linux/dynamic_debug.h:41:
+#define _DPRINTK_FLAGS_PREFIX_CACHED (1<<7)
^
total: 0 errors, 0 warnings, 1 checks, 7 lines checked
539bac55d682 dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP
1a220d47995e dyndbg: refactor *dynamic_emit_prefix
7bd404363b52 dyndbg: change WARN_ON to WARN_ON_ONCE
4051b620245c drm: use correct ccflags-y spelling
8a5559e3aaf5 drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
18845430cd6a drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Temporarily force MTL into uncached mode (rev4)
== Series Details == Series: drm/i915/gt: Temporarily force MTL into uncached mode (rev4) URL : https://patchwork.freedesktop.org/series/124866/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_124866v4_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_124866v4_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_124866v4_full, please notify your bug team (lgci.bug.fil...@intel.com) 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_124866v4_full: ### IGT changes ### Possible regressions * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-rkl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-rkl-7/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124866v4/shard-rkl-2/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html Warnings * igt@device_reset@unbind-reset-rebind: - shard-dg1: [INCOMPLETE][3] ([i915#9408]) -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-dg1-15/igt@device_re...@unbind-reset-rebind.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124866v4/shard-dg1-13/igt@device_re...@unbind-reset-rebind.html Known issues Here are the changes found in Patchwork_124866v4_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [FAIL][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29]) ([i915#8293]) -> ([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], [PASS][52], [PASS][53], [PASS][54]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk9/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk8/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk3/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124866v4/shard-glk7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124866v4/shard-glk7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124866v4/shard-glk6/boot.html [33]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Define and use GuC and CTB TLB invalidation routines
== Series Details ==
Series: drm/i915: Define and use GuC and CTB TLB invalidation routines
URL : https://patchwork.freedesktop.org/series/125136/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125136v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/index.html
Participating hosts (38 -> 37)
--
Additional (2): fi-kbl-soraka fi-hsw-4770
Missing(3): bat-dg2-9 fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_125136v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-6: NOTRUN -> [SKIP][1] ([i915#9318])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/fi-hsw-4770/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- bat-adlp-6: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/bat-adlp-6/igt@gem_tiled_pread_basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-6: NOTRUN -> [SKIP][7] ([i915#4103] / [i915#5608]) +1
other test skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_dsc@dsc-basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271]) +9 other tests skip
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/fi-kbl-soraka/igt@kms_...@dsc-basic.html
- bat-adlp-6: NOTRUN -> [SKIP][9] ([i915#3555] / [i915#3840])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/bat-adlp-6/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-6: NOTRUN -> [SKIP][10] ([fdo#109285])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [PASS][11] -> [ABORT][12] ([i915#8668])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html
Possible fixes
* igt@i915_module_load@load:
- bat-adlp-6: [INCOMPLETE][13] ([i915#8449]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-adlp-6/igt@i915_module_l...@load.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/bat-adlp-6/igt@i915_module_l...@load.html
* igt@kms_hdmi_inject@inject-audio:
- fi-kbl-guc: [FAIL][15] ([IGT#3]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125136v1/fi-kbl-guc/igt@kms_hdmi_inj...@inject-audio.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#3]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/3
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5608]: https://gitlab.freedesktop.org/drm/intel/issues/5608
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Define and use GuC and CTB TLB invalidation routines
== Series Details == Series: drm/i915: Define and use GuC and CTB TLB invalidation routines URL : https://patchwork.freedesktop.org/series/125136/ 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: Define and use GuC and CTB TLB invalidation routines
== Series Details == Series: drm/i915: Define and use GuC and CTB TLB invalidation routines URL : https://patchwork.freedesktop.org/series/125136/ State : warning == Summary == Error: dim checkpatch failed 81011600b839 drm/i915: Add GuC TLB Invalidation device info flags 509d175695bb drm/i915/guc: Add CT size delay helper e96d0239cdfc drm/i915: Define and use GuC and CTB TLB invalidation routines -:284: WARNING:MISORDERED_TYPE: type 'long unsigned int' should be specified in [[un]signed] [short|int|long|long long] order #284: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1929: + long unsigned int i; -:284: WARNING:UNNECESSARY_INT: Prefer 'unsigned long' over 'long unsigned int' as the int is unnecessary #284: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1929: + long unsigned int i; -:447: WARNING:MEMORY_BARRIER: memory barrier without comment #447: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:4741: + smp_store_mb(wq_entry->flags, wq_entry->flags & ~WQ_FLAG_WOKEN); total: 0 errors, 3 warnings, 0 checks, 441 lines checked d162b69472b2 drm/i915: No TLB invalidation on suspended GT 356ec4813ecd drm/i915: No TLB invalidation on wedged GT 5ea00102c87e drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck -:32: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.rst #32: FILE: drivers/gpu/drm/i915/gt/selftest_tlb.c:146: + msleep(10); total: 0 errors, 1 warnings, 0 checks, 17 lines checked c611cb1d9fcc drm/i915: Enable GuC TLB invalidations for MTL
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DPLL code cleanups (rev2)
== Series Details == Series: drm/i915: DPLL code cleanups (rev2) URL : https://patchwork.freedesktop.org/series/125052/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125052v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/index.html Participating hosts (38 -> 38) -- Additional (2): fi-kbl-soraka fi-hsw-4770 Missing(2): fi-snb-2520m fi-bsw-n3050 Known issues Here are the changes found in Patchwork_125052v2 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-6: NOTRUN -> [SKIP][1] ([i915#9318]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 other tests skip [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - bat-adlp-6: NOTRUN -> [SKIP][4] ([i915#3282]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/bat-adlp-6/igt@gem_tiled_pread_basic.html * igt@i915_module_load@reload: - fi-kbl-soraka: NOTRUN -> [DMESG-WARN][5] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-kbl-soraka/igt@i915_module_l...@reload.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#5334] / [i915#7872]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [PASS][8] -> [ABORT][9] ([i915#9414]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@i915_selftest@l...@requests.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#5190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-6: NOTRUN -> [SKIP][11] ([i915#4103] / [i915#5608]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271]) +9 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-kbl-soraka/igt@kms_...@dsc-basic.html - bat-adlp-6: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#3840]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/bat-adlp-6/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-adlp-6: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1: - fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271]) +12 other tests skip [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][16] -> [ABORT][17] ([i915#8668]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1: - fi-hsw-4770:NOTRUN -> [DMESG-WARN][18] ([i915#8841]) +6 other tests dmesg-warn [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125052v2/fi-hsw-4770/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-vga-1.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1072]) +3 other tests skip [19]:
[Intel-gfx] [PATCH v7b 20/25] dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP
dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive.
When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY
prefix decorations are sprintf'd into stack-mem for every call.
This string (or part of it) could be cached once its 1st generated,
and retrieved thereafter, as long as its deleted any time the
callsite's flags are changed afterwards.
So consider the prefix/decoration flags: 'tmfsl', and what should be
in the cache:
-t thread-id. not part of the "callsite" info, derived from current.
doesn't belong in the cache. it would be wrong.
can be done in outer: dynamic_emit_prefix()
-l line number
this could be part of the prefix, but would bloat the cache
can also be done in outer: dynamic_emit_prefix()
-mfs module, function, source-file
we cache these, composed into a sub-string.
they are "lookups", currently to descriptor fields,
could be accessor macros to "compressed" tables.
cache saves more access work.
All enabled together, they compose a prefix string like:
# outer -inner-- outer
"[tid] module:function:sourcfile:line: "
So this patch extracts _DPRINTK_FLAGS_INCL_LOOKUP macro out of
_DPRINTK_FLAGS_INCL_ANY macro, then redefs latter.
Next re-refactor dynamic_emit_prefix inner/outer fns accordingly.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 927cb14f24e0..2237d454bc19 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -40,10 +40,12 @@ struct _ddebug {
#define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
#define _DPRINTK_FLAGS_PREFIX_CACHED (1<<7)
-#define _DPRINTK_FLAGS_INCL_ANY\
- (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
-_DPRINTK_FLAGS_INCL_LINENO | _DPRINTK_FLAGS_INCL_TID |\
+#define _DPRINTK_FLAGS_INCL_LOOKUP \
+ (_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME | \
_DPRINTK_FLAGS_INCL_SOURCENAME)
+#define _DPRINTK_FLAGS_INCL_ANY
\
+ (_DPRINTK_FLAGS_INCL_LINENO | _DPRINTK_FLAGS_INCL_TID | \
+_DPRINTK_FLAGS_INCL_LOOKUP)
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
--
2.41.0
[Intel-gfx] [PATCH v7b 25/25] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN
Lots of burn-in testing needed before signing, upstreaming. NOTE: I set default Y to maximize testing by default. Is there a better way to do this ? Signed-off-by: Jim Cromie --- drivers/gpu/drm/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 3caa020391c7..708f5e8cb205 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -55,8 +55,7 @@ config DRM_DEBUG_MM config DRM_USE_DYNAMIC_DEBUG bool "use dynamic debug to implement drm.debug" - default n - depends on BROKEN + default y depends on DRM depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE depends on JUMP_LABEL -- 2.41.0
[Intel-gfx] [PATCH v7b 23/25] drm: use correct ccflags-y spelling
Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DYNAMIC_DEBUG=n
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory
macro")
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 215e78e79125..22b1984cc982 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -3,7 +3,8 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
+ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG)+=
-DDYNAMIC_DEBUG_MODULE
+subdir-ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
drm-y := \
drm_aperture.o \
--
2.41.0
[Intel-gfx] [PATCH v7b 22/25] dyndbg: change WARN_ON to WARN_ON_ONCE
This shouldn't ever happen, and 1st 2 conditions never have.
The 3rd condition did happen, due to corrupt linkage due to a missing
align(8) in DYNDBG_CLASSMAP_USE, on the static struct allocation into
the __dyndbg_class_users section.
Not sure whether changing to _ONCE is appropriate - this is a
module-load activity, so it won't continuously spam syslog.
Signed-off-by: Jim Cromie
---
undo BUG_ON addition
---
lib/dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 5825b58043a6..2a5eb64dbc27 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1284,7 +1284,7 @@ static void ddebug_attach_user_module_classes(struct
ddebug_table *dt,
*/
for_each_boxed_vector(di, class_users, num_class_users, i, cli) {
- if (WARN_ON(!cli || !cli->map || !cli->user_mod_name))
+ if (WARN_ON_ONCE(!cli || !cli->map || !cli->user_mod_name))
continue;
if (!strcmp(cli->user_mod_name, dt->mod_name)) {
--
2.41.0
[Intel-gfx] [PATCH v7b 19/25] dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED
Reserve bit 7 to remember that a pr-debug callsite is/was:
- enabled, with +p
- wants a dynamic-prefix, with one+ of module:function:sourcfile
- was previously called
- was thus saved in the cache. NOT YET.
Its unclear whether any cache fetch would be faster than 2-3 field
fetches, but theres another factor; the 3 columns in the __dyndbg
section are highly redundant and compressible, but to get the
compression, we need field accessors, which will rebalance the
tradeoff.
So, for now, its just the bit reservation.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index f182f95caabb..927cb14f24e0 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -38,6 +38,7 @@ struct _ddebug {
#define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
#define _DPRINTK_FLAGS_INCL_TID(1<<4)
#define _DPRINTK_FLAGS_INCL_SOURCENAME (1<<5)
+#define _DPRINTK_FLAGS_PREFIX_CACHED (1<<7)
#define _DPRINTK_FLAGS_INCL_ANY\
(_DPRINTK_FLAGS_INCL_MODNAME | _DPRINTK_FLAGS_INCL_FUNCNAME |\
--
2.41.0
[Intel-gfx] [PATCH v7b 24/25] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files. For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.
Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its class'd prdbgs stuck in the initial
(disabled, but for DEBUG) state.
The stuck sites are evident in /proc/dynamic_debug/control as:
class:_UNKNOWN_ _id:N# control's last column
rather than a proper "enumeration":
class:DRM_UT_CORE
This set of updates was found by choosing M for all DRM-config items I
found (not allmodconfig), building & modprobing them, and grepping
"class unknown," control. There may yet be others.
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++
drivers/gpu/drm/gud/gud_drv.c | 2 ++
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++
drivers/gpu/drm/qxl/qxl_drv.c | 2 ++
drivers/gpu/drm/radeon/radeon_drv.c| 2 ++
drivers/gpu/drm/udl/udl_main.c | 2 ++
drivers/gpu/drm/vkms/vkms_drv.c| 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 ++
8 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index e435f986cd13..066d906e3199 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -23,6 +23,8 @@
#include
#include
+DRM_CLASSMAP_USE(drm_debug_classes);
+
MODULE_IMPORT_NS(DMA_BUF);
/**
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index 9d7bf8ee45f1..5b555045fce4 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -31,6 +31,8 @@
#include "gud_internal.h"
+DRM_CLASSMAP_USE(drm_debug_classes);
+
/* Only used internally */
static const struct drm_format_info gud_drm_format_r1 = {
.format = GUD_DRM_FORMAT_R1,
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index abddf37f0ea1..d678eb8e028d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -24,6 +24,8 @@ static int mgag200_modeset = -1;
MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
module_param_named(modeset, mgag200_modeset, int, 0400);
+DRM_CLASSMAP_USE(drm_debug_classes);
+
int mgag200_init_pci_options(struct pci_dev *pdev, u32 option, u32 option2)
{
struct device *dev = >dev;
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index b30ede1cf62d..91942ffcc2b4 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -65,6 +65,8 @@ module_param_named(modeset, qxl_modeset, int, 0400);
MODULE_PARM_DESC(num_heads, "Number of virtual crtcs to expose (default 4)");
module_param_named(num_heads, qxl_num_crtc, int, 0400);
+DRM_CLASSMAP_USE(drm_debug_classes);
+
static struct drm_driver qxl_driver;
static struct pci_driver qxl_pci_driver;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa531493b111..ab29945af657 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -247,6 +247,8 @@ int radeon_cik_support = 1;
MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 =
disabled)");
module_param_named(cik_support, radeon_cik_support, int, 0444);
+DRM_CLASSMAP_USE(drm_debug_classes);
+
static struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
};
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 3ebe2ce55dfd..ba57c14454e5 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -19,6 +19,8 @@
#define NR_USB_REQUEST_CHANNEL 0x12
+DRM_CLASSMAP_USE(drm_debug_classes);
+
#define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
#define WRITES_IN_FLIGHT (20)
#define MAX_VENDOR_DESCRIPTOR_SIZE 256
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index dd0af086e7fa..086797c4b82b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -39,6 +39,8 @@
static struct vkms_config *default_config;
+DRM_CLASSMAP_USE(drm_debug_classes);
+
static bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 8b24ecf60e3e..9cb6be422621 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -275,6 +275,8 @@ static int vmw_probe(struct pci_dev *, const struct
pci_device_id *);
static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
void *ptr);
+DRM_CLASSMAP_USE(drm_debug_classes);
+
MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
[Intel-gfx] [PATCH v7b 21/25] dyndbg: refactor *dynamic_emit_prefix
Refactor the split of duties between outer & inner fns.
The outer fn was previously just an inline unlikely forward to inner,
which did all the work.
Now, outer handles +t and +l flags itself, and calls inner only when
_DPRINTK_FLAGS_INCL_LOOKUP is needed.
No functional change.
But it does make the results of the inner-fn more cache-friendly
(fewer entries, reused more often):
1- no spurious [TID] or noise
2- no LINE-number to bloat the cache (avg 9 pr_debugs/fn)
3- only LOOKUP stuff
Currently LOOKUPs are descriptor-field refs but could be replaced by
accessor functions. This would allow the __dyndbg_sites section to be
de-duplicated and reclaimed; currently module, filename fields are
~90% repeated. As the accessors get more expensive, the value of
caching part of the prefix goes up.
Also change inner-fn to return count of extra chars written to the
buffer, and drop "inline" from outer, let the compiler decide. Maybe
also change name accordingly.
Signed-off-by: Jim Cromie
---
fixup whitespace
---
lib/dynamic_debug.c | 39 ++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 17eefb35ac96..5825b58043a6 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -777,11 +777,28 @@ static int remaining(int wrote)
return 0;
}
-static char *__dynamic_emit_prefix(const struct _ddebug *desc, char *buf)
+static int __dynamic_emit_prefix(const struct _ddebug *desc, char *buf, int
pos)
+{
+ if (desc->flags & _DPRINTK_FLAGS_INCL_MODNAME)
+ pos += snprintf(buf + pos, remaining(pos), "%s:",
+ desc->modname);
+ if (desc->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
+ pos += snprintf(buf + pos, remaining(pos), "%s:",
+ desc->function);
+ if (desc->flags & _DPRINTK_FLAGS_INCL_SOURCENAME)
+ pos += snprintf(buf + pos, remaining(pos), "%s:",
+ trim_prefix(desc->filename));
+ return pos;
+}
+
+static char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
{
int pos_after_tid;
int pos = 0;
+ if (likely(!(desc->flags & _DPRINTK_FLAGS_INCL_ANY)))
+ return buf;
+
if (desc->flags & _DPRINTK_FLAGS_INCL_TID) {
if (in_interrupt())
pos += snprintf(buf + pos, remaining(pos), " ");
@@ -790,15 +807,10 @@ static char *__dynamic_emit_prefix(const struct _ddebug
*desc, char *buf)
task_pid_vnr(current));
}
pos_after_tid = pos;
- if (desc->flags & _DPRINTK_FLAGS_INCL_MODNAME)
- pos += snprintf(buf + pos, remaining(pos), "%s:",
- desc->modname);
- if (desc->flags & _DPRINTK_FLAGS_INCL_FUNCNAME)
- pos += snprintf(buf + pos, remaining(pos), "%s:",
- desc->function);
- if (desc->flags & _DPRINTK_FLAGS_INCL_SOURCENAME)
- pos += snprintf(buf + pos, remaining(pos), "%s:",
- trim_prefix(desc->filename));
+
+ if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_LOOKUP))
+ pos += __dynamic_emit_prefix(desc, buf, pos);
+
if (desc->flags & _DPRINTK_FLAGS_INCL_LINENO)
pos += snprintf(buf + pos, remaining(pos), "%d:",
desc->lineno);
@@ -810,13 +822,6 @@ static char *__dynamic_emit_prefix(const struct _ddebug
*desc, char *buf)
return buf;
}
-static inline char *dynamic_emit_prefix(struct _ddebug *desc, char *buf)
-{
- if (unlikely(desc->flags & _DPRINTK_FLAGS_INCL_ANY))
- return __dynamic_emit_prefix(desc, buf);
- return buf;
-}
-
void __dynamic_pr_debug(struct _ddebug *descriptor, const char *fmt, ...)
{
va_list args;
--
2.41.0
[Intel-gfx] [PATCH v7b 14/25] dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression
DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K
rule: "define once, refer many times".
When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together when DRM.debug
categories are enabled.
Worse, it causes the CONFIG_DRM_USE_DYNAMIC_DEBUG=Y regression; 1st
drm.ko loads, and dyndbg initializes its DRM.debug callsites, then a
drm-driver loads, but too late - it missed the DRM.debug enablement.
So replace it with 2 macros:
DYNDBG_CLASSMAP_DEFINE - invoked once from core - drm.ko
DYNDBG_CLASSMAP_USE- from all drm drivers and helpers.
DYNDBG_CLASSMAP_DEFINE: based on DECLARE_DYNDBG_CLASSMAP, but now it
drops the static on the constructed classmap variable, and exports it
instead.
DYNDBG_CLASSMAP_USE: then refers to the exported var by name:
* used from drivers, helper-mods
* lets us drop the repetitive "classname" args
* fixes 2nd-defn problem
* creates a ddebug_class_user record in new __dyndbg_class_users section
this allows ddebug_add_module(etal) to handle them per-module.
The distinction, and the usage record, allows dyndbg to initialize the
driver's DRM.debug callsites separately after it is modprobed.
Since DRM now needs updates to use the new macros, it also gets 2
wrappers: DRM_CLASSMAP_DEFINE, DRM_CLASSMAP_USE which declutter the
users by hiding the ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG.
To review, dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.
. DYNDBG_CLASSMAP_DEFINE(and old one) creates classmaps in this section.
This patch adds __dyndbg_class_users[] section:
. catalogs uses/references to the classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. DYNDBG_CLASSMAP_USE() creates classmap-user records in this section.
Now ddebug_add_module(etal) can handle classmap-uses like (and after)
classmaps; when a dependent module is loaded, its parent's kernel
params are scanned to find the param wired to dyndbg-param-ops, whose
classmap matches the one ref'd by the client.
To support this, theres a few data/header changes:
. new struct ddebug_class_user
contains: user-module-name,
it records drm-driver's use of a classmap in the section, allowing lookup
struct ddebug_info gets 2 new fields to encapsulate the new section:
class_users, num_class_users.
set by dynamic_debug_init() for builtins.
or by kernel/module/main:load_info() for loadable modules.
vmlinux.lds.h: new BOUNDED_SECTION for __dyndbg_class_users
dynamic_debug.c has 2 changes in ddebug_add_module(), ddebug_change():
ddebug_add_module() already calls ddebug_attach_module_classes()
to handle classmaps DEFINEd by a module, now it also calls
ddebug_attach_user_module_classes() to handle USEd classmaps. To
avoid this work when possible, 1st scan the module's descriptors and
count the number of class'd pr_debugs.
ddebug_attach_user_module_classes() scans the module's class_users
section, follows the refs to the parent's classmap, and calls
ddebug_apply_params() on each. It also avoids work by checking the
module's class-ct.
ddebug_apply_params(new fn):
It scans module's/builtin kernel-params, calls ddebug_match_apply_kparam
for each to find the params/sysfs-nodes which may be wired to a classmap.
ddebug_match_apply_kparam(new fn):
1st, it tests the kernel-param.ops is dyndbg's; this guarantees that
the attached arg is a struct ddebug_class_param, which has a ref to
the param's state, and to the classmap defining the param's handling.
2nd, it requires that the classmap ref'd by the kparam is the one
we're called for; modules can use many separate classmaps (as
test_dynamic_debug does).
Then apply the "parent" kparam's setting to the dependent module,
using ddebug_apply_class_bitmap().
ddebug_change(and callees) also gets adjustments:
ddebug_find_valid_class(): This does a search over the module's
classmaps, looking for the class FOO echo'd to >control. So now it
searches over __dyndbg_class_users[] after __dyndbg_classes[].
ddebug_class_name(): return class-names for defined AND used classes.
test_dynamic_debug.c, test_dynamic_debug_submod.c:
This (already) demonstrates the 2 types of classmaps & sysfs-params,
following the 4-part recipe:
1. define an enum for the classmap: DRM.debug has DRM_UT_{CORE,KMS,...}
multiple classes must share 0-62 classid space.
2. DYNDBG_CLASSMAP_DEFINE(.. DRM_UT_{CORE,KMS,...})
3. DYNDBG_CLASSMAP_PARAM* (classmap)
4. DYNDBG_CLASSMAP_USE()
by _submod only, skipping 2,3
Move all the enum declarations together, to better explain how they
share the 0..62 class-id space available to a module (non-overlapping
subranges).
reorg macros 2,3 by name. This gives a tabular format, making it easy
to see the pattern of repetition, and the points of change.
And
[Intel-gfx] [PATCH v7b 18/25] dyndbg-doc: add classmap info to howto
Add some basic info on classmap usage and api cc: linux-...@vger.kernel.org Signed-off-by: Jim Cromie --- v5- adjustments per Randy Dunlap, me v7b- checkpatch fixes --- .../admin-guide/dynamic-debug-howto.rst | 60 ++- 1 file changed, 59 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 0b3d39c610d9..028c2cb5b4c5 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -225,7 +225,6 @@ the ``p`` flag has meaning, other flags are ignored. Note the regexp ``^[-+=][fslmpt_]+$`` matches a flags specification. To clear all flags at once, use ``=_`` or ``-fslmpt``. - Debug messages during Boot Process == @@ -375,3 +374,62 @@ just a shortcut for ``print_hex_dump(KERN_DEBUG)``. For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is its ``prefix_str`` argument, if it is constant string; or ``hexdump`` in case ``prefix_str`` is built dynamically. + +Dynamic Debug classmaps +=== + +Dyndbg allows selection/grouping of *prdbg* callsites using structural +info: module, file, function, line. Classmaps allow authors to add +their own domain-oriented groupings using class-names. Classmaps are +exported, so they referencable from other modules. + + # enable classes individually + :#> ddcmd class DRM_UT_CORE +p + :#> ddcmd class DRM_UT_KMS +p + # or more selectively + :#> ddcmd class DRM_UT_CORE module drm +p + +The "class FOO" syntax protects class'd prdbgs from generic overwrite:: + + # IOW this doesn't wipe any DRM.debug settings + :#> ddcmd -p + +To support the DRM.debug parameter, DYNDBG_CLASSMAP_PARAM* updates all +classes in a classmap, mapping param-bits 0..N onto the classes: +DRM_UT_<*> for the DRM use-case. + +Dynamic Debug Classmap API +== + +DYNDBG_CLASSMAP_DEFINE - modules use this to create classmaps, naming +each of the classes (stringified enum-symbols: "DRM_UT_<*>"), and +type, and mapping the class-names to consecutive _class_ids. + +By doing so, modules tell dyndbg that they are have prdbgs with those +class_ids, and they authorize dyndbg to accept "class FOO" for the +module defining that classname. + +There are 2 types of classmaps: + + DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, like DRM.debug + DD_CLASS_TYPE_LEVEL_NUM: classes are relative, ordered (V3 > V2) + +DYNDBG_CLASSMAP_PARAM - refers to a DEFINEd classmap, exposing the set +of defined classes to manipulation as a group. This interface +enforces the relatedness of classes of DD_CLASS_TYPE_LEVEL_NUM typed +classmaps; all classes are independent in the >control parser itself. + +DYNDBG_CLASSMAP_USE - drm drivers invoke this to ref the CLASSMAP that +drm DEFINEs. This shares the classmap definition, and authorizes +dyndbg to apply changes to the user module's class'd pr_debugs. It +also tells dyndbg how to initialize the user's prdbgs at modprobe, +based upon the current setting of the parent's controlling param. + +Modules or module-groups (drm & drivers) can define multiple +classmaps, as long as they share the limited 0..62 per-module-group +_class_id range, without overlap. + +``#define DEBUG`` will enable all pr_debugs in scope, including any +class'd ones. This won't be reflected in the PARAM readback value, +but the pr_debug callsites can be toggled into agreement with the +param. -- 2.41.0
[Intel-gfx] [PATCH v7b 16/25] dyndbg: refactor ddebug_classparam_clamp_input
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former. It takes kernel-param arg, so it can complain
about "foo: bad input".
Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to validate inputs from parent's params, just like our own.
To support that reuse, alter ddebug_sync_classbits() and caller to
pass kp instead of kp->arg.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 70 ++---
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index c11feca70d6f..17eefb35ac96 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -656,6 +656,30 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
#define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
+static void ddebug_class_param_clamp_input(unsigned long *inrep, const struct
kernel_param *kp)
+{
+ const struct ddebug_class_param *dcp = kp->arg;
+ const struct ddebug_class_map *map = dcp->map;
+
+ switch (map->map_type) {
+ case DD_CLASS_TYPE_DISJOINT_BITS:
+ /* expect bits. mask and warn if too many */
+ if (*inrep & ~CLASSMAP_BITMASK(map->length)) {
+ pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx,
masking\n",
+ KP_NAME(kp), *inrep,
CLASSMAP_BITMASK(map->length));
+ *inrep &= CLASSMAP_BITMASK(map->length);
+ }
+ break;
+ case DD_CLASS_TYPE_LEVEL_NUM:
+ /* input is bitpos, of highest verbosity to be enabled */
+ if (*inrep > map->length) {
+ pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
+ KP_NAME(kp), *inrep, map->length);
+ *inrep = map->length;
+ }
+ break;
+ }
+}
static int param_set_dyndbg_module_classes(const char *instr,
const struct kernel_param *kp,
const char *modnm)
@@ -674,26 +698,15 @@ static int param_set_dyndbg_module_classes(const char
*instr,
pr_err("expecting numeric input, not: %s > %s\n", instr,
KP_NAME(kp));
return -EINVAL;
}
+ ddebug_class_param_clamp_input(, kp);
switch (map->map_type) {
case DD_CLASS_TYPE_DISJOINT_BITS:
- /* expect bits. mask and warn if too many */
- if (inrep & ~CLASSMAP_BITMASK(map->length)) {
- pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx,
masking\n",
- KP_NAME(kp), inrep,
CLASSMAP_BITMASK(map->length));
- inrep &= CLASSMAP_BITMASK(map->length);
- }
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*",
KP_NAME(kp));
totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits,
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
- /* input is bitpos, of highest verbosity to be enabled */
- if (inrep > map->length) {
- pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
- KP_NAME(kp), inrep, map->length);
- inrep = map->length;
- }
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
@@ -1160,16 +1173,27 @@ static const char * const ddebug_classmap_typenames[] =
{
ddebug_classmap_typenames[_cm->map_type]);\
})
-static void ddebug_sync_classbits(const struct ddebug_class_param *dcp, const
char *modname)
+static void ddebug_sync_classbits(const struct kernel_param *kp, const char
*modname)
{
- /* clamp initial bitvec, mask off hi-bits */
- if (*dcp->bits & ~CLASSMAP_BITMASK(dcp->map->length)) {
- *dcp->bits &= CLASSMAP_BITMASK(dcp->map->length);
- v2pr_info("preset classbits: %lx\n", *dcp->bits);
+ struct ddebug_class_param *dcp = kp->arg;
+ unsigned long new_bits;
+
+ ddebug_class_param_clamp_input(dcp->bits, kp);
+
+ switch (dcp->map->map_type) {
+ case DD_CLASS_TYPE_DISJOINT_BITS:
+ v2pr_info(" %s: classbits: 0x%lx\n", KP_NAME(kp), *dcp->bits);
+ ddebug_apply_class_bitmap(dcp, dcp->bits, 0UL, modname);
+ break;
+ case DD_CLASS_TYPE_LEVEL_NUM:
+ new_bits = CLASSMAP_BITMASK(*dcp->lvl);
+ v2pr_info(" %s: lvl:%ld bits:0x%lx\n", KP_NAME(kp), *dcp->lvl,
new_bits);
+ ddebug_apply_class_bitmap(dcp, _bits, 0UL, modname);
+ break;
+ default:
+
[Intel-gfx] [PATCH v7b 15/25] dyndbg: add for_each_boxed_vector
Add a for_each iterator to walk a counted vector member in a struct
(ie the box), and use it to replace 8 open-coded loops.
Signed-off-by: Jim Cromie
---
v5- parens-on-box-force-precedence
---
lib/dynamic_debug.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index be49e104ec76..c11feca70d6f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -158,6 +158,9 @@ static void vpr_info_dq(const struct ddebug_query *query,
const char *msg)
_dt->num_class_users);\
})
+#define for_each_boxed_vector(_box, _vec, _len, _ct, _curs)\
+ for (_ct = 0, _curs = (_box)->_vec; _ct < (_box)->_len; _ct++, _curs++)
+
#define __outvar /* filled by callee */
static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table
const *dt,
const char
*class_string,
@@ -167,7 +170,7 @@ static struct ddebug_class_map
*ddebug_find_valid_class(struct ddebug_table cons
struct ddebug_class_user *cli;
int i, idx;
- for (i = 0, map = dt->classes; i < dt->num_classes; i++, map++) {
+ for_each_boxed_vector(dt, classes, num_classes, i, map) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -175,7 +178,7 @@ static struct ddebug_class_map
*ddebug_find_valid_class(struct ddebug_table cons
return map;
}
}
- for (i = 0, cli = dt->class_users; i < dt->num_class_users; i++, cli++)
{
+ for_each_boxed_vector(dt, class_users, num_class_users, i, cli) {
idx = match_string(cli->map->class_names, cli->map->length,
class_string);
if (idx >= 0) {
*class_id = idx + cli->map->base;
@@ -1058,11 +1061,11 @@ static const char *ddebug_class_name(struct
ddebug_table *dt, struct _ddebug *dp
struct ddebug_class_user *cli = dt->class_users;
int i;
- for (i = 0; i < dt->num_classes; i++, map++)
+ for_each_boxed_vector(dt, classes, num_classes, i, map)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
- for (i = 0; i < dt->num_class_users; i++, cli++)
+ for_each_boxed_vector(dt, class_users, num_class_users, i, cli)
if (class_in_range(dp->class_id, cli->map))
return cli->map->class_names[dp->class_id -
cli->map->base];
@@ -1216,7 +1219,7 @@ static void ddebug_attach_module_classes(struct
ddebug_table *dt, struct _ddebug
struct ddebug_class_map *cm;
int i, nc = 0;
- for (i = 0, cm = di->classes; i < di->num_classes; i++, cm++) {
+ for_each_boxed_vector(di, classes, num_classes, i, cm) {
if (!strcmp(cm->mod_name, dt->mod_name)) {
vpr_cm_info(cm, "classes[%d]:", i);
@@ -1230,7 +1233,7 @@ static void ddebug_attach_module_classes(struct
ddebug_table *dt, struct _ddebug
vpr_info("module:%s attached %d classes\n", dt->mod_name, nc);
dt->num_classes = nc;
- for (i = 0, cm = dt->classes; i < dt->num_classes; i++, cm++)
+ for_each_boxed_vector(di, classes, num_classes, i, cm)
ddebug_apply_params(cm, cm->mod_name);
}
@@ -1250,7 +1253,7 @@ static void ddebug_attach_user_module_classes(struct
ddebug_table *dt,
* module's refs, save to dt. For loadables, this is the
* whole array.
*/
- for (i = 0, cli = di->class_users; i < di->num_class_users; i++, cli++)
{
+ for_each_boxed_vector(di, class_users, num_class_users, i, cli) {
if (WARN_ON(!cli || !cli->map || !cli->user_mod_name))
continue;
@@ -1268,8 +1271,7 @@ static void ddebug_attach_user_module_classes(struct
ddebug_table *dt,
dt->num_class_users = nc;
- /* now iterate dt */
- for (i = 0, cli = dt->class_users; i < dt->num_class_users; i++, cli++)
+ for_each_boxed_vector(di, class_users, num_class_users, i, cli)
ddebug_apply_params(cli->map, cli->user_mod_name);
vpr_dt_info(dt, "attach-client-module: ");
--
2.41.0
[Intel-gfx] [PATCH v7b 17/25] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into
the header, and refine it, by distinguishing the 2 use cases:
1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before
2.DYNDBG_CLASSMAP_PARAM
new user (test_dynamic_debug) doesn't need to share state,
decls a static long unsigned int to store the bitvec.
__DYNDBG_CLASSMAP_PARAM
bottom layer - allocate,init a ddebug-class-param, module-param-cb.
Also clean up and improve comments in test-code, and add
MODULE_DESCRIPTIONs.
Signed-off-by: Jim Cromie
---
---
drivers/gpu/drm/drm_print.c | 8 ++---
include/drm/drm_print.h | 6 ++--
include/linux/dynamic_debug.h | 37 +-
lib/test_dynamic_debug.c| 56 +++--
lib/test_dynamic_debug_submod.c | 9 +-
5 files changed, 69 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index dabcfa0dd279..8f4b609353a5 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -69,12 +69,8 @@ DRM_CLASSMAP_DEFINE(drm_debug_classes,
DD_CLASS_TYPE_DISJOINT_BITS,
"DRM_UT_DP",
"DRM_UT_DRMRES");
-static struct ddebug_class_param drm_debug_bitmap = {
- .bits = &__drm_debug,
- .flags = "p",
- .map = _debug_classes,
-};
-module_param_cb(debug, _ops_dyndbg_classes, _debug_bitmap, 0600);
+DRM_CLASSMAP_PARAM_REF(debug, __drm_debug, drm_debug_classes, p);
+
#endif
void __drm_puts_coredump(struct drm_printer *p, const char *str)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 706afc97c79c..94d4f5500030 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -322,11 +322,13 @@ enum drm_debug_category {
};
#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
-#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
-#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
+#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)DYNDBG_CLASSMAP_PARAM_REF(__VA_ARGS__)
#else
#define DRM_CLASSMAP_DEFINE(...)
#define DRM_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)
#endif
static inline bool drm_debug_enabled_raw(enum drm_debug_category category)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 1b027be2cdc4..f182f95caabb 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -91,7 +91,7 @@ struct ddebug_class_map {
* used to validate a "class FOO .." >control command on the module
*/
#define DYNDBG_CLASSMAP_DEFINE(_var, _maptype, _base, ...) \
- const char *_var##_classnames[] = { __VA_ARGS__ }; \
+ static const char *_var##_classnames[] = { __VA_ARGS__ }; \
struct ddebug_class_map __aligned(8) __used \
__section("__dyndbg_classes") _var = { \
.mod = THIS_MODULE, \
@@ -145,6 +145,41 @@ struct ddebug_class_param {
const struct ddebug_class_map *map;
};
+/**
+ * DYNDBG_CLASSMAP_PARAM - wrap a dyndbg-classmap with a controlling sys-param
+ * @_name sysfs node name
+ * @_var name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classes defined by the
+ * classmap. Keeps bits in a private/static
+ */
+#define DYNDBG_CLASSMAP_PARAM(_name, _var, _flags) \
+ static unsigned long _name##_bvec; \
+ __DYNDBG_CLASSMAP_PARAM(_name, _name##_bvec, _var, _flags)
+
+/**
+ * DYNDBG_CLASSMAP_PARAM_REF - wrap a dyndbg-classmap with a controlling
sys-param
+ * @_name sysfs node name
+ * @_bits name of the module's unsigned long bit-vector, ex: __drm_debug
+ * @_var name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classmap, keeping bitvec in user
@_bits.
+ * This lets drm use __drm_debug elsewhere too.
+ */
+#define DYNDBG_CLASSMAP_PARAM_REF(_name, _bits, _var, _flags) \
+ __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)
+
+#define __DYNDBG_CLASSMAP_PARAM(_name, _bits, _var, _flags)\
+ static struct ddebug_class_param _name##_##_flags = { \
+ .bits = &(_bits), \
+ .flags = #_flags, \
+ .map = &(_var), \
+ }; \
+ module_param_cb(_name, _ops_dyndbg_classes, \
+
[Intel-gfx] [PATCH v7b 10/25] dyndbg: tighten ddebug_class_name() 1st arg type
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b07aab422604..8158943b350d 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1117,12 +1117,12 @@ static void *ddebug_proc_next(struct seq_file *m, void
*p, loff_t *pos)
#define class_in_range(class_id, map) \
(class_id >= map->base && class_id < map->base + map->length)
-static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug
*dp)
+static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug
*dp)
{
- struct ddebug_class_map *map = iter->table->classes;
- int i, nc = iter->table->num_classes;
+ struct ddebug_class_map *map = dt->classes;
+ int i;
- for (i = 0; i < nc; i++, map++)
+ for (i = 0; i < dt->num_classes; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
@@ -1156,7 +1156,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
seq_puts(m, "\"");
if (dp->class_id != _DPRINTK_CLASS_DFLT) {
- class = ddebug_class_name(iter, dp);
+ class = ddebug_class_name(iter->table, dp);
if (class)
seq_printf(m, " class:%s", class);
else
--
2.41.0
[Intel-gfx] [PATCH v7b 12/25] dyndbg: reduce verbose=3 messages in ddebug_add_module
The fn currently says "add-module", then "skipping" if the module has
no prdbgs. Just check 1st and return quietly.
no functional change
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8beb98a831f5..45870a699507 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1242,11 +1242,10 @@ static int ddebug_add_module(struct _ddebug_info *di,
const char *modname)
{
struct ddebug_table *dt;
- v3pr_info("add-module: %s.%d sites\n", modname, di->num_descs);
- if (!di->num_descs) {
- v3pr_info(" skip %s\n", modname);
+ if (!di->num_descs)
return 0;
- }
+
+ v3pr_info("add-module: %s %d sites\n", modname, di->num_descs);
dt = kzalloc(sizeof(*dt), GFP_KERNEL);
if (dt == NULL) {
--
2.41.0
[Intel-gfx] [PATCH v7b 13/25] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:
echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names
The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things for now.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 19 ++-
lib/dynamic_debug.c | 103 +++---
lib/test_dynamic_debug.c | 12
3 files changed, 12 insertions(+), 122 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 8116d0a0d33a..8eaf8eabdc8d 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -61,24 +61,13 @@ struct _ddebug {
enum class_map_type {
DD_CLASS_TYPE_DISJOINT_BITS,
/**
-* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, one per bit.
-* expecting hex input. Built for drm.debug, basis for other types.
+* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, mapped to
bits[0..N].
+* Expects hex input. Built for drm.debug, basis for other types.
*/
DD_CLASS_TYPE_LEVEL_NUM,
/**
-* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N.
-* N turns on just bits N-1 .. 0, so N=0 turns all bits off.
-*/
- DD_CLASS_TYPE_DISJOINT_NAMES,
- /**
-* DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* classes are independent, like _DISJOINT_BITS.
-*/
- DD_CLASS_TYPE_LEVEL_NAMES,
- /**
-* DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* intended for names like: INFO,DEBUG,TRACE, with a module prefix
-* avoid EMERG,ALERT,CRIT,ERR,WARNING: they're not debug
+* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0..N.
+* Input N turns on bits 0..N-1
*/
};
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 45870a699507..91c8b67fd8f8 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -632,77 +632,6 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
#define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
-/* accept comma-separated-list of [+-] classnames */
-static int param_set_dyndbg_classnames(const char *instr, const struct
kernel_param *kp)
-{
- const struct ddebug_class_param *dcp = kp->arg;
- const struct ddebug_class_map *map = dcp->map;
- unsigned long curr_bits, old_bits;
- char *cl_str, *p, *tmp;
- int cls_id, totct = 0;
- bool wanted;
-
- cl_str = tmp = kstrdup(instr, GFP_KERNEL);
- p = strchr(cl_str, '\n');
- if (p)
- *p = '\0';
-
- /* start with previously set state-bits, then modify */
- curr_bits = old_bits = *dcp->bits;
- vpr_info("\"%s\" > %s:0x%lx\n", cl_str, KP_NAME(kp), curr_bits);
-
- for (; cl_str; cl_str = p) {
- p = strchr(cl_str, ',');
- if (p)
- *p++ = '\0';
-
- if (*cl_str == '-') {
- wanted = false;
- cl_str++;
- } else {
- wanted = true;
- if (*cl_str == '+')
- cl_str++;
- }
- cls_id = match_string(map->class_names, map->length, cl_str);
- if (cls_id < 0) {
- pr_err("%s unknown to %s\n", cl_str, KP_NAME(kp));
- continue;
- }
-
- /* have one or more valid class_ids of one *_NAMES type */
- switch (map->map_type) {
- case DD_CLASS_TYPE_DISJOINT_NAMES:
- /* the +/- pertains to a single bit */
- if (test_bit(cls_id, _bits) == wanted) {
- v3pr_info("no change on %s\n", cl_str);
- continue;
- }
- curr_bits ^= BIT(cls_id);
- totct += ddebug_apply_class_bitmap(dcp, _bits,
*dcp->bits, NULL);
- *dcp->bits = curr_bits;
- v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp),
cls_id,
- map->class_names[cls_id]);
- break;
- case DD_CLASS_TYPE_LEVEL_NAMES:
- /* cls_id = N in 0..max. wanted +/- determines N or N-1
*/
- old_bits = CLASSMAP_BITMASK(*dcp->lvl);
- curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0
));
-
- totct += ddebug_apply_class_bitmap(dcp, _bits,
old_bits, NULL);
- *dcp->lvl = (cls_id + (wanted ? 1 : 0));
- v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n",
KP_NAME(kp), cls_id,
-
[Intel-gfx] [PATCH v7b 11/25] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn. Disallow this.
And constify new_bits while here.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8158943b350d..8beb98a831f5 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -593,7 +593,8 @@ static int ddebug_exec_queries(char *query, const char
*modname)
/* apply a new class-param setting */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long
*old_bits,
+const unsigned long *new_bits,
+const unsigned long old_bits,
const char *query_modname)
{
#define QUERY_SIZE 128
@@ -602,12 +603,12 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
- if (*new_bits != *old_bits)
+ if (*new_bits != old_bits)
v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
for (bi = 0; bi < map->length; bi++) {
- if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
+ if (test_bit(bi, new_bits) == test_bit(bi, _bits))
continue;
snprintf(query, QUERY_SIZE, "class %s %c%s",
map->class_names[bi],
@@ -619,9 +620,9 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
ct, map->class_names[bi], *new_bits);
}
- if (*new_bits != *old_bits)
+ if (*new_bits != old_bits)
v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
return matches;
}
@@ -678,7 +679,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
- totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits, NULL);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
*dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp),
cls_id,
map->class_names[cls_id]);
@@ -688,7 +689,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0
));
- totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits, NULL);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
old_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n",
KP_NAME(kp), cls_id,
map->class_names[cls_id], old_bits,
curr_bits);
@@ -742,7 +743,7 @@ static int param_set_dyndbg_module_classes(const char
*instr,
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*",
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
modnm);
+ totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits,
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -755,7 +756,7 @@ static int param_set_dyndbg_module_classes(const char
*instr,
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
modnm);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, old_bits,
modnm);
*dcp->lvl = inrep;
break;
default:
--
2.41.0
[Intel-gfx] [PATCH v7b 08/25] dyndbg: reduce verbose/debug clutter
currently, for verbose=3, these are logged (blank lines for clarity):
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 class=...
dyndbg: no matches for query
dyndbg: no-match: func="" file="" module="" format="" lineno=0-0 class=...
dyndbg: processed 1 queries, with 0 matches, 0 errs
That is excessive, so this patch:
- shrinks 3 lines of 2nd stanza to single line
- drops 1st 2 lines of 3rd stanza
3rd is like 1st, with result, not procedure.
2nd is just status, retold in 4th, with more info.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b67c9b137447..b0e11f6bfaa2 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -266,9 +266,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
- if (!nfound && verbose)
- pr_info("no matches for query\n");
-
return nfound;
}
@@ -497,7 +494,6 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
pr_err("bad flag-op %c, at start of %s\n", *str, str);
return -EINVAL;
}
- v3pr_info("op='%c'\n", op);
for (; *str ; ++str) {
for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) {
@@ -511,7 +507,6 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
return -EINVAL;
}
}
- v3pr_info("flags=0x%x\n", modifiers->flags);
/* calculate final flags, mask based upon op */
switch (op) {
@@ -527,7 +522,7 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
modifiers->flags = 0;
break;
}
- v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags,
modifiers->mask);
+ v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags,
modifiers->mask);
return 0;
}
@@ -537,7 +532,7 @@ static int ddebug_exec_query(char *query_string, const char
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
#define MAXWORDS 9
- int nwords, nfound;
+ int nwords;
char *words[MAXWORDS];
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -555,10 +550,7 @@ static int ddebug_exec_query(char *query_string, const
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
- nfound = ddebug_change(, );
- vpr_info_dq(, nfound ? "applied" : "no-match");
-
- return nfound;
+ return ddebug_change(, );
}
/* handle multiple queries in query string, continue on error, return
--
2.41.0
[Intel-gfx] [PATCH v7b 07/25] dyndbg: drop NUM_TYPE_ARRAY
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index b53217e4b711..8116d0a0d33a 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -106,11 +106,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base, \
.map_type = _maptype, \
- .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+ .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames, \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
/* encapsulate linker provided built-in (or module) dyndbg data */
struct _ddebug_info {
--
2.41.0
[Intel-gfx] [PATCH v7b 09/25] dyndbg: silence debugs with no-change updates
check for actual changes before announcing them, declutter logs.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b0e11f6bfaa2..b07aab422604 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -591,7 +591,7 @@ static int ddebug_exec_queries(char *query, const char
*modname)
return nfound;
}
-/* apply a new bitmap to the sys-knob's current bit-state */
+/* apply a new class-param setting */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
unsigned long *new_bits, unsigned long
*old_bits,
const char *query_modname)
@@ -602,8 +602,9 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
- v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
- query_modname ?: "");
+ if (*new_bits != *old_bits)
+ v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,8 +619,9 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
ct, map->class_names[bi], *new_bits);
}
- v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
- query_modname ?: "");
+ if (*new_bits != *old_bits)
+ v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
return matches;
}
--
2.41.0
[Intel-gfx] [PATCH v7b 06/25] dyndbg: split param_set_dyndbg_classes to module/wrapper fns
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new. New arg allows caller to specify that only one module
is affected by a prdbgs update.
Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope of changes
made.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ba41fdeaaf98..b67c9b137447 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -708,18 +708,9 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
return 0;
}
-/**
- * param_set_dyndbg_classes - class FOO >control
- * @instr: string echo>d to sysfs, input depends on map_type
- * @kp:kp->arg has state: bits/lvl, map, map_type
- *
- * Enable/disable prdbgs by their class, as given in the arguments to
- * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative
- * levels by bitpos.
- *
- * Returns: 0 or <0 if error.
- */
-int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+static int param_set_dyndbg_module_classes(const char *instr,
+ const struct kernel_param *kp,
+ const char *modnm)
{
const struct ddebug_class_param *dcp = kp->arg;
const struct ddebug_class_map *map = dcp->map;
@@ -756,8 +747,8 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
KP_NAME(kp), inrep,
CLASSMAP_BITMASK(map->length));
inrep &= CLASSMAP_BITMASK(map->length);
}
- v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
NULL);
+ v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*",
KP_NAME(kp));
+ totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -770,7 +761,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
NULL);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
modnm);
*dcp->lvl = inrep;
break;
default:
@@ -779,6 +770,22 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct);
return 0;
}
+
+/**
+ * param_set_dyndbg_classes - class FOO >control
+ * @instr: string echo>d to sysfs, input depends on map_type
+ * @kp:kp->arg has state: bits/lvl, map, map_type
+ *
+ * Enable/disable prdbgs by their class, as given in the arguments to
+ * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative
+ * levels by bitpos.
+ *
+ * Returns: 0 or <0 if error.
+ */
+int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+{
+ return param_set_dyndbg_module_classes(instr, kp, NULL);
+}
EXPORT_SYMBOL(param_set_dyndbg_classes);
/**
--
2.41.0
[Intel-gfx] [PATCH v7b 04/25] dyndbg: replace classmap list with a vector
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.
So this changes:
struct ddebug_class_map drops list-head link.
struct ddebug_table drops the list-head maps, and gets: classes &
num_classes for the start-addy and num_classes, placed to improve
struct packing.
The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.
The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.
Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.
no functional changes
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 1 -
lib/dynamic_debug.c | 61 ++-
2 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 5231aaf361c4..b53217e4b711 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -83,7 +83,6 @@ enum class_map_type {
};
struct ddebug_class_map {
- struct list_head link;
struct module *mod;
const char *mod_name; /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b984ce338921..a3be2e7c8c84 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
extern struct ddebug_class_map __stop___dyndbg_classes[];
struct ddebug_table {
- struct list_head link, maps;
+ struct list_head link;
const char *mod_name;
- unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+ struct ddebug_class_map *classes;
+ unsigned int num_ddebugs, num_classes;
};
struct ddebug_query {
@@ -147,13 +148,15 @@ static void vpr_info_dq(const struct ddebug_query *query,
const char *msg)
query->first_lineno, query->last_lineno, query->class_string);
}
+#define __outvar /* filled by callee */
static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table
const *dt,
- const char
*class_string, int *class_id)
+ const char
*class_string,
+ __outvar int *class_id)
{
struct ddebug_class_map *map;
- int idx;
+ int i, idx;
- list_for_each_entry(map, >maps, link) {
+ for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -164,7 +167,6 @@ static struct ddebug_class_map
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
}
-#define __outvar /* filled by callee */
/*
* Search the tables for _ddebug's which match the given `query' and
* apply the `flags' and `mask' to them. Returns number of matching
@@ -,9 +1113,10 @@ static void *ddebug_proc_next(struct seq_file *m, void
*p, loff_t *pos)
static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug
*dp)
{
- struct ddebug_class_map *map;
+ struct ddebug_class_map *map = iter->table->classes;
+ int i, nc = iter->table->num_classes;
- list_for_each_entry(map, >table->maps, link)
+ for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
@@ -1197,30 +1200,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
};
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct
_ddebug_info *di)
{
struct ddebug_class_map *cm;
- int i, j, ct = 0;
+ int i, nc = 0;
- for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+ /*
+* Find this module's classmaps in a subrange/wholerange of
+* the builtin/modular classmap vector/section. Save the start
+* and length of the subrange
[Intel-gfx] [PATCH v7b 03/25] dyndbg: make ddebug_class_param union members same size
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 2 +-
lib/dynamic_debug.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 4fcbf4d4fd0a..5231aaf361c4 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -124,7 +124,7 @@ struct _ddebug_info {
struct ddebug_class_param {
union {
unsigned long *bits;
- unsigned int *lvl;
+ unsigned long *lvl;
};
char flags[8];
const struct ddebug_class_map *map;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index ceb3067a5c83..b984ce338921 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -796,7 +796,7 @@ int param_get_dyndbg_classes(char *buffer, const struct
kernel_param *kp)
case DD_CLASS_TYPE_LEVEL_NAMES:
case DD_CLASS_TYPE_LEVEL_NUM:
- return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
+ return scnprintf(buffer, PAGE_SIZE, "%ld\n", *dcp->lvl);
default:
return -1;
}
--
2.41.0
[Intel-gfx] [PATCH v7b 05/25] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.
bash-5.2# lsmod
Module Size Used by
i915 3133440 0
drm_buddy 20480 1 i915
ttm90112 1 i915
i2c_algo_bit 16384 1 i915
video 61440 1 i915
wmi32768 1 video
drm_display_helper200704 1 i915
drm_kms_helper208896 2 drm_display_helper,i915
drm 606208 5
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344 2 drm_display_helper,i915
---
lib/dynamic_debug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a3be2e7c8c84..ba41fdeaaf98 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -601,7 +601,8 @@ static int ddebug_exec_queries(char *query, const char
*modname)
/* apply a new bitmap to the sys-knob's current bit-state */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long
*old_bits)
+unsigned long *new_bits, unsigned long
*old_bits,
+const char *query_modname)
{
#define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -609,7 +610,8 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
- v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
+ v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
+ query_modname ?: "");
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -618,12 +620,15 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s",
map->class_names[bi],
test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
- ct = ddebug_exec_queries(query, NULL);
+ ct = ddebug_exec_queries(query, query_modname);
matches += ct;
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
ct, map->class_names[bi], *new_bits);
}
+ v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
+ query_modname ?: "");
+
return matches;
}
@@ -679,7 +684,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
- totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp),
cls_id,
map->class_names[cls_id]);
@@ -689,7 +694,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0
));
- totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n",
KP_NAME(kp), cls_id,
map->class_names[cls_id], old_bits,
curr_bits);
@@ -752,7 +757,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+ totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -765,7 +770,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
NULL);
[Intel-gfx] [PATCH v7b 01/25] test-dyndbg: fixup CLASSMAP usage error
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class
unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. I intentionally coded in an error, but
forgot to verify its detection and remove it.
RFC:
This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone. As noted in test-mod comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__. Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.
[1] name changes later to DYNDBG_CLASSMAP_DEFINE
Signed-off-by: Jim Cromie
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.41.0
[Intel-gfx] [PATCH v7b 02/25] dyndbg: reword "class unknown, " to "class:_UNKNOWN_"
This appears in the control-file to report an unknown class-name, which indicates that the class_id is not authorized, and dyndbg will ignore changes to it. Generally, this means that a DYNDBG_CLASSMAP_DEFINE or DYNDBG_CLASSMAP_USE is missing. But the word "unknown" appears in quite a few prdbg formats, so thats a suboptimal search term to find occurrences of the problem. Thus change it to "_UNKNOWN_" which properly shouts the condition. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 6fba6423cc10..ceb3067a5c83 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -1151,7 +1151,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p) if (class) seq_printf(m, " class:%s", class); else - seq_printf(m, " class unknown, _id:%d", dp->class_id); + seq_printf(m, " class:_UNKNOWN_ _id:%d", dp->class_id); } seq_puts(m, "\n"); -- 2.41.0
[Intel-gfx] [PATCH v7b 00/25] fix DRM_USE_DYNAMIC_DEBUG=y regression
hi Jason, DRM-folk (now with checkpatch fixes) This patchest fixes the chicken-egg initialization problem in the 1st version of ddebug-class-maps, that DRM-CI uncovered. The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K rule: "define once, refer many". In patch 14 it is replaced by: DYNDBG_CLASSMAP_DEFINE - define and export a struct ddebug_class_map DYNDBG_CLASSMAP_USE - ref the exported struct test-dynamic-debug is also extended with a -submod.ko, in order to recapitulate the drm & drivers initialization scenario. They're on v6.6-rc5 now, and apply cleanly to drm-tip/drm-tip. Ive been running recent revs on rc3+, on my desktop and laptop. The final blocker was a missing __align(8) on the ddebug_class_user record inserted by DYNDBG_CLASSMAP_USE. This caused DRM=y (builtin only) to have a corrupt record for drm_kms_helper (builtin dependent). Curiously, a clang build did not exhibit this problem. Heres a part of dmesg, for a DRM=y kernel, booted with dynamic_debug.verbose=3 drm.debug=0x10 [0.466747] dyndbg: add-module: drm 406 sites [0.467569] dyndbg: classes[0]: module:drm base:0 len:10 type:DISJOINT_BITS [0.467743] dyndbg: module:drm attached 1 classes [0.468557] dyndbg: builtin class: module:drm base:0 len:10 type:DISJOINT_BITS [0.468742] dyndbg: found kp:drm.debug =0x10 [0.468743] dyndbg: mapped to: module:drm base:0 len:10 type:DISJOINT_BITS [0.469742] dyndbg: drm.debug: classbits: 0x10 [0.470573] dyndbg: apply bitmap: 0x10 to: 0x0 for drm [0.470743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm [0.471743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p" [0.472743] dyndbg: op='+' flags=0x1 maskp=0x [0.473679] dyndbg: parsed: func="" file="" module="drm" format="" lineno=0-0 class=DRM_UT_ATOMIC [0.473749] dyndbg: processed 1 queries, with 0 matches, 0 errs [0.474742] dyndbg: bit_4: 0 matches on class: DRM_UT_ATOMIC -> 0x10 [0.475742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm [0.476686] dyndbg: 406 debug prints in module drm [0.476743] dyndbg: add-module: drm_kms_helper 93 sites [0.477727] dyndbg: class_ref[0] drm_kms_helper -> drm module:drm base:0 len:10 type:DISJOINT_BITS [0.477743] dyndbg: builtin class: module:drm base:0 len:10 type:DISJOINT_BITS [0.478742] dyndbg: found kp:drm.debug =0x10 [0.478743] dyndbg: mapped to: module:drm base:0 len:10 type:DISJOINT_BITS [0.479743] dyndbg: drm.debug: classbits: 0x10 [0.480592] dyndbg: apply bitmap: 0x10 to: 0x0 for drm_kms_helper [0.480743] dyndbg: query 0: "class DRM_UT_ATOMIC +p" mod:drm_kms_helper [0.481743] dyndbg: split into words: "class" "DRM_UT_ATOMIC" "+p" [0.482743] dyndbg: op='+' flags=0x1 maskp=0x [0.483743] dyndbg: parsed: func="" file="" module="drm_kms_helper" format="" lineno=0-0 class=DRM_UT_ATOMIC [0.484750] dyndbg: class-ref: drm_kms_helper.DRM_UT_ATOMIC module:drm_kms_helper nd:93 nc:0 nu:1 [0.485809] dyndbg: processed 1 queries, with 44 matches, 0 errs [0.486742] dyndbg: bit_4: 44 matches on class: DRM_UT_ATOMIC -> 0x10 [0.487742] dyndbg: applied bitmap: 0x10 to: 0x0 for drm_kms_helper [0.488743] dyndbg: attach-client-module: module:drm_kms_helper nd:93 nc:0 nu:1 [0.489742] dyndbg: 93 debug prints in module drm_kms_helper Widespread testing is appreciated. I have scripts if anyone wants them. I'll forward lkp-robot reports here when I get them. Patches also at https://github.com/jimc/linux (dd-fix-7b) Jim Cromie (25): test-dyndbg: fixup CLASSMAP usage error dyndbg: reword "class unknown," to "class:_UNKNOWN_" dyndbg: make ddebug_class_param union members same size dyndbg: replace classmap list with a vector dyndbg: ddebug_apply_class_bitmap - add module arg, select on it dyndbg: split param_set_dyndbg_classes to module/wrapper fns dyndbg: drop NUM_TYPE_ARRAY dyndbg: reduce verbose/debug clutter dyndbg: silence debugs with no-change updates dyndbg: tighten ddebug_class_name() 1st arg type dyndbg: tighten fn-sig of ddebug_apply_class_bitmap dyndbg: reduce verbose=3 messages in ddebug_add_module dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression dyndbg: add for_each_boxed_vector dyndbg: refactor ddebug_classparam_clamp_input dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API dyndbg-doc: add classmap info to howto dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP dyndbg: refactor *dynamic_emit_prefix dyndbg: change WARN_ON to WARN_ON_ONCE drm: use correct ccflags-y spelling drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN .../admin-guide/dynamic-debug-howto.rst | 60 ++- MAINTAINERS | 2 +- drivers/gpu/drm/Kconfig | 3 +-
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: DPLL code cleanups (rev2)
== Series Details == Series: drm/i915: DPLL code cleanups (rev2) URL : https://patchwork.freedesktop.org/series/125052/ 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.IGT: failure for Frontbuffer tracking preparing for Xe (rev2)
== Series Details == Series: Frontbuffer tracking preparing for Xe (rev2) URL : https://patchwork.freedesktop.org/series/125033/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_125033v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125033v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125033v2_full, please notify your bug team (lgci.bug.fil...@intel.com) 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_125033v2_full: ### IGT changes ### Possible regressions * igt@kms_cursor_crc@cursor-suspend@pipe-d-hdmi-a-3: - shard-dg2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg2-5/igt@kms_cursor_crc@cursor-susp...@pipe-d-hdmi-a-3.html * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1: - shard-apl: [PASS][2] -> [FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-apl6/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-apl7/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html Known issues Here are the changes found in Patchwork_125033v2_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][4] ([i915#8411]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg2-5/igt@api_intel...@object-reloc-keep-cache.html * igt@device_reset@unbind-cold-reset-rebind: - shard-dg1: NOTRUN -> [SKIP][5] ([i915#7701]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg1-17/igt@device_re...@unbind-cold-reset-rebind.html * igt@drm_fdinfo@busy@ccs0: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#8414]) +11 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg2-1/igt@drm_fdinfo@b...@ccs0.html * igt@gem_busy@semaphore: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#3936]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg2-3/igt@gem_b...@semaphore.html * igt@gem_ctx_persistence@heartbeat-many: - shard-dg2: NOTRUN -> [SKIP][8] ([i915#8555]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg2-5/igt@gem_ctx_persiste...@heartbeat-many.html * igt@gem_exec_balancer@bonded-false-hang: - shard-dg2: NOTRUN -> [SKIP][9] ([i915#4812]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg2-1/igt@gem_exec_balan...@bonded-false-hang.html * igt@gem_exec_balancer@invalid-bonds: - shard-dg2: NOTRUN -> [SKIP][10] ([i915#4036]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg2-1/igt@gem_exec_balan...@invalid-bonds.html * igt@gem_exec_balancer@noheartbeat: - shard-dg1: NOTRUN -> [SKIP][11] ([i915#8555]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-dg1-17/igt@gem_exec_balan...@noheartbeat.html - shard-mtlp: NOTRUN -> [SKIP][12] ([i915#8555]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-mtlp-3/igt@gem_exec_balan...@noheartbeat.html * igt@gem_exec_fair@basic-deadline: - shard-rkl: [PASS][13] -> [FAIL][14] ([i915#2846]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-rkl-7/igt@gem_exec_f...@basic-deadline.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@rcs0: - shard-glk: NOTRUN -> [FAIL][15] ([i915#2842]) +2 other tests fail [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-glk6/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-rkl: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-rkl-6/igt@gem_exec_fair@basic-p...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-rkl-2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13749/shard-glk7/igt@gem_exec_fair@basic-p...@vecs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125033v2/shard-glk5/igt@gem_exec_fair@basic-p...@vecs0.html *
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move the g45 PEG band gap HPD workaround to the HPD code (rev2)
== Series Details == Series: drm/i915: Move the g45 PEG band gap HPD workaround to the HPD code (rev2) URL : https://patchwork.freedesktop.org/series/125053/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125053v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125053v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125053v2, please notify your bug team (lgci.bug.fil...@intel.com) 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_125053v2/index.html Participating hosts (38 -> 36) -- Additional (2): fi-kbl-soraka fi-hsw-4770 Missing(4): bat-dg2-9 fi-bsw-n3050 fi-snb-2520m fi-pnv-d510 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125053v2: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - bat-dg2-11: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_125053v2 that come from known issues: ### CI changes ### Issues hit * boot: - fi-hsw-4770:NOTRUN -> [FAIL][3] ([i915#8293]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/fi-hsw-4770/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-6: NOTRUN -> [SKIP][4] ([i915#9318]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - bat-adlp-6: NOTRUN -> [SKIP][7] ([i915#3282]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-adlp-6/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [PASS][9] -> [ABORT][10] ([i915#9414]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-6: NOTRUN -> [SKIP][11] ([i915#4103] / [i915#5608]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271]) +9 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/fi-kbl-soraka/igt@kms_...@dsc-basic.html - bat-adlp-6: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#3840]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-adlp-6/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-adlp-6: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][15] -> [ABORT][16] ([i915#8668]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html Possible fixes * igt@i915_module_load@load: - bat-adlp-6: [INCOMPLETE][17] ([i915#8449]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-adlp-6/igt@i915_module_l...@load.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125053v2/bat-adlp-6/igt@i915_module_l...@load.html
[Intel-gfx] [PATCH v15 4/7] drm/i915: No TLB invalidation on suspended GT
In case of GT is suspended, don't allow submission of new TLB invalidation
request and cancel all pending requests. The TLB entries will be
invalidated either during GuC reload or on system resume.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 24 ---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 ++
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 0949628d69f8b..2b6dfe62c8f2a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -537,4 +537,5 @@ int intel_guc_invalidate_tlb_engines(struct intel_guc *guc);
int intel_guc_invalidate_tlb_guc(struct intel_guc *guc);
int intel_guc_tlb_invalidation_done(struct intel_guc *guc,
const u32 *payload, u32 len);
+void wake_up_all_tlb_invalidate(struct intel_guc *guc);
#endif
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 9ec6e80b258c4..1b04b1692e48d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1796,6 +1796,20 @@ static void __guc_reset_context(struct intel_context
*ce, intel_engine_mask_t st
intel_context_put(parent);
}
+void wake_up_all_tlb_invalidate(struct intel_guc *guc)
+{
+ struct intel_guc_tlb_wait *wait;
+ unsigned long i;
+
+ if (!intel_guc_tlb_invalidation_is_available(guc))
+ return;
+
+ xa_lock_irq(>tlb_lookup);
+ xa_for_each(>tlb_lookup, i, wait)
+ wake_up(>wq);
+ xa_unlock_irq(>tlb_lookup);
+}
+
void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t
stalled)
{
struct intel_context *ce;
@@ -1925,9 +1939,6 @@ void intel_guc_submission_cancel_requests(struct
intel_guc *guc)
void intel_guc_submission_reset_finish(struct intel_guc *guc)
{
- struct intel_guc_tlb_wait *wait;
- long unsigned int i;
-
/* Reset called during driver load or during wedge? */
if (unlikely(!guc_submission_initialized(guc) ||
intel_gt_is_wedged(guc_to_gt(guc {
@@ -1951,12 +1962,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
*guc)
* The full GT reset will have cleared the TLB caches and flushed the
* G2H message queue; we can release all the blocked waiters.
*/
- if (intel_guc_tlb_invalidation_is_available(guc)) {
- xa_lock_irq(>tlb_lookup);
- xa_for_each(>tlb_lookup, i, wait)
- wake_up(>wq);
- xa_unlock_irq(>tlb_lookup);
- }
+ wake_up_all_tlb_invalidate(guc);
}
static void destroyed_worker_func(struct work_struct *w);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 98b103375b7ab..27f6561dd7319 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -688,6 +688,8 @@ void intel_uc_suspend(struct intel_uc *uc)
/* flush the GSC worker */
intel_gsc_uc_flush_work(>gsc);
+ wake_up_all_tlb_invalidate(guc);
+
if (!intel_guc_is_ready(guc)) {
guc->interrupts.enabled = false;
return;
@@ -736,6 +738,11 @@ static int __uc_resume(struct intel_uc *uc, bool
enable_communication)
intel_gsc_uc_resume(>gsc);
+ if (intel_guc_tlb_invalidation_is_available(guc)) {
+ intel_guc_invalidate_tlb_engines(guc);
+ intel_guc_invalidate_tlb_guc(guc);
+ }
+
return 0;
}
--
2.25.1
[Intel-gfx] [PATCH v15 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
From: Prathap Kumar Valsan
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table. The invalidation is submitted as
a wait request and is performed in the CT event handler. This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.
With this new invalidation routine, we can perform GuC-based GGTT
invalidations. GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.
The additional complexity incurred in this patch will be necessary for
range-based tlb invalidations, which will be platformed in the future.
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Bruce Chang
Signed-off-by: Chris Wilson
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Jonathan Cavitt
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Fei Yang
CC: Andi Shyti
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 ++-
drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33 +++
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 22 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 197 +-
7 files changed, 299 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632b..1c93e84278a03 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -206,22 +206,36 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
}
+static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ intel_wakeref_t wakeref;
+
+ with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
+ struct intel_guc *guc = >uc.guc;
+
+ intel_guc_invalidate_tlb_guc(guc);
+ }
+}
+
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
+ struct intel_gt *gt;
gen8_ggtt_invalidate(ggtt);
- if (GRAPHICS_VER(i915) >= 12) {
- struct intel_gt *gt;
-
- list_for_each_entry(gt, >gt_list, ggtt_link)
+ list_for_each_entry(gt, >gt_list, ggtt_link) {
+ if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
+ guc_ggtt_ct_invalidate(gt);
+ } else if (GRAPHICS_VER(i915) >= 12) {
intel_uncore_write_fw(gt->uncore,
GEN12_GUC_TLB_INV_CR,
GEN12_GUC_TLB_INV_CR_INVALIDATE);
- } else {
- intel_uncore_write_fw(ggtt->vm.gt->uncore,
- GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ } else {
+ intel_uncore_write_fw(gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ }
}
}
@@ -1243,7 +1257,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.raw_insert_page = gen8_ggtt_insert_page;
}
- if (intel_uc_wants_guc(>vm.gt->uc))
+ if (intel_uc_wants_guc_submission(>vm.gt->uc))
ggtt->invalidate = guc_ggtt_invalidate;
else
ggtt->invalidate = gen8_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index 139608c30d978..4bb13d1890e37 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -12,6 +12,7 @@
#include "intel_gt_print.h"
#include "intel_gt_regs.h"
#include "intel_tlb.h"
+#include "uc/intel_guc.h"
/*
* HW architecture suggest typical invalidation time at 40us,
@@ -131,11 +132,24 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
u32 seqno)
return;
with_intel_gt_pm_if_awake(gt, wakeref) {
+ struct intel_guc *guc = >uc.guc;
+
mutex_lock(>tlb.invalidate_lock);
if (tlb_seqno_passed(gt, seqno))
goto unlock;
- mmio_invalidate_full(gt);
+ if
[Intel-gfx] [PATCH v15 5/7] drm/i915: No TLB invalidation on wedged GT
It is not an error for GuC TLB invalidations to fail when the GT is
wedged or disabled, so do not process a wait failure as one in
guc_send_invalidate_tlb.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
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 1b04b1692e48d..c67628f238588 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -32,6 +32,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
+#include "i915_irq.h"
#include "i915_trace.h"
/**
@@ -1935,6 +1936,12 @@ void intel_guc_submission_cancel_requests(struct
intel_guc *guc)
/* GuC is blown away, drop all references to contexts */
xa_destroy(>context_lookup);
+
+ /*
+* Wedged GT won't respond to any TLB invalidation request. Simply
+* release all the blocked waiters.
+*/
+ wake_up_all_tlb_invalidate(guc);
}
void intel_guc_submission_reset_finish(struct intel_guc *guc)
@@ -4749,6 +4756,14 @@ static long must_wait_woken(struct wait_queue_entry
*wq_entry, long timeout)
return timeout;
}
+static bool intel_gt_is_enabled(const struct intel_gt *gt)
+{
+ /* Check if GT is wedged or suspended */
+ if (intel_gt_is_wedged(gt) || !intel_irqs_enabled(gt->i915))
+ return false;
+ return true;
+}
+
static int guc_send_invalidate_tlb(struct intel_guc *guc,
enum intel_guc_tlb_invalidation_type type)
{
@@ -4798,7 +4813,8 @@ static int guc_send_invalidate_tlb(struct intel_guc *guc,
if (err)
goto out;
- if (!must_wait_woken(, intel_guc_ct_max_queue_time_jiffies())) {
+ if (intel_gt_is_enabled(guc_to_gt(guc)) &&
+ !must_wait_woken(, intel_guc_ct_max_queue_time_jiffies())) {
guc_err(guc,
"TLB invalidation response timed out for seqno %u\n",
seqno);
err = -ETIME;
--
2.25.1
[Intel-gfx] [PATCH v15 1/7] drm/i915: Add GuC TLB Invalidation device info flags
Add device info flags for if GuC TLB Invalidation is enabled.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cb60fc9cf8737..6a2a78c61f212 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -794,6 +794,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GUC_DEPRIVILEGE(i915) \
(INTEL_INFO(i915)->has_guc_deprivilege)
+#define HAS_GUC_TLB_INVALIDATION(i915)
(INTEL_INFO(i915)->has_guc_tlb_invalidation)
+
#define HAS_3D_PIPELINE(i915) (INTEL_INFO(i915)->has_3d_pipeline)
#define HAS_ONE_EU_PER_FUSE_BIT(i915)
(INTEL_INFO(i915)->has_one_eu_per_fuse_bit)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 39817490b13fd..eba2f0b919c87 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -153,6 +153,7 @@ enum intel_ppgtt_type {
func(has_heci_pxp); \
func(has_heci_gscfi); \
func(has_guc_deprivilege); \
+ func(has_guc_tlb_invalidation); \
func(has_l3_ccs_read); \
func(has_l3_dpf); \
func(has_llc); \
--
2.25.1
[Intel-gfx] [PATCH v15 6/7] drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck
For the gt_tlb live selftest, when operating on the GSC engine,
increase the timeout from 10 ms to 200 ms because the GSC
engine is a bit slower than the rest.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/selftest_tlb.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_tlb.c
b/drivers/gpu/drm/i915/gt/selftest_tlb.c
index 7e41f69fc818f..00b872b6380b1 100644
--- a/drivers/gpu/drm/i915/gt/selftest_tlb.c
+++ b/drivers/gpu/drm/i915/gt/selftest_tlb.c
@@ -136,8 +136,15 @@ pte_tlbinv(struct intel_context *ce,
i915_request_get(rq);
i915_request_add(rq);
- /* Short sleep to sanitycheck the batch is spinning before we begin */
- msleep(10);
+ /*
+* Short sleep to sanitycheck the batch is spinning before we begin.
+* FIXME: Why is GSC so slow?
+*/
+ if (ce->engine->class == OTHER_CLASS)
+ msleep(200);
+ else
+ msleep(10);
+
if (va == vb) {
if (!i915_request_completed(rq)) {
pr_err("%s(%s): Semaphore sanitycheck failed %llx, with
alignment %llx, using PTE size %x (phys %x, sg %x)\n",
--
2.25.1
[Intel-gfx] [PATCH v15 7/7] drm/i915: Enable GuC TLB invalidations for MTL
Enable GuC TLB invalidations for MTL. Though more platforms than just
MTL support GuC TLB invalidations, MTL is presently the only platform
that requires it for any purpose, so only enable it there for now to
minimize cross-platform impact.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index df7c261410f79..d4b51ececbb12 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -829,6 +829,7 @@ static const struct intel_device_info mtl_info = {
.has_flat_ccs = 0,
.has_gmd_id = 1,
.has_guc_deprivilege = 1,
+ .has_guc_tlb_invalidation = 1,
.has_llc = 0,
.has_mslice_steering = 0,
.has_snoop = 1,
--
2.25.1
[Intel-gfx] [PATCH v15 2/7] drm/i915/guc: Add CT size delay helper
As of now, there is no mechanism for tracking a given request's
progress through the queue. Instead, add a helper that returns
an estimated maximum time the queue should take to drain if
completely full.
Suggested-by: John Harrison
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 27 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index c33210ead1ef7..03b616ba4ebb7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -103,6 +103,33 @@ enum { CTB_SEND = 0, CTB_RECV = 1 };
enum { CTB_OWNER_HOST = 0 };
+/*
+ * Some H2G commands involve a synchronous response that the driver needs
+ * to wait for. In such cases, a timeout is required to prevent the driver
+ * from waiting forever in the case of an error (either no error response
+ * is defined in the protocol or something has died and requires a reset).
+ * The specific command may be defined as having a time bound response but
+ * the CT is a queue and that time guarantee only starts from the point
+ * when the command reaches the head of the queue and is processed by GuC.
+ *
+ * Ideally there would be a helper to report the progress of a given
+ * command through the CT. However, that would require a significant
+ * amount of work in the CT layer. In the meantime, provide a reasonable
+ * estimation of the worst case latency it should take for the entire
+ * queue to drain. And therefore, how long a caller should wait before
+ * giving up on their request. The current estimate is based on empirical
+ * measurement of a test that fills the buffer with context creation and
+ * destruction requests as they seem to be the slowest operation.
+ */
+long intel_guc_ct_max_queue_time_jiffies(void)
+{
+ /*
+* A 4KB buffer full of context destroy commands takes a little
+* over a second to process so bump that to 2s to be super safe.
+*/
+ return (CTB_H2G_BUFFER_SIZE * HZ) / SZ_2K;
+}
+
static void ct_receive_tasklet_func(struct tasklet_struct *t);
static void ct_incoming_request_worker_func(struct work_struct *w);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 58e42901ff498..2c4bb9a941be6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -104,6 +104,8 @@ struct intel_guc_ct {
#endif
};
+long intel_guc_ct_max_queue_time_jiffies(void);
+
void intel_guc_ct_init_early(struct intel_guc_ct *ct);
int intel_guc_ct_init(struct intel_guc_ct *ct);
void intel_guc_ct_fini(struct intel_guc_ct *ct);
--
2.25.1
[Intel-gfx] [PATCH v15 0/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
Implement GuC-based TLB invalidations and use them on MTL. Some complexity in the implementation was introduced early on and will be required for range-based TLB invalidations. RFC: https://patchwork.freedesktop.org/series/124922/ v2: - Add missing supporting patches. v3: - Split suspend/resume changes and multi-gt support into separate patches. - Only perform GuC TLB invalidation functions when supported. - Move intel_guc_is_enabled check function to usage location. - Address comments. v4: - Change conditions for GuC-based tlb invalidation support to a pci tag that's only active for MTL. - Address some FIXMEs and formatting issues. - Move suspend/resume changes to helper functions in intel_gt.h - Improve comment for ct_handle_event change. - Use cleaner if-else conditions. - Address comments. v5: - Reintroduce missing change to selftest msleep duration - Move suspend/resume loops from intel_gt.h to intel_tlb.c, making them no longer static inlines. - Remove superfluous blocking and error checks. - Move ct_handle_event exception to general case in ct_process_request. - Explain usage of xa_alloc_cyclic_irq. - Modify explanation of purpose of OUTSTANDING_GUC_TIMEOUT_PERIOD macro. - Explain purpose of performing tlb invalidation twice in intel_gt_tlb_resume_all. v6: - Add this cover letter. - Fix explanation of purpose of OUTSTANDING_GUC_TIMEOUT_PERIOD macro again. - s/pci tags/pci flags - Enable GuC TLB Invalidations separately from adding the flags to do so. v7: - Eliminate pci terminology from patches. - Order new device info flag correctly. - Run gen8_ggtt_invalidate in more cases, specifically when GuC-based TLB invalidation is not supported. - Use intel_uncore_write_fw instead of intel_uncore_write during guc_ggtt_invalidate. - Remove duplicate request message clear in ct_process_request. - Remove faulty tag from series. v8: - Simplify cover letter contents. - Fix miscellaneous formatting and typos. - Reorder device info flags and defines. - Reword commit message. - Rename TLB invalidation enums and functions. - Add comments explaining confusing points. - Add helper function getting expected delay of CT buffer. - Simplify intel_guc_tlb_invalidation_done by passing computed values. - Remove helper functions for tlb suspend and resume. - Move tlb suspend and resume paths to uc. - Split suspend/resume and wedged into two patches. - Clarify purpose of sleep change in tlb selftest. v9: - Explain complexity of GuC TLB invalidations as required for range-based TLB invalidations, which will be platformed later. - Fix CHECKPATCH issues. - Explain intel_guc_is_ready tlb invalidation skip in intel_gt_invalidate_tlb_full. - Reword comment for unlocked xa_for_each loop in intel_guc_submission_reset. - Report all errors in init_tlb_lookup. - Remove debug message from fini_tlb_lookup. - Use standardized interface for intel_guc_tlb_invalidation_done - Remove spurious changes. - Move wake_up_all_tlb_invalidate on wedge to correct patch. v10: - Add lock to tlb_lookup on guc submission reset. - Add comment about why timeout increased from 10 ms to 20 ms by default in gt_tlb selftest. - Remove spurious changes. v11: - Update CT size delay helper to be clearer. - Reorder some function declarations. - Clarify some comments. - Produce error message if attempting to free a busy wait during fini_tlb_lookup. - Revert default sleep back to 10 ms. - Link to RFC. v12: - Add helper for checking if GuC TLB invalidation is supported and guc is ready. - Prevent suspend/resume actions involving GuC TLB invalidations if guc is not ready. - Add path for INTEL_GUC_ACTION_TLB_INVALIDATION_DONE to immediately process in ct_process_request after it is submitted to ct_handle_event. v13: - Re-add error check in intel_guc_tlb_invalidation_done for invalid length. - Remove intel_guc_is_ready requirement from wake_up_all_tlb_invalidate. - Align patches 3 and 4 by adding a check for GuC TLB invalidation support to the former that was added in the latter. v14: - Re-add intel_guc_is_ready requirement to wake_up_all_tlb_invalidate. - Move wake_up_all_tlb_invalidate from intel_guc_submission_reset to the end of __uc_hw_init. - Remove gen8_ggtt_invalidate changes, as they aren't related to GuC TLB invalidation. - Add missing newline. v15: - Move wake_up_all_tlb_invalidate from __uc_hw_init to intel_guc_submission_reset_finish. - Change structure of wake_up_all_tlb_invalidate back to the way it was in v12, since it looks better and is functionally equivalent. - s/readd/re-add Jonathan Cavitt (6): drm/i915: Add GuC TLB Invalidation device info flags drm/i915/guc: Add CT size delay helper drm/i915: No TLB invalidation on suspended GT drm/i915: No TLB invalidation on wedged GT drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck drm/i915: Enable GuC TLB invalidations for MTL Prathap Kumar Valsan (1): drm/i915: Define and use GuC and CTB TLB invalidation
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bios: Clamp VBT HDMI level shift on BDW
== Series Details == Series: drm/i915/bios: Clamp VBT HDMI level shift on BDW URL : https://patchwork.freedesktop.org/series/125120/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125120v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125120v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125120v1, please notify your bug team (lgci.bug.fil...@intel.com) 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_125120v1/index.html Participating hosts (38 -> 37) -- Additional (2): fi-kbl-soraka fi-hsw-4770 Missing(3): bat-dg2-9 fi-snb-2520m fi-bsw-n3050 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_125120v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - bat-rpls-1: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-rpls-1/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_125120v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-6: NOTRUN -> [SKIP][3] ([i915#9318]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-adlp-6/igt@debugfs_t...@basic-hwmon.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_125120v1/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 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - bat-adlp-6: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-adlp-6/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [PASS][8] -> [ABORT][9] ([i915#9414]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@i915_selftest@l...@requests.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#5190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-6: NOTRUN -> [SKIP][11] ([i915#4103] / [i915#5608]) +1 other test skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271]) +9 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/fi-kbl-soraka/igt@kms_...@dsc-basic.html - bat-adlp-6: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#3840]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-adlp-6/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-adlp-6: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1: - fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271]) +12 other tests skip [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-adlp-9: NOTRUN -> [SKIP][16] ([i915#3546]) +2 other tests skip [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125120v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1: - fi-hsw-4770:NOTRUN -> [DMESG-WARN][17] ([i915#8841]) +6 other tests dmesg-warn [17]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush WC GGTT only on required platforms (rev2)
== Series Details ==
Series: drm/i915: Flush WC GGTT only on required platforms (rev2)
URL : https://patchwork.freedesktop.org/series/125111/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125111v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/index.html
Participating hosts (38 -> 37)
--
Additional (1): fi-kbl-soraka
Missing(2): fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_125111v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-6: NOTRUN -> [SKIP][1] ([i915#9318])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html
* igt@gem_exec_suspend@basic-s3@smem:
- bat-mtlp-8: [PASS][2] -> [ABORT][3] ([i915#8213] / [i915#9262])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-mtlp-8/igt@gem_exec_suspend@basic...@smem.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_125111v2/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
other tests skip
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- bat-adlp-6: NOTRUN -> [SKIP][6] ([i915#3282])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-adlp-6/igt@gem_tiled_pread_basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#5334] / [i915#7872])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-6: NOTRUN -> [SKIP][9] ([i915#4103] / [i915#5608]) +1
other test skip
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_dsc@dsc-basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271]) +9 other tests
skip
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/fi-kbl-soraka/igt@kms_...@dsc-basic.html
- bat-adlp-6: NOTRUN -> [SKIP][11] ([i915#3555] / [i915#3840])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-adlp-6/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-6: NOTRUN -> [SKIP][12] ([fdo#109285])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][13] ([i915#3546]) +2 other tests skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
Possible fixes
* igt@i915_module_load@load:
- bat-adlp-6: [INCOMPLETE][14] ([i915#8449]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-adlp-6/igt@i915_module_l...@load.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125111v2/bat-adlp-6/igt@i915_module_l...@load.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#5608]: https://gitlab.freedesktop.org/drm/intel/issues/5608
Re: [Intel-gfx] [PATCH] drm/i915/gem: Allow users to disable waitboost
On Thu, Sep 28, 2023 at 01:48:34PM +0100, Tvrtko Ursulin wrote:
>
> On 27/09/2023 20:34, Belgaumkar, Vinay wrote:
> >
> > On 9/21/2023 3:41 AM, Tvrtko Ursulin wrote:
> > >
> > > On 20/09/2023 22:56, Vinay Belgaumkar wrote:
> > > > Provide a bit to disable waitboost while waiting on a gem object.
> > > > Waitboost results in increased power consumption by requesting RP0
> > > > while waiting for the request to complete. Add a bit in the gem_wait()
> > > > IOCTL where this can be disabled.
> > > >
> > > > This is related to the libva API change here -
> > > > Link:
> > > > https://github.com/XinfengZhang/libva/commit/3d90d18c67609a73121bb71b20ee4776b54b61a7
> > >
> > > This link does not appear to lead to userspace code using this uapi?
> > We have asked Carl (cc'd) to post a patch for the same.
>
> Ack.
I'm glad to see that we will have the end-to-end flow of the high-level API.
>
> > > > Cc: Rodrigo Vivi
> > > > Signed-off-by: Vinay Belgaumkar
> > > > ---
> > > > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 9 ++---
> > > > drivers/gpu/drm/i915/i915_request.c | 3 ++-
> > > > drivers/gpu/drm/i915/i915_request.h | 1 +
> > > > include/uapi/drm/i915_drm.h | 1 +
> > > > 4 files changed, 10 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > > > index d4b918fb11ce..955885ec859d 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > > > @@ -72,7 +72,8 @@ i915_gem_object_wait_reservation(struct
> > > > dma_resv *resv,
> > > > struct dma_fence *fence;
> > > > long ret = timeout ?: 1;
> > > > - i915_gem_object_boost(resv, flags);
> > > > + if (!(flags & I915_WAITBOOST_DISABLE))
> > > > + i915_gem_object_boost(resv, flags);
> > > > dma_resv_iter_begin(, resv,
> > > > dma_resv_usage_rw(flags & I915_WAIT_ALL));
> > > > @@ -236,7 +237,7 @@ i915_gem_wait_ioctl(struct drm_device *dev,
> > > > void *data, struct drm_file *file)
> > > > ktime_t start;
> > > > long ret;
> > > > - if (args->flags != 0)
> > > > + if (args->flags != 0 || args->flags != I915_GEM_WAITBOOST_DISABLE)
> > > > return -EINVAL;
> > > > obj = i915_gem_object_lookup(file, args->bo_handle);
> > > > @@ -248,7 +249,9 @@ i915_gem_wait_ioctl(struct drm_device *dev,
> > > > void *data, struct drm_file *file)
> > > > ret = i915_gem_object_wait(obj,
> > > > I915_WAIT_INTERRUPTIBLE |
> > > > I915_WAIT_PRIORITY |
> > > > - I915_WAIT_ALL,
> > > > + I915_WAIT_ALL |
> > > > + (args->flags & I915_GEM_WAITBOOST_DISABLE ?
> > > > + I915_WAITBOOST_DISABLE : 0),
> > > > to_wait_timeout(args->timeout_ns));
> > > > if (args->timeout_ns > 0) {
> > > > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > > > b/drivers/gpu/drm/i915/i915_request.c
> > > > index f59081066a19..2957409b4b2a 100644
> > > > --- a/drivers/gpu/drm/i915/i915_request.c
> > > > +++ b/drivers/gpu/drm/i915/i915_request.c
> > > > @@ -2044,7 +2044,8 @@ long i915_request_wait_timeout(struct
> > > > i915_request *rq,
> > > > * but at a cost of spending more power processing the workload
> > > > * (bad for battery).
> > > > */
> > > > - if (flags & I915_WAIT_PRIORITY && !i915_request_started(rq))
> > > > + if (!(flags & I915_WAITBOOST_DISABLE) && (flags &
> > > > I915_WAIT_PRIORITY) &&
> > > > + !i915_request_started(rq))
> > > > intel_rps_boost(rq);
> > > > wait.tsk = current;
> > > > diff --git a/drivers/gpu/drm/i915/i915_request.h
> > > > b/drivers/gpu/drm/i915/i915_request.h
> > > > index 0ac55b2e4223..3cc00e8254dc 100644
> > > > --- a/drivers/gpu/drm/i915/i915_request.h
> > > > +++ b/drivers/gpu/drm/i915/i915_request.h
> > > > @@ -445,6 +445,7 @@ long i915_request_wait(struct i915_request *rq,
> > > > #define I915_WAIT_INTERRUPTIBLE BIT(0)
> > > > #define I915_WAIT_PRIORITY BIT(1) /* small priority bump
> > > > for the request */
> > > > #define I915_WAIT_ALL BIT(2) /* used by
> > > > i915_gem_object_wait() */
> > > > +#define I915_WAITBOOST_DISABLE BIT(3) /* used by
maybe name it I915_WAIT_NO_BOOST to align a bit better with the existent ones?
> > > > i915_gem_object_wait() */
> > > > void i915_request_show(struct drm_printer *m,
> > > > const struct i915_request *rq,
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 7000e5910a1d..4adee70e39cf 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -1928,6 +1928,7 @@ struct drm_i915_gem_wait {
> > > > /** Handle of BO we shall wait on */
> > > > __u32 bo_handle;
> > > > __u32 flags;
> > > > +#define
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix LUT rounding
== Series Details ==
Series: drm/i915: Fix LUT rounding
URL : https://patchwork.freedesktop.org/series/125116/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125116v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125116v1/index.html
Participating hosts (38 -> 37)
--
Additional (1): fi-hsw-4770
Missing(2): fi-snb-2520m fi-bsw-n3050
Known issues
Here are the changes found in Patchwork_125116v1 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-hsw-4770:NOTRUN -> [FAIL][1] ([i915#8293])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125116v1/fi-hsw-4770/boot.html
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- bat-mtlp-8: [PASS][2] -> [ABORT][3] ([i915#9414])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125116v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence:
- bat-adlp-9: NOTRUN -> [SKIP][4] ([i915#3546]) +2 other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125116v1/bat-adlp-9/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293
[i915#8981]: https://gitlab.freedesktop.org/drm/intel/issues/8981
[i915#9414]: https://gitlab.freedesktop.org/drm/intel/issues/9414
Build changes
-
* Linux: CI_DRM_13754 -> Patchwork_125116v1
CI-20190529: 20190529
CI_DRM_13754: 3801f98312c4ae0e31edc6dc69eced1dabbcc694 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7539: 08e87a32fa113a9b6f30cbd9766fec346b53faac @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_125116v1: 3801f98312c4ae0e31edc6dc69eced1dabbcc694 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
ad8bcec7cdae drm/i915: Fix glk+ degamma LUT conversions
80bd0a58069a drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack()
8ef271f2553d drm/i915: Adjust LUT rounding rules
8467a7fa92fe drm: Fix color LUT rounding
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125116v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix LUT rounding
== Series Details == Series: drm/i915: Fix LUT rounding URL : https://patchwork.freedesktop.org/series/125116/ 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: Fix LUT rounding
== Series Details == Series: drm/i915: Fix LUT rounding URL : https://patchwork.freedesktop.org/series/125116/ State : warning == Summary == Error: dim checkpatch failed e6e1f586ce6d drm: Fix color LUT rounding b3b1eb0a523e drm/i915: Adjust LUT rounding rules a0073c74c274 drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack() 8e551577c2a7 drm/i915: Fix glk+ degamma LUT conversions -:42: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #42: FILE: drivers/gpu/drm/i915/display/intel_color.c:1537: + entry->red = entry->green = entry->blue = min(val, 0xu); -:54: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #54: FILE: drivers/gpu/drm/i915/display/intel_color.c:1548: + entry->red = entry->green = entry->blue = total: 0 errors, 0 warnings, 2 checks, 79 lines checked
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Reset message bus after each read/write operation
On Fri, Oct 13, 2023 at 09:55:32AM +0300, Mika Kahola wrote:
> Every know and then we receive the following error when running
> for example IGT test kms_flip.
>
> [drm] *ERROR* PHY G Read 0d80 failed after 3 retries.
> [drm] *ERROR* PHY G Write 0d81 failed after 3 retries.
>
> Since the error is sporadic in nature, the patch proposes
> to reset the message bus after every successful or unsuccessful
> read or write operation. However, the testing revealed that this
> alone is not sufficient method and therefore an additional
> delay is introduced anything from 200us to 300us to let HW to
> settle down. This delay is experimental value and has no
> specification to back it up.
>
> v2: Add FIXME's to indicate the experimental nature of
> this workaround (Rodrigo)
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 6e6a1818071e..7c48ec5e54bd 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -221,6 +221,14 @@ static u8 __intel_cx0_read(struct drm_i915_private
> *i915, enum port port,
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_read_once(i915, port, lane, addr);
>
> + /*
> + * FIXME: Workaround to let HW to settle
> + * down and let the message bus to end up
> + * in a known state
> + */
> + intel_cx0_bus_reset(i915, port, lane);
> + usleep_range(200, 300);
> +
> if (status >= 0)
> return status;
> }
> @@ -300,6 +308,14 @@ static void __intel_cx0_write(struct drm_i915_private
> *i915, enum port port,
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_write_once(i915, port, lane, addr, data,
> committed);
>
> + /*
> + * FIXME: Workaround to let HW to settle
> + * down and let the message bus to end up
> + * in a known state
> + */
> + intel_cx0_bus_reset(i915, port, lane);
> + usleep_range(200, 300);
what cases trigger these paths?
and how many calls in the modset case?
what about suspend/resume cylces?
if we do a single rmw we are introducing at least 400us of delay here.
have we measured the overall final impact of these extra sleeps on the resume
and modeset latencies?
> +
> if (status == 0)
> return;
> }
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH v14 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
Hi John,
...
> > @@ -560,6 +562,17 @@ static int __uc_init_hw(struct intel_uc *uc)
> > guc_info(guc, "submission %s\n",
> > str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
> > guc_info(guc, "SLPC %s\n",
> > str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
> > + /*
> > +* The full GT reset will have cleared the TLB caches and flushed the
> > +* G2H message queue; we can release all the blocked waiters.
> > +*/
> > + if (intel_guc_tlb_invalidation_is_available(guc)) {
> > + xa_lock_irq(>tlb_lookup);
> > + xa_for_each(>tlb_lookup, i, wait)
> > + wake_up(>wq);
> > + xa_unlock_irq(>tlb_lookup);
> > + }
> > +
> This is not the right place for this. This is an init function but this
> comment is talking about resets and is doing things that assume the system
> has been running for some time.
>
> Yes, hw init might happen as part of a reset but this is reset only
> processing and it should be in a reset specific code path.
>
> What was wrong with the previous version that had the code in
> intel_guc_submission_reset?
It was wrongly placed there because at that point the gt reset
was not totally complete but it was still mid-way through.
The threads needed a bit more time in order to wait for the GT to
be completely alive after the reset.
The works need to be woken up at the end of the gt reset, where,
besides, we need to clear up the xa_array with work queues.
First Jonathan added it in driectly at the end of the
intel_gt_reset(), but that's not the right place as this is a UC
related operation, rather than GT.
Following the reset flow this looked like the right place, called
after the reset in the UC part.
What's wrong with placing it it here?
Andi
Re: [Intel-gfx] [PATCH v14 0/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
On 10/13/2023 10:52, Jonathan Cavitt wrote: Implement GuC-based TLB invalidations and use them on MTL. Some complexity in the implementation was introduced early on and will be required for range-based TLB invalidations. RFC: https://patchwork.freedesktop.org/series/124922/ v2: - Add missing supporting patches. v3: - Split suspend/resume changes and multi-gt support into separate patches. - Only perform GuC TLB invalidation functions when supported. - Move intel_guc_is_enabled check function to usage location. - Address comments. v4: - Change conditions for GuC-based tlb invalidation support to a pci tag that's only active for MTL. - Address some FIXMEs and formatting issues. - Move suspend/resume changes to helper functions in intel_gt.h - Improve comment for ct_handle_event change. - Use cleaner if-else conditions. - Address comments. v5: - Reintroduce missing change to selftest msleep duration - Move suspend/resume loops from intel_gt.h to intel_tlb.c, making them no longer static inlines. - Remove superfluous blocking and error checks. - Move ct_handle_event exception to general case in ct_process_request. - Explain usage of xa_alloc_cyclic_irq. - Modify explanation of purpose of OUTSTANDING_GUC_TIMEOUT_PERIOD macro. - Explain purpose of performing tlb invalidation twice in intel_gt_tlb_resume_all. v6: - Add this cover letter. - Fix explanation of purpose of OUTSTANDING_GUC_TIMEOUT_PERIOD macro again. - s/pci tags/pci flags - Enable GuC TLB Invalidations separately from adding the flags to do so. v7: - Eliminate pci terminology from patches. - Order new device info flag correctly. - Run gen8_ggtt_invalidate in more cases, specifically when GuC-based TLB invalidation is not supported. - Use intel_uncore_write_fw instead of intel_uncore_write during guc_ggtt_invalidate. - Remove duplicate request message clear in ct_process_request. - Remove faulty tag from series. v8: - Simplify cover letter contents. - Fix miscellaneous formatting and typos. - Reorder device info flags and defines. - Reword commit message. - Rename TLB invalidation enums and functions. - Add comments explaining confusing points. - Add helper function getting expected delay of CT buffer. - Simplify intel_guc_tlb_invalidation_done by passing computed values. - Remove helper functions for tlb suspend and resume. - Move tlb suspend and resume paths to uc. - Split suspend/resume and wedged into two patches. - Clarify purpose of sleep change in tlb selftest. v9: - Explain complexity of GuC TLB invalidations as required for range-based TLB invalidations, which will be platformed later. - Fix CHECKPATCH issues. - Explain intel_guc_is_ready tlb invalidation skip in intel_gt_invalidate_tlb_full. - Reword comment for unlocked xa_for_each loop in intel_guc_submission_reset. - Report all errors in init_tlb_lookup. - Remove debug message from fini_tlb_lookup. - Use standardized interface for intel_guc_tlb_invalidation_done - Remove spurious changes. - Move wake_up_all_tlb_invalidate on wedge to correct patch. v10: - Add lock to tlb_lookup on guc submission reset. - Add comment about why timeout increased from 10 ms to 20 ms by default in gt_tlb selftest. - Remove spurious changes. v11: - Update CT size delay helper to be clearer. - Reorder some function declarations. - Clarify some comments. - Produce error message if attempting to free a busy wait during fini_tlb_lookup. - Revert default sleep back to 10 ms. - Link to RFC. v12: - Add helper for checking if GuC TLB invalidation is supported and guc is ready. - Prevent suspend/resume actions involving GuC TLB invalidations if guc is not ready. - Add path for INTEL_GUC_ACTION_TLB_INVALIDATION_DONE to immediately process in ct_process_request after it is submitted to ct_handle_event. v13: - Readd error check in intel_guc_tlb_invalidation_done for invalid length. - Remove intel_guc_is_ready requirement from wake_up_all_tlb_invalidate. - Align patches 3 and 4 by adding a check for GuC TLB invalidation support to the former that was added in the latter. v14: - Readd intel_guc_is_ready requirement to wake_up_all_tlb_invalidate. Can you please use 're-add'. It took me some time to realise this wasn't a typo for 'read' or 'ready'. - Move wake_up_all_tlb_invalidate from intel_guc_submission_reset to the end of __uc_hw_init. I can see that this change was done. But why? What was the problem with the previous version? How does this move fix it? Because an init specific function is not the correct place for reset specific code. John.
Re: [Intel-gfx] [PATCH v14 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
On 10/13/2023 10:52, Jonathan Cavitt wrote:
From: Prathap Kumar Valsan
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table. The invalidation is submitted as
a wait request and is performed in the CT event handler. This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.
With this new invalidation routine, we can perform GuC-based GGTT
invalidations. GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.
The additional complexity incurred in this patch will be necessary for
range-based tlb invalidations, which will be platformed in the future.
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Bruce Chang
Signed-off-by: Chris Wilson
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Jonathan Cavitt
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Fei Yang
CC: Andi Shyti
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 ++-
drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 22 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 13 ++
8 files changed, 298 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632b..1c93e84278a03 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -206,22 +206,36 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
}
+static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ intel_wakeref_t wakeref;
+
+ with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
+ struct intel_guc *guc = >uc.guc;
+
+ intel_guc_invalidate_tlb_guc(guc);
+ }
+}
+
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
+ struct intel_gt *gt;
gen8_ggtt_invalidate(ggtt);
- if (GRAPHICS_VER(i915) >= 12) {
- struct intel_gt *gt;
-
- list_for_each_entry(gt, >gt_list, ggtt_link)
+ list_for_each_entry(gt, >gt_list, ggtt_link) {
+ if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
+ guc_ggtt_ct_invalidate(gt);
+ } else if (GRAPHICS_VER(i915) >= 12) {
intel_uncore_write_fw(gt->uncore,
GEN12_GUC_TLB_INV_CR,
GEN12_GUC_TLB_INV_CR_INVALIDATE);
- } else {
- intel_uncore_write_fw(ggtt->vm.gt->uncore,
- GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ } else {
+ intel_uncore_write_fw(gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ }
}
}
@@ -1243,7 +1257,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.raw_insert_page = gen8_ggtt_insert_page;
}
- if (intel_uc_wants_guc(>vm.gt->uc))
+ if (intel_uc_wants_guc_submission(>vm.gt->uc))
ggtt->invalidate = guc_ggtt_invalidate;
else
ggtt->invalidate = gen8_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index 139608c30d978..4bb13d1890e37 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -12,6 +12,7 @@
#include "intel_gt_print.h"
#include "intel_gt_regs.h"
#include "intel_tlb.h"
+#include "uc/intel_guc.h"
/*
* HW architecture suggest typical invalidation time at 40us,
@@ -131,11 +132,24 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
u32 seqno)
return;
with_intel_gt_pm_if_awake(gt, wakeref) {
+ struct intel_guc *guc = >uc.guc;
+
mutex_lock(>tlb.invalidate_lock);
if
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prevent potential null-ptr-deref in engine_init_common (rev4)
== Series Details ==
Series: drm/i915: Prevent potential null-ptr-deref in engine_init_common (rev4)
URL : https://patchwork.freedesktop.org/series/124971/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13754 -> Patchwork_124971v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/index.html
Participating hosts (38 -> 37)
--
Additional (1): fi-hsw-4770
Missing(2): fi-snb-2520m fi-pnv-d510
Known issues
Here are the changes found in Patchwork_124971v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adlp-6: NOTRUN -> [SKIP][1] ([i915#9318])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/fi-hsw-4770/igt@debugfs_t...@basic-hwmon.html
* igt@gem_tiled_pread_basic:
- bat-adlp-6: NOTRUN -> [SKIP][3] ([i915#3282])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/bat-adlp-6/igt@gem_tiled_pread_basic.html
* igt@i915_selftest@live@requests:
- bat-mtlp-8: [PASS][4] -> [ABORT][5] ([i915#9414])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/bat-mtlp-8/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-6: NOTRUN -> [SKIP][6] ([i915#4103] / [i915#5608]) +1
other test skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_dsc@dsc-basic:
- bat-adlp-6: NOTRUN -> [SKIP][7] ([i915#3555] / [i915#3840])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/bat-adlp-6/igt@kms_...@dsc-basic.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-adlp-6: NOTRUN -> [SKIP][8] ([fdo#109285])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html
Possible fixes
* igt@i915_module_load@load:
- bat-adlp-6: [INCOMPLETE][9] ([i915#8449]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-adlp-6/igt@i915_module_l...@load.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/bat-adlp-6/igt@i915_module_l...@load.html
* igt@kms_frontbuffer_tracking@basic:
- fi-bsw-nick:[FAIL][11] ([i915#9276]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/fi-bsw-nick/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/fi-bsw-nick/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#5608]: https://gitlab.freedesktop.org/drm/intel/issues/5608
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#8449]: https://gitlab.freedesktop.org/drm/intel/issues/8449
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8981]: https://gitlab.freedesktop.org/drm/intel/issues/8981
[i915#9276]: https://gitlab.freedesktop.org/drm/intel/issues/9276
[i915#9318]: https://gitlab.freedesktop.org/drm/intel/issues/9318
[i915#9414]: https://gitlab.freedesktop.org/drm/intel/issues/9414
Build changes
-
* Linux: CI_DRM_13754 -> Patchwork_124971v4
CI-20190529: 20190529
CI_DRM_13754: 3801f98312c4ae0e31edc6dc69eced1dabbcc694 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7539: 08e87a32fa113a9b6f30cbd9766fec346b53faac @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_124971v4: 3801f98312c4ae0e31edc6dc69eced1dabbcc694 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
8d4f7a0690ae drm/i915: Prevent potential null-ptr-deref in engine_init_common
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124971v4/index.html
Re: [Intel-gfx] [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT
On 10/13/2023 12:12, John Harrison wrote:
On 10/13/2023 07:42, Cavitt, Jonathan wrote:
-Original Message-
From: Harrison, John C
Sent: Thursday, October 12, 2023 6:08 PM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Gupta, saurabhg ;
chris.p.wil...@linux.intel.com; Iddamsetty, Aravind
; Yang, Fei ;
Shyti, Andi ; Das, Nirmoy
; Krzysztofik, Janusz
; Roper, Matthew D
; tvrtko.ursu...@linux.intel.com;
jani.nik...@linux.intel.com
Subject: Re: [PATCH v13 4/7] drm/i915: No TLB invalidation on
suspended GT
On 10/12/2023 15:38, Jonathan Cavitt wrote:
In case of GT is suspended, don't allow submission of new TLB
invalidation
request and cancel all pending requests. The TLB entries will be
invalidated either during GuC reload or on system resume.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 22
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 ++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 0949628d69f8b..2b6dfe62c8f2a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -537,4 +537,5 @@ int intel_guc_invalidate_tlb_engines(struct
intel_guc *guc);
int intel_guc_invalidate_tlb_guc(struct intel_guc *guc);
int intel_guc_tlb_invalidation_done(struct intel_guc *guc,
const u32 *payload, u32 len);
+void wake_up_all_tlb_invalidate(struct intel_guc *guc);
#endif
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 1377398afcdfa..3a0d20064878a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1796,13 +1796,24 @@ static void __guc_reset_context(struct
intel_context *ce, intel_engine_mask_t st
intel_context_put(parent);
}
-void intel_guc_submission_reset(struct intel_guc *guc,
intel_engine_mask_t stalled)
+void wake_up_all_tlb_invalidate(struct intel_guc *guc)
{
struct intel_guc_tlb_wait *wait;
+ unsigned long i;
+
+ if (HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915)) {
Why the change from 'if(!is_available) return' to 'if(HAS_) {doStuff}'?
I feel like this question has two parts, so I'll answer them separately:
1. Why HAS_GUC_TLB_INVALIDATION and not
intel_guc_tlb_invalidation_is_available?
Wake_up_all_tlb_invalidate is called during the suspend/resume path,
specifically in the
middle of suspend. It's required for it to be called here to clean
up any invalidations left
in the queue during the suspend/resume phase because they are no
longer valid requests.
However, the suspend/resume phase also resets GuC, so
intel_guc_is_ready returns false.
In short, using intel_guc_invalidation_is_available was causing us to
skip this code section
incorrectly, resulting in spurious GuC TLB invalidation timeout
errors during gt reset.
I'm not following this argument. If a reset is occurring then there is
no need to issue the invalidate. And the previous version was skipping
if GuC is in reset but this version does not. Which means it is now
sending invalidate requests to GuC when GuC is not able to respond and
therefore more likely to cause timeout errors not less likely.
Hang on. I'm getting confused between sending the request and waking up
blocked threads. Apologies.
Okay, that makes sense now.
John.
Re: [Intel-gfx] [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT
On 10/13/2023 07:42, Cavitt, Jonathan wrote:
-Original Message-
From: Harrison, John C
Sent: Thursday, October 12, 2023 6:08 PM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com; Iddamsetty, Aravind
; Yang, Fei ; Shyti, Andi ;
Das, Nirmoy ; Krzysztofik, Janusz ; Roper, Matthew D
; tvrtko.ursu...@linux.intel.com; jani.nik...@linux.intel.com
Subject: Re: [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT
On 10/12/2023 15:38, Jonathan Cavitt wrote:
In case of GT is suspended, don't allow submission of new TLB invalidation
request and cancel all pending requests. The TLB entries will be
invalidated either during GuC reload or on system resume.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 22 ---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 ++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 0949628d69f8b..2b6dfe62c8f2a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -537,4 +537,5 @@ int intel_guc_invalidate_tlb_engines(struct intel_guc *guc);
int intel_guc_invalidate_tlb_guc(struct intel_guc *guc);
int intel_guc_tlb_invalidation_done(struct intel_guc *guc,
const u32 *payload, u32 len);
+void wake_up_all_tlb_invalidate(struct intel_guc *guc);
#endif
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 1377398afcdfa..3a0d20064878a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1796,13 +1796,24 @@ static void __guc_reset_context(struct intel_context
*ce, intel_engine_mask_t st
intel_context_put(parent);
}
-void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t stalled)
+void wake_up_all_tlb_invalidate(struct intel_guc *guc)
{
struct intel_guc_tlb_wait *wait;
+ unsigned long i;
+
+ if (HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915)) {
Why the change from 'if(!is_available) return' to 'if(HAS_) {doStuff}'?
I feel like this question has two parts, so I'll answer them separately:
1. Why HAS_GUC_TLB_INVALIDATION and not intel_guc_tlb_invalidation_is_available?
Wake_up_all_tlb_invalidate is called during the suspend/resume path,
specifically in the
middle of suspend. It's required for it to be called here to clean up any
invalidations left
in the queue during the suspend/resume phase because they are no longer valid
requests.
However, the suspend/resume phase also resets GuC, so intel_guc_is_ready
returns false.
In short, using intel_guc_invalidation_is_available was causing us to skip this
code section
incorrectly, resulting in spurious GuC TLB invalidation timeout errors during
gt reset.
I'm not following this argument. If a reset is occurring then there is
no need to issue the invalidate. And the previous version was skipping
if GuC is in reset but this version does not. Which means it is now
sending invalidate requests to GuC when GuC is not able to respond and
therefore more likely to cause timeout errors not less likely.
2. Why use a positive check to perform and not a negative check to skip?
In patch 3, wake_up_all_tlb_invalidate was originally called universally on all
platforms
during intel_guc_submission_reset, which is incorrect and not how was
reimplemented here.
I discovered this was the case and retroactively corrected it, as seen below.
Because of how intel_guc_submission_reset is structured, a negative check to
skip wouldn't
make much sense there, so I used a positive check to perform instead. This is
a holdover from
that implementation, and was kept to maintain consistency between patches 3 and
4. It's
probably not as big of a deal as I'm imagining, but I think it would be awkward
if the initial
implementation in intel_guc_submission_reset and the reimplementation in
wake_up_all_tlb_invalidate weren't superficially the same, even if they were
functionally
equivalent otherwise.
I would argue that a bunch of early exit conditions at the start of a
function is easy to read and maintain than adding nesting levels to the
entire function.
John.
-Jonathan Cavitt
John.
+ xa_lock_irq(>tlb_lookup);
+ xa_for_each(>tlb_lookup, i, wait)
+ wake_up(>wq);
+ xa_unlock_irq(>tlb_lookup);
+ }
+}
+
+void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t
stalled)
+{
struct intel_context *ce;
unsigned long index;
unsigned long flags;
-
Re: [Intel-gfx] [PATCH v13 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
On 10/13/2023 07:52, Cavitt, Jonathan wrote:
-Original Message-
From: Harrison, John C
Sent: Thursday, October 12, 2023 6:11 PM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com; Iddamsetty, Aravind
; Yang, Fei ; Shyti, Andi ;
Das, Nirmoy ; Krzysztofik, Janusz ; Roper, Matthew D
; tvrtko.ursu...@linux.intel.com; jani.nik...@linux.intel.com
Subject: Re: [PATCH v13 3/7] drm/i915: Define and use GuC and CTB TLB
invalidation routines
On 10/12/2023 15:38, Jonathan Cavitt wrote:
From: Prathap Kumar Valsan
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table. The invalidation is submitted as
a wait request and is performed in the CT event handler. This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.
With this new invalidation routine, we can perform GuC-based GGTT
invalidations. GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.
The additional complexity incurred in this patch will be necessary for
range-based tlb invalidations, which will be platformed in the future.
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Bruce Chang
Signed-off-by: Chris Wilson
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Jonathan Cavitt
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Fei Yang
CC: Andi Shyti
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 33 ++-
drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33 +++
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 22 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 195 +-
7 files changed, 299 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632b..7d145b2d3cb17 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -206,22 +206,37 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
}
+static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ intel_wakeref_t wakeref;
+
+ with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
+ struct intel_guc *guc = >uc.guc;
+
+ intel_guc_invalidate_tlb_guc(guc);
+ }
+}
+
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
+ struct intel_gt *gt;
- gen8_ggtt_invalidate(ggtt);
-
- if (GRAPHICS_VER(i915) >= 12) {
- struct intel_gt *gt;
+ if (!HAS_GUC_TLB_INVALIDATION(i915))
+ gen8_ggtt_invalidate(ggtt);
This has not changed? As per comments from Matthew Roper and Nirmoy Das,
there needs to be a fixup patch first to stop gen8_ggtt_invalidate()
from being called on invalid platforms.
Given the sounds of things, it seems like this change here is irrelevant to
this patch series, as the reason we're
guarding against gen8_ggtt_invalidate isn't related to GuC-based TLB
invalidations at all. Ergo, it would actually
make more sense for me to not skip it here and leave the respective guard
change to a different patch series.
-Jonathan Cavitt
The point was that if this code needs to change then that patch needs to
happen first. Otherwise there would be merge conflicts when pushing that
patch to the stable trees.
However, it looks like the change is all happening inside the gen8_
function and the intention is to keep calling it even on Gen12+
platforms that don't need it. Seems odd but people appear to be happy
with it. And therefore no conflicts should happen with this patch no
matter what order they land in.
John.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Reset message bus after each read/write operation (rev2)
== Series Details == Series: drm/i915/display: Reset message bus after each read/write operation (rev2) URL : https://patchwork.freedesktop.org/series/124602/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_124602v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/index.html Participating hosts (38 -> 38) -- Additional (1): fi-hsw-4770 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_124602v2 that come from known issues: ### CI changes ### Issues hit * boot: - fi-bsw-n3050: [PASS][1] -> [FAIL][2] ([i915#8293]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/fi-bsw-n3050/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/fi-bsw-n3050/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-6: NOTRUN -> [SKIP][3] ([i915#9318]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html * igt@gem_tiled_pread_basic: - bat-adlp-6: NOTRUN -> [SKIP][4] ([i915#3282]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/bat-adlp-6/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html - fi-glk-j4005: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [PASS][9] -> [ABORT][10] ([i915#9414]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-mtlp-8/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#5190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-6: NOTRUN -> [SKIP][12] ([i915#4103] / [i915#5608]) +1 other test skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/bat-adlp-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - bat-adlp-6: NOTRUN -> [SKIP][13] ([i915#3555] / [i915#3840]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/bat-adlp-6/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-adlp-6: NOTRUN -> [SKIP][14] ([fdo#109285]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/bat-adlp-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-a-vga-1: - fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271]) +12 other tests skip [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-n...@pipe-a-vga-1.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][16] -> [ABORT][17] ([i915#8668]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1: - fi-hsw-4770:NOTRUN -> [DMESG-WARN][18] ([i915#8841]) +6 other tests dmesg-warn [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/fi-hsw-4770/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-vga-1.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1072]) +3 other tests skip [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124602v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html Possible fixes * igt@i915_module_load@load: - bat-adlp-6: [INCOMPLETE][20] ([i915#8449]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13754/bat-adlp-6/igt@i915_module_l...@load.html [21]:
Re: [Intel-gfx] [PATCH] tests: save GPU engine information more properly
Hi Shawn,
without the i-g-t tag in the title this path was picked up by the
kernel's patchwork.
Can you please use the [PATCH i-g-t] tag?
On Fri, Oct 13, 2023 at 12:20:12PM +0800, Lee Shawn C wrote:
> We encounter a unexpected error on chrome book device while
> running kms_busy test. It will restore GPU engine's timeout
> value but open incorrect file name (XR24 in below).
>
> openat(AT_FDCWD, "/sys/dev/char/226:0", O_RDONLY) = 12
> openat(12, "dev", O_RDONLY) = 13
> read(13, "226:0\n", 1023) = 6
> close(13) = 0
> openat(12, "engine", O_RDONLY) = 13
> close(12) = 0
> openat(13, "XR24", O_RDONLY)= -1 ENOENT (No such file or
> directory)
>
> Test code did not save engine data properly to cause this problem.
> So modify the code to save GPU engine information into a globla variable
> to avoid test deamon to open incorrect file again.
>
> Issue: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/issues/147
> Fixes: 9e635a1c5029 ("tests/kms_busy: Ensure GPU reset when waiting
> for a new FB during modeset")
please don't break the Fixes: line.
Andi
[Intel-gfx] [CI] PR for new GuC v70.13.1
The following changes since commit 7727f7e3b3358713c7c91c64a835e80c331a6b8b: Merge branch 'patch-1696561325' into 'main' (2023-10-06 03:04:57 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_70.13.1 for you to fetch changes up to 44a9510c94ac0334931b6c89dd240ffe5bf1e5fa: i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL (2023-10-13 11:34:26 -0700) John Harrison (1): i915: Add GuC v70.13.1 for DG2, TGL, ADL-P and MTL WHENCE | 8 i915/adlp_guc_70.bin | Bin 297984 -> 342848 bytes i915/dg2_guc_70.bin | Bin 385856 -> 443200 bytes i915/mtl_guc_70.bin | Bin 308032 -> 365376 bytes i915/tgl_guc_70.bin | Bin 285888 -> 330304 bytes 5 files changed, 4 insertions(+), 4 deletions(-)
[Intel-gfx] [PATCH v14 6/7] drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck
For the gt_tlb live selftest, when operating on the GSC engine,
increase the timeout from 10 ms to 200 ms because the GSC
engine is a bit slower than the rest.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/selftest_tlb.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_tlb.c
b/drivers/gpu/drm/i915/gt/selftest_tlb.c
index 7e41f69fc818f..00b872b6380b1 100644
--- a/drivers/gpu/drm/i915/gt/selftest_tlb.c
+++ b/drivers/gpu/drm/i915/gt/selftest_tlb.c
@@ -136,8 +136,15 @@ pte_tlbinv(struct intel_context *ce,
i915_request_get(rq);
i915_request_add(rq);
- /* Short sleep to sanitycheck the batch is spinning before we begin */
- msleep(10);
+ /*
+* Short sleep to sanitycheck the batch is spinning before we begin.
+* FIXME: Why is GSC so slow?
+*/
+ if (ce->engine->class == OTHER_CLASS)
+ msleep(200);
+ else
+ msleep(10);
+
if (va == vb) {
if (!i915_request_completed(rq)) {
pr_err("%s(%s): Semaphore sanitycheck failed %llx, with
alignment %llx, using PTE size %x (phys %x, sg %x)\n",
--
2.25.1
[Intel-gfx] [PATCH v14 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
From: Prathap Kumar Valsan
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the GuC is
disabled.
The invalidation is done by sending a request directly to the GuC
tlb_lookup that invalidates the table. The invalidation is submitted as
a wait request and is performed in the CT event handler. This means we
cannot perform this TLB invalidation path if the CT is not enabled.
If the request isn't fulfilled in two seconds, this would constitute
an error in the invalidation as that would constitute either a lost
request or a severe GuC overload.
With this new invalidation routine, we can perform GuC-based GGTT
invalidations. GuC-based GGTT invalidation is incompatible with
MMIO invalidation so we should not perform MMIO invalidation when
GuC-based GGTT invalidation is expected.
The additional complexity incurred in this patch will be necessary for
range-based tlb invalidations, which will be platformed in the future.
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Bruce Chang
Signed-off-by: Chris Wilson
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Jonathan Cavitt
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Fei Yang
CC: Andi Shyti
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 ++-
drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +-
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 22 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 13 ++
8 files changed, 298 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632b..1c93e84278a03 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -206,22 +206,36 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
}
+static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ intel_wakeref_t wakeref;
+
+ with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
+ struct intel_guc *guc = >uc.guc;
+
+ intel_guc_invalidate_tlb_guc(guc);
+ }
+}
+
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
{
struct drm_i915_private *i915 = ggtt->vm.i915;
+ struct intel_gt *gt;
gen8_ggtt_invalidate(ggtt);
- if (GRAPHICS_VER(i915) >= 12) {
- struct intel_gt *gt;
-
- list_for_each_entry(gt, >gt_list, ggtt_link)
+ list_for_each_entry(gt, >gt_list, ggtt_link) {
+ if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
+ guc_ggtt_ct_invalidate(gt);
+ } else if (GRAPHICS_VER(i915) >= 12) {
intel_uncore_write_fw(gt->uncore,
GEN12_GUC_TLB_INV_CR,
GEN12_GUC_TLB_INV_CR_INVALIDATE);
- } else {
- intel_uncore_write_fw(ggtt->vm.gt->uncore,
- GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ } else {
+ intel_uncore_write_fw(gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ }
}
}
@@ -1243,7 +1257,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.raw_insert_page = gen8_ggtt_insert_page;
}
- if (intel_uc_wants_guc(>vm.gt->uc))
+ if (intel_uc_wants_guc_submission(>vm.gt->uc))
ggtt->invalidate = guc_ggtt_invalidate;
else
ggtt->invalidate = gen8_ggtt_invalidate;
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index 139608c30d978..4bb13d1890e37 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -12,6 +12,7 @@
#include "intel_gt_print.h"
#include "intel_gt_regs.h"
#include "intel_tlb.h"
+#include "uc/intel_guc.h"
/*
* HW architecture suggest typical invalidation time at 40us,
@@ -131,11 +132,24 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
u32 seqno)
return;
with_intel_gt_pm_if_awake(gt, wakeref) {
+ struct intel_guc *guc = >uc.guc;
+
mutex_lock(>tlb.invalidate_lock);
if (tlb_seqno_passed(gt, seqno))
goto unlock;
-
[Intel-gfx] [PATCH v14 4/7] drm/i915: No TLB invalidation on suspended GT
In case of GT is suspended, don't allow submission of new TLB invalidation
request and cancel all pending requests. The TLB entries will be
invalidated either during GuC reload or on system resume.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c| 13 +
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 16
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 0949628d69f8b..2b6dfe62c8f2a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -537,4 +537,5 @@ int intel_guc_invalidate_tlb_engines(struct intel_guc *guc);
int intel_guc_invalidate_tlb_guc(struct intel_guc *guc);
int intel_guc_tlb_invalidation_done(struct intel_guc *guc,
const u32 *payload, u32 len);
+void wake_up_all_tlb_invalidate(struct intel_guc *guc);
#endif
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 8a304b4c85462..1b9fa2bafaad6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1796,6 +1796,19 @@ static void __guc_reset_context(struct intel_context
*ce, intel_engine_mask_t st
intel_context_put(parent);
}
+void wake_up_all_tlb_invalidate(struct intel_guc *guc)
+{
+ struct intel_guc_tlb_wait *wait;
+ unsigned long i;
+
+ if (intel_guc_tlb_invalidation_is_available(guc)) {
+ xa_lock_irq(>tlb_lookup);
+ xa_for_each(>tlb_lookup, i, wait)
+ wake_up(>wq);
+ xa_unlock_irq(>tlb_lookup);
+ }
+}
+
void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t
stalled)
{
struct intel_context *ce;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 83ffdf19fd3fc..7ad560149a189 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -464,8 +464,6 @@ static int __uc_init_hw(struct intel_uc *uc)
struct drm_i915_private *i915 = gt->i915;
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
- struct intel_guc_tlb_wait *wait;
- long unsigned int i;
int ret, attempts;
bool pl1en = false;
@@ -566,12 +564,7 @@ static int __uc_init_hw(struct intel_uc *uc)
* The full GT reset will have cleared the TLB caches and flushed the
* G2H message queue; we can release all the blocked waiters.
*/
- if (intel_guc_tlb_invalidation_is_available(guc)) {
- xa_lock_irq(>tlb_lookup);
- xa_for_each(>tlb_lookup, i, wait)
- wake_up(>wq);
- xa_unlock_irq(>tlb_lookup);
- }
+ wake_up_all_tlb_invalidate(guc);
return 0;
@@ -701,6 +694,8 @@ void intel_uc_suspend(struct intel_uc *uc)
/* flush the GSC worker */
intel_gsc_uc_flush_work(>gsc);
+ wake_up_all_tlb_invalidate(guc);
+
if (!intel_guc_is_ready(guc)) {
guc->interrupts.enabled = false;
return;
@@ -749,6 +744,11 @@ static int __uc_resume(struct intel_uc *uc, bool
enable_communication)
intel_gsc_uc_resume(>gsc);
+ if (intel_guc_tlb_invalidation_is_available(guc)) {
+ intel_guc_invalidate_tlb_engines(guc);
+ intel_guc_invalidate_tlb_guc(guc);
+ }
+
return 0;
}
--
2.25.1
[Intel-gfx] [PATCH v14 7/7] drm/i915: Enable GuC TLB invalidations for MTL
Enable GuC TLB invalidations for MTL. Though more platforms than just
MTL support GuC TLB invalidations, MTL is presently the only platform
that requires it for any purpose, so only enable it there for now to
minimize cross-platform impact.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index df7c261410f79..d4b51ececbb12 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -829,6 +829,7 @@ static const struct intel_device_info mtl_info = {
.has_flat_ccs = 0,
.has_gmd_id = 1,
.has_guc_deprivilege = 1,
+ .has_guc_tlb_invalidation = 1,
.has_llc = 0,
.has_mslice_steering = 0,
.has_snoop = 1,
--
2.25.1
[Intel-gfx] [PATCH v14 2/7] drm/i915/guc: Add CT size delay helper
As of now, there is no mechanism for tracking a given request's
progress through the queue. Instead, add a helper that returns
an estimated maximum time the queue should take to drain if
completely full.
Suggested-by: John Harrison
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 27 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index c33210ead1ef7..03b616ba4ebb7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -103,6 +103,33 @@ enum { CTB_SEND = 0, CTB_RECV = 1 };
enum { CTB_OWNER_HOST = 0 };
+/*
+ * Some H2G commands involve a synchronous response that the driver needs
+ * to wait for. In such cases, a timeout is required to prevent the driver
+ * from waiting forever in the case of an error (either no error response
+ * is defined in the protocol or something has died and requires a reset).
+ * The specific command may be defined as having a time bound response but
+ * the CT is a queue and that time guarantee only starts from the point
+ * when the command reaches the head of the queue and is processed by GuC.
+ *
+ * Ideally there would be a helper to report the progress of a given
+ * command through the CT. However, that would require a significant
+ * amount of work in the CT layer. In the meantime, provide a reasonable
+ * estimation of the worst case latency it should take for the entire
+ * queue to drain. And therefore, how long a caller should wait before
+ * giving up on their request. The current estimate is based on empirical
+ * measurement of a test that fills the buffer with context creation and
+ * destruction requests as they seem to be the slowest operation.
+ */
+long intel_guc_ct_max_queue_time_jiffies(void)
+{
+ /*
+* A 4KB buffer full of context destroy commands takes a little
+* over a second to process so bump that to 2s to be super safe.
+*/
+ return (CTB_H2G_BUFFER_SIZE * HZ) / SZ_2K;
+}
+
static void ct_receive_tasklet_func(struct tasklet_struct *t);
static void ct_incoming_request_worker_func(struct work_struct *w);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 58e42901ff498..2c4bb9a941be6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
@@ -104,6 +104,8 @@ struct intel_guc_ct {
#endif
};
+long intel_guc_ct_max_queue_time_jiffies(void);
+
void intel_guc_ct_init_early(struct intel_guc_ct *ct);
int intel_guc_ct_init(struct intel_guc_ct *ct);
void intel_guc_ct_fini(struct intel_guc_ct *ct);
--
2.25.1
[Intel-gfx] [PATCH v14 0/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
Implement GuC-based TLB invalidations and use them on MTL. Some complexity in the implementation was introduced early on and will be required for range-based TLB invalidations. RFC: https://patchwork.freedesktop.org/series/124922/ v2: - Add missing supporting patches. v3: - Split suspend/resume changes and multi-gt support into separate patches. - Only perform GuC TLB invalidation functions when supported. - Move intel_guc_is_enabled check function to usage location. - Address comments. v4: - Change conditions for GuC-based tlb invalidation support to a pci tag that's only active for MTL. - Address some FIXMEs and formatting issues. - Move suspend/resume changes to helper functions in intel_gt.h - Improve comment for ct_handle_event change. - Use cleaner if-else conditions. - Address comments. v5: - Reintroduce missing change to selftest msleep duration - Move suspend/resume loops from intel_gt.h to intel_tlb.c, making them no longer static inlines. - Remove superfluous blocking and error checks. - Move ct_handle_event exception to general case in ct_process_request. - Explain usage of xa_alloc_cyclic_irq. - Modify explanation of purpose of OUTSTANDING_GUC_TIMEOUT_PERIOD macro. - Explain purpose of performing tlb invalidation twice in intel_gt_tlb_resume_all. v6: - Add this cover letter. - Fix explanation of purpose of OUTSTANDING_GUC_TIMEOUT_PERIOD macro again. - s/pci tags/pci flags - Enable GuC TLB Invalidations separately from adding the flags to do so. v7: - Eliminate pci terminology from patches. - Order new device info flag correctly. - Run gen8_ggtt_invalidate in more cases, specifically when GuC-based TLB invalidation is not supported. - Use intel_uncore_write_fw instead of intel_uncore_write during guc_ggtt_invalidate. - Remove duplicate request message clear in ct_process_request. - Remove faulty tag from series. v8: - Simplify cover letter contents. - Fix miscellaneous formatting and typos. - Reorder device info flags and defines. - Reword commit message. - Rename TLB invalidation enums and functions. - Add comments explaining confusing points. - Add helper function getting expected delay of CT buffer. - Simplify intel_guc_tlb_invalidation_done by passing computed values. - Remove helper functions for tlb suspend and resume. - Move tlb suspend and resume paths to uc. - Split suspend/resume and wedged into two patches. - Clarify purpose of sleep change in tlb selftest. v9: - Explain complexity of GuC TLB invalidations as required for range-based TLB invalidations, which will be platformed later. - Fix CHECKPATCH issues. - Explain intel_guc_is_ready tlb invalidation skip in intel_gt_invalidate_tlb_full. - Reword comment for unlocked xa_for_each loop in intel_guc_submission_reset. - Report all errors in init_tlb_lookup. - Remove debug message from fini_tlb_lookup. - Use standardized interface for intel_guc_tlb_invalidation_done - Remove spurious changes. - Move wake_up_all_tlb_invalidate on wedge to correct patch. v10: - Add lock to tlb_lookup on guc submission reset. - Add comment about why timeout increased from 10 ms to 20 ms by default in gt_tlb selftest. - Remove spurious changes. v11: - Update CT size delay helper to be clearer. - Reorder some function declarations. - Clarify some comments. - Produce error message if attempting to free a busy wait during fini_tlb_lookup. - Revert default sleep back to 10 ms. - Link to RFC. v12: - Add helper for checking if GuC TLB invalidation is supported and guc is ready. - Prevent suspend/resume actions involving GuC TLB invalidations if guc is not ready. - Add path for INTEL_GUC_ACTION_TLB_INVALIDATION_DONE to immediately process in ct_process_request after it is submitted to ct_handle_event. v13: - Readd error check in intel_guc_tlb_invalidation_done for invalid length. - Remove intel_guc_is_ready requirement from wake_up_all_tlb_invalidate. - Align patches 3 and 4 by adding a check for GuC TLB invalidation support to the former that was added in the latter. v14: - Readd intel_guc_is_ready requirement to wake_up_all_tlb_invalidate. - Move wake_up_all_tlb_invalidate from intel_guc_submission_reset to the end of __uc_hw_init. - Remove gen8_ggtt_invalidate changes, as they aren't related to GuC TLB invalidation. - Add missing newline. Jonathan Cavitt (6): drm/i915: Add GuC TLB Invalidation device info flags drm/i915/guc: Add CT size delay helper drm/i915: No TLB invalidation on suspended GT drm/i915: No TLB invalidation on wedged GT drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck drm/i915: Enable GuC TLB invalidations for MTL Prathap Kumar Valsan (1): drm/i915: Define and use GuC and CTB TLB invalidation routines drivers/gpu/drm/i915/gt/intel_ggtt.c | 30 ++- drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +- drivers/gpu/drm/i915/gt/selftest_tlb.c| 11 +- .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33 +++
[Intel-gfx] [PATCH v14 5/7] drm/i915: No TLB invalidation on wedged GT
It is not an error for GuC TLB invalidations to fail when the GT is
wedged or disabled, so do not process a wait failure as one in
guc_send_invalidate_tlb.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Acked-by: Nirmoy Das
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
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 1b9fa2bafaad6..7f2d6adb5dfce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -32,6 +32,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
+#include "i915_irq.h"
#include "i915_trace.h"
/**
@@ -1934,6 +1935,12 @@ void intel_guc_submission_cancel_requests(struct
intel_guc *guc)
/* GuC is blown away, drop all references to contexts */
xa_destroy(>context_lookup);
+
+ /*
+* Wedged GT won't respond to any TLB invalidation request. Simply
+* release all the blocked waiters.
+*/
+ wake_up_all_tlb_invalidate(guc);
}
void intel_guc_submission_reset_finish(struct intel_guc *guc)
@@ -4742,6 +4749,14 @@ static long must_wait_woken(struct wait_queue_entry
*wq_entry, long timeout)
return timeout;
}
+static bool intel_gt_is_enabled(const struct intel_gt *gt)
+{
+ /* Check if GT is wedged or suspended */
+ if (intel_gt_is_wedged(gt) || !intel_irqs_enabled(gt->i915))
+ return false;
+ return true;
+}
+
static int guc_send_invalidate_tlb(struct intel_guc *guc,
enum intel_guc_tlb_invalidation_type type)
{
@@ -4791,7 +4806,8 @@ static int guc_send_invalidate_tlb(struct intel_guc *guc,
if (err)
goto out;
- if (!must_wait_woken(, intel_guc_ct_max_queue_time_jiffies())) {
+ if (intel_gt_is_enabled(guc_to_gt(guc)) &&
+ !must_wait_woken(, intel_guc_ct_max_queue_time_jiffies())) {
guc_err(guc,
"TLB invalidation response timed out for seqno %u\n",
seqno);
err = -ETIME;
--
2.25.1
[Intel-gfx] [PATCH v14 1/7] drm/i915: Add GuC TLB Invalidation device info flags
Add device info flags for if GuC TLB Invalidation is enabled.
Signed-off-by: Jonathan Cavitt
Reviewed-by: Andi Shyti
Acked-by: Tvrtko Ursulin
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cb60fc9cf8737..6a2a78c61f212 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -794,6 +794,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GUC_DEPRIVILEGE(i915) \
(INTEL_INFO(i915)->has_guc_deprivilege)
+#define HAS_GUC_TLB_INVALIDATION(i915)
(INTEL_INFO(i915)->has_guc_tlb_invalidation)
+
#define HAS_3D_PIPELINE(i915) (INTEL_INFO(i915)->has_3d_pipeline)
#define HAS_ONE_EU_PER_FUSE_BIT(i915)
(INTEL_INFO(i915)->has_one_eu_per_fuse_bit)
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 39817490b13fd..eba2f0b919c87 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -153,6 +153,7 @@ enum intel_ppgtt_type {
func(has_heci_pxp); \
func(has_heci_gscfi); \
func(has_guc_deprivilege); \
+ func(has_guc_tlb_invalidation); \
func(has_l3_ccs_read); \
func(has_l3_dpf); \
func(has_llc); \
--
2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add bigjoiner force enable option to debugfs (rev3)
== Series Details == Series: drm/i915: Add bigjoiner force enable option to debugfs (rev3) URL : https://patchwork.freedesktop.org/series/124730/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13747_full -> Patchwork_124730v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_124730v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_124730v3_full, please notify your bug team (lgci.bug.fil...@intel.com) 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_124730v3_full: ### IGT changes ### Possible regressions * igt@i915_module_load@reload-with-fault-injection: - shard-snb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-snb7/igt@i915_module_l...@reload-with-fault-injection.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v3/shard-snb6/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1: - shard-apl: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v3/shard-apl7/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html * igt@kms_rotation_crc@primary-y-tiled-reflect-x-90: - shard-rkl: NOTRUN -> [INCOMPLETE][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v3/shard-rkl-1/igt@kms_rotation_...@primary-y-tiled-reflect-x-90.html Known issues Here are the changes found in Patchwork_124730v3_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][5], [PASS][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], [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], [FAIL][41], [PASS][42], [FAIL][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#8293]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk9/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk8/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk8/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk3/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13747/shard-glk1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v3/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_124730v3/shard-glk2/boot.html [32]:
Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms
On Fri, Oct 13, 2023 at 02:28:21PM +0200, Nirmoy Das wrote:
> Hi Ville,
>
> On 10/13/2023 12:50 PM, Ville Syrjälä wrote:
> > On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote:
> > > gen8_ggtt_invalidate() is only needed for limitted set of platforms
> > > where GGTT is mapped as WC
> > I know there is supposed to be some kind hw snooping of the ggtt
> > pte writes to invalidate the tlb, but are we sure GFX_FLSH_CNTL
> > has no other side effects we depend on?
>
> I spent some time searching through the gfxspec. This GFX_FLSH_CNTL register
> only seems to be for
>
> invalidating TLB for GUnit and (from git log ) we started to do that to
> enable WC based GGTT updates.
Might be good to cite the relevant git commits in the commit message to
make this clear.
-Sima
>
>
> So if I am not missing anything obvious then this should be safe.
>
>
> Regards,
>
> Nirmoy
>
> >
> > > otherwise this can cause unwanted
> > > side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not
> > > valid.
> > >
> > > Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> > > Cc: Rodrigo Vivi
> > > Cc: Tvrtko Ursulin
> > > Cc: Joonas Lahtinen
> > > Cc: Jani Nikula
> > > Cc: Jonathan Cavitt
> > > Cc: John Harrison
> > > Cc: Andi Shyti
> > > Cc: # v6.2+
> > > Suggested-by: Matt Roper
> > > Signed-off-by: Nirmoy Das
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > > b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > > index 4d7d88b92632..c2858d434bce 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > > @@ -197,13 +197,17 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
> > > static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
> > > {
> > > + struct drm_i915_private *i915 = ggtt->vm.i915;
> > > struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> > > /*
> > >* Note that as an uncached mmio write, this will flush the
> > >* WCB of the writes into the GGTT before it triggers the
> > > invalidate.
> > > + *
> > > + * Only perform this when GGTT is mapped as WC, see ggtt_probe_common().
> > >*/
> > > - intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> > > + if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
> > > + intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
> > > GFX_FLSH_CNTL_EN);
> > > }
> > > static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
> > > --
> > > 2.41.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v2] drm/i915: Flush WC GGTT only on required platforms
On Fri, Oct 13, 2023 at 03:44:39PM +0200, Nirmoy Das wrote:
> gen8_ggtt_invalidate() is only needed for limited set of platforms
> where GGTT is mapped as WC otherwise this can cause unwanted
> side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not
> valid.
>
> v2: Add a func to detect wc ggtt detection (Ville)
>
> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Cc: Jani Nikula
> Cc: Jonathan Cavitt
> Cc: John Harrison
> Cc: Andi Shyti
> Cc: Ville Syrjälä
> Cc: # v6.2+
> Suggested-by: Matt Roper
> Signed-off-by: Nirmoy Das
> Acked-by: Andi Shyti
Reviewed-by: Matt Roper
Interestingly, bspec 151 indicates that we probably shouldn't have been
using a CPU:WC mapping for the GGTT on gen9bc platforms either (i.e.,
the GTT part of the GTTMMADR has the same "64-bits or less" restriction
listed as later platforms). But we've been using WC without issue for
the last 8 years, so I guess it's not worth changing it now.
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 35 +++-
> 1 file changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 4d7d88b92632..401667f83f96 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -195,6 +195,21 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
> spin_unlock_irq(>lock);
> }
>
> +static bool needs_wc_ggtt_mapping(struct drm_i915_private *i915)
> +{
> + /*
> + * On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
> + * will be dropped. For WC mappings in general we have 64 byte burst
> + * writes when the WC buffer is flushed, so we can't use it, but have to
> + * resort to an uncached mapping. The WC issue is easily caught by the
> + * readback check when writing GTT PTE entries.
> + */
> + if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
> + return true;
> +
> + return false;
> +}
> +
> static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
> {
> struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> @@ -202,8 +217,12 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
> /*
>* Note that as an uncached mmio write, this will flush the
>* WCB of the writes into the GGTT before it triggers the invalidate.
> + *
> + * Only perform this when GGTT is mapped as WC, see ggtt_probe_common().
>*/
> - intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> + if (needs_wc_ggtt_mapping(ggtt->vm.i915))
> + intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
> + GFX_FLSH_CNTL_EN);
> }
>
> static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
> @@ -1126,17 +1145,11 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt,
> u64 size)
> GEM_WARN_ON(pci_resource_len(pdev, GEN4_GTTMMADR_BAR) !=
> gen6_gttmmadr_size(i915));
> phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) +
> gen6_gttadr_offset(i915);
>
> - /*
> - * On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
> - * will be dropped. For WC mappings in general we have 64 byte burst
> - * writes when the WC buffer is flushed, so we can't use it, but have to
> - * resort to an uncached mapping. The WC issue is easily caught by the
> - * readback check when writing GTT PTE entries.
> - */
> - if (IS_GEN9_LP(i915) || GRAPHICS_VER(i915) >= 11)
> - ggtt->gsm = ioremap(phys_addr, size);
> - else
> + if (needs_wc_ggtt_mapping(i915))
> ggtt->gsm = ioremap_wc(phys_addr, size);
> + else
> + ggtt->gsm = ioremap(phys_addr, size);
> +
> if (!ggtt->gsm) {
> drm_err(>drm, "Failed to map the ggtt page table\n");
> return -ENOMEM;
> --
> 2.41.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] Buggy graphics on 82G33/G31.
https://media.discordapp.com/attachments/697112906457677914/1161753753993621505/image.png Has somebody ever experienced such issue on a 82G33/G31 GPU? This issue happens on Windows too. It's more aggressive (in the sense it's more prone to happen) on Linux, though. Strangely, I've never found reports on this issue in the internet. Games I've experienced this issue are GTA 3, GTA Vice City, GTA San Andreas and Freelancer. Not all games have this issue. Switching to modesetting X driver solves the issue, but introduces a new one, lag. I contacted Intel support, but they said the product reached the end of interactive support.
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Clean up zero initializers
== Series Details == Series: drm/i915: Clean up zero initializers URL : https://patchwork.freedesktop.org/series/125050/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13746_full -> Patchwork_125050v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125050v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125050v1_full, please notify your bug team (lgci.bug.fil...@intel.com) 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_125050v1_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live@workarounds: - shard-dg1: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13746/shard-dg1-12/igt@i915_selftest@l...@workarounds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125050v1/shard-dg1-18/igt@i915_selftest@l...@workarounds.html New tests - New tests have been introduced between CI_DRM_13746_full and Patchwork_125050v1_full: ### New IGT tests (109) ### * igt@kms_content_protection@atomic-dpms@pipe-a-dp-4: - Statuses : 1 timeout(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-mc-ccs-to-4: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-mc-ccs-to-4-mc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-mc-ccs-to-4-rc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-mc-ccs-to-4-rc-ccs-cc: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-mc-ccs-to-linear: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-mc-ccs-to-x: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-cc-to-4: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-cc-to-4-mc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-cc-to-4-rc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-cc-to-4-rc-ccs-cc: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-cc-to-linear: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-cc-to-x: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-to-4: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-to-4-mc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-to-4-rc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-to-4-rc-ccs-cc: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-to-linear: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-rc-ccs-to-x: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-to-4-mc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-to-4-rc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-4-to-4-rc-ccs-cc: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-linear-to-4-mc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-linear-to-4-rc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-linear-to-4-rc-ccs-cc: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-x-to-4-mc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_flip_tiling@flip-change-tiling@hdmi-a-3-pipe-a-x-to-4-rc-ccs: - Statuses : 1 pass(s) - Exec time: [0.0] s *
Re: [Intel-gfx] [PATCH v13 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines
-Original Message-
From: Harrison, John C
Sent: Thursday, October 12, 2023 6:11 PM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com;
Iddamsetty, Aravind ; Yang, Fei
; Shyti, Andi ; Das, Nirmoy
; Krzysztofik, Janusz ;
Roper, Matthew D ; tvrtko.ursu...@linux.intel.com;
jani.nik...@linux.intel.com
Subject: Re: [PATCH v13 3/7] drm/i915: Define and use GuC and CTB TLB
invalidation routines
>
> On 10/12/2023 15:38, Jonathan Cavitt wrote:
> > From: Prathap Kumar Valsan
> >
> > The GuC firmware had defined the interface for Translation Look-Aside
> > Buffer (TLB) invalidation. We should use this interface when
> > invalidating the engine and GuC TLBs.
> > Add additional functionality to intel_gt_invalidate_tlb, invalidating
> > the GuC TLBs and falling back to GT invalidation when the GuC is
> > disabled.
> > The invalidation is done by sending a request directly to the GuC
> > tlb_lookup that invalidates the table. The invalidation is submitted as
> > a wait request and is performed in the CT event handler. This means we
> > cannot perform this TLB invalidation path if the CT is not enabled.
> > If the request isn't fulfilled in two seconds, this would constitute
> > an error in the invalidation as that would constitute either a lost
> > request or a severe GuC overload.
> >
> > With this new invalidation routine, we can perform GuC-based GGTT
> > invalidations. GuC-based GGTT invalidation is incompatible with
> > MMIO invalidation so we should not perform MMIO invalidation when
> > GuC-based GGTT invalidation is expected.
> >
> > The additional complexity incurred in this patch will be necessary for
> > range-based tlb invalidations, which will be platformed in the future.
> >
> > Signed-off-by: Prathap Kumar Valsan
> > Signed-off-by: Bruce Chang
> > Signed-off-by: Chris Wilson
> > Signed-off-by: Umesh Nerlige Ramappa
> > Signed-off-by: Jonathan Cavitt
> > Signed-off-by: Aravind Iddamsetty
> > Signed-off-by: Fei Yang
> > CC: Andi Shyti
> > Reviewed-by: Andi Shyti
> > Acked-by: Tvrtko Ursulin
> > Acked-by: Nirmoy Das
> > Reviewed-by: John Harrison
> > ---
> > drivers/gpu/drm/i915/gt/intel_ggtt.c | 33 ++-
> > drivers/gpu/drm/i915/gt/intel_tlb.c | 16 +-
> > .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 33 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 22 ++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 11 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 1 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 195 +-
> > 7 files changed, 299 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > index 4d7d88b92632b..7d145b2d3cb17 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > @@ -206,22 +206,37 @@ static void gen8_ggtt_invalidate(struct i915_ggtt
> > *ggtt)
> > intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> > }
> >
> > +static void guc_ggtt_ct_invalidate(struct intel_gt *gt)
> > +{
> > + struct intel_uncore *uncore = gt->uncore;
> > + intel_wakeref_t wakeref;
> > +
> > + with_intel_runtime_pm_if_active(uncore->rpm, wakeref) {
> > + struct intel_guc *guc = >uc.guc;
> > +
> > + intel_guc_invalidate_tlb_guc(guc);
> > + }
> > +}
> > +
> > static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
> > {
> > struct drm_i915_private *i915 = ggtt->vm.i915;
> > + struct intel_gt *gt;
> >
> > - gen8_ggtt_invalidate(ggtt);
> > -
> > - if (GRAPHICS_VER(i915) >= 12) {
> > - struct intel_gt *gt;
> > + if (!HAS_GUC_TLB_INVALIDATION(i915))
> > + gen8_ggtt_invalidate(ggtt);
> This has not changed? As per comments from Matthew Roper and Nirmoy Das,
> there needs to be a fixup patch first to stop gen8_ggtt_invalidate()
> from being called on invalid platforms.
Given the sounds of things, it seems like this change here is irrelevant to
this patch series, as the reason we're
guarding against gen8_ggtt_invalidate isn't related to GuC-based TLB
invalidations at all. Ergo, it would actually
make more sense for me to not skip it here and leave the respective guard
change to a different patch series.
-Jonathan Cavitt
>
> >
> > - list_for_each_entry(gt, >gt_list, ggtt_link)
> > + list_for_each_entry(gt, >gt_list, ggtt_link) {
> > + if (intel_guc_tlb_invalidation_is_available(>uc.guc)) {
> > + guc_ggtt_ct_invalidate(gt);
> > + } else if (GRAPHICS_VER(i915) >= 12) {
> > intel_uncore_write_fw(gt->uncore,
> > GEN12_GUC_TLB_INV_CR,
> > GEN12_GUC_TLB_INV_CR_INVALIDATE);
> > - } else {
> > - intel_uncore_write_fw(ggtt->vm.gt->uncore,
> > -
Re: [Intel-gfx] [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT
-Original Message-
From: Harrison, John C
Sent: Thursday, October 12, 2023 6:08 PM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com;
Iddamsetty, Aravind ; Yang, Fei
; Shyti, Andi ; Das, Nirmoy
; Krzysztofik, Janusz ;
Roper, Matthew D ; tvrtko.ursu...@linux.intel.com;
jani.nik...@linux.intel.com
Subject: Re: [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT
>
> On 10/12/2023 15:38, Jonathan Cavitt wrote:
> > In case of GT is suspended, don't allow submission of new TLB invalidation
> > request and cancel all pending requests. The TLB entries will be
> > invalidated either during GuC reload or on system resume.
> >
> > Signed-off-by: Fei Yang
> > Signed-off-by: Jonathan Cavitt
> > CC: John Harrison
> > Reviewed-by: Andi Shyti
> > Acked-by: Tvrtko Ursulin
> > Acked-by: Nirmoy Das
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 22 ---
> > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 ++
> > 3 files changed, 22 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 0949628d69f8b..2b6dfe62c8f2a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -537,4 +537,5 @@ int intel_guc_invalidate_tlb_engines(struct intel_guc
> > *guc);
> > int intel_guc_invalidate_tlb_guc(struct intel_guc *guc);
> > int intel_guc_tlb_invalidation_done(struct intel_guc *guc,
> > const u32 *payload, u32 len);
> > +void wake_up_all_tlb_invalidate(struct intel_guc *guc);
> > #endif
> > 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 1377398afcdfa..3a0d20064878a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -1796,13 +1796,24 @@ static void __guc_reset_context(struct
> > intel_context *ce, intel_engine_mask_t st
> > intel_context_put(parent);
> > }
> >
> > -void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t
> > stalled)
> > +void wake_up_all_tlb_invalidate(struct intel_guc *guc)
> > {
> > struct intel_guc_tlb_wait *wait;
> > + unsigned long i;
> > +
> > + if (HAS_GUC_TLB_INVALIDATION(guc_to_gt(guc)->i915)) {
> Why the change from 'if(!is_available) return' to 'if(HAS_) {doStuff}'?
I feel like this question has two parts, so I'll answer them separately:
1. Why HAS_GUC_TLB_INVALIDATION and not intel_guc_tlb_invalidation_is_available?
Wake_up_all_tlb_invalidate is called during the suspend/resume path,
specifically in the
middle of suspend. It's required for it to be called here to clean up any
invalidations left
in the queue during the suspend/resume phase because they are no longer valid
requests.
However, the suspend/resume phase also resets GuC, so intel_guc_is_ready
returns false.
In short, using intel_guc_invalidation_is_available was causing us to skip this
code section
incorrectly, resulting in spurious GuC TLB invalidation timeout errors during
gt reset.
2. Why use a positive check to perform and not a negative check to skip?
In patch 3, wake_up_all_tlb_invalidate was originally called universally on all
platforms
during intel_guc_submission_reset, which is incorrect and not how was
reimplemented here.
I discovered this was the case and retroactively corrected it, as seen below.
Because of how intel_guc_submission_reset is structured, a negative check to
skip wouldn't
make much sense there, so I used a positive check to perform instead. This is
a holdover from
that implementation, and was kept to maintain consistency between patches 3 and
4. It's
probably not as big of a deal as I'm imagining, but I think it would be awkward
if the initial
implementation in intel_guc_submission_reset and the reimplementation in
wake_up_all_tlb_invalidate weren't superficially the same, even if they were
functionally
equivalent otherwise.
-Jonathan Cavitt
>
> John.
>
> > + xa_lock_irq(>tlb_lookup);
> > + xa_for_each(>tlb_lookup, i, wait)
> > + wake_up(>wq);
> > + xa_unlock_irq(>tlb_lookup);
> > + }
> > +}
> > +
> > +void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t
> > stalled)
> > +{
> > struct intel_context *ce;
> > unsigned long index;
> > unsigned long flags;
> > - unsigned long i;
> >
> > if (unlikely(!guc_submission_initialized(guc))) {
> > /* Reset called during driver load? GuC not yet initialised! */
> > @@ -1833,12 +1844,7 @@ void intel_guc_submission_reset(struct intel_guc
> > *guc, intel_engine_mask_t stall
> > * The full GT reset will have cleared the TLB caches and flushed the
> > * G2H message queue; we
Re: [Intel-gfx] Regression in linux-next
Hello Rafael, > -Original Message- > From: Borah, Chaitanya Kumar > Sent: Wednesday, October 11, 2023 10:19 PM > To: Wysocki, Rafael J > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar > ; Saarinen, Jani > Subject: RE: Regression in linux-next > > Hello Rafael, > > > -Original Message- > > From: Wysocki, Rafael J > > Sent: Wednesday, October 11, 2023 9:44 PM > > To: Borah, Chaitanya Kumar > > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar > > ; Saarinen, Jani > > > > Subject: Re: Regression in linux-next > > > > Hi, > > > > On 10/11/2023 6:00 AM, Borah, Chaitanya Kumar wrote: > > > Hello Rafael, > > > > > >> -Original Message- > > >> From: Wysocki, Rafael J > > >> Sent: Tuesday, October 10, 2023 12:54 AM > > >> To: Borah, Chaitanya Kumar > > >> Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar > > >> ; Saarinen, Jani > > >> > > >> Subject: Re: Regression in linux-next > > >> > > >> Hi, > > >> > > >> On 10/9/2023 7:10 AM, Borah, Chaitanya Kumar wrote: > > >>> Hello Rafael > > >>> > > Thanks for the report, I think that this is a lockdep assertion > > failing. > > If that is correct, it should be straightforward to fix. > > I'll take care of this early next week. > > Thanks! > > >>> Thank you for your response. Please let us know when a fix is > > >>> available. > > >> It should be fixed in linux-next from today, by this commit: > > >> > > >> https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux- > > >> pm.git/commit/?h=linux- > > >> next=b4027ce7714f309e96b804b7fb088a40d708 > > >> > > >> Thanks! > > > Thanks a lot for the fix. This seems to have fixed the issue in most > > > of the > > machines but we are still seeing a similar problem in few of the machines. > > > > Thanks for reporting this! > > > > > > > This has a different call stack but seems to be from the same > > > thermal subsystem. Full logs in [1] > > > > > > <4>[4.392015] WARNING: CPU: 1 PID: 306 at > > drivers/thermal/thermal_trip.c:178 thermal_zone_trip_id+0x61/0x70 > > > <4>[4.392022] Modules linked in: x86_pkg_temp_thermal coretemp > > kvm_intel mei_pxp mei_hdcp wmi_bmof kvm e1000e irqbypass > > crct10dif_pclmul video ptp crc32_pclmul ghash_clmulni_intel i2c_i801 > > mei_me pps_core mei i2c_smbus wmi > > > <4>[4.392057] CPU: 1 PID: 306 Comm: thermald Not tainted 6.6.0-rc5- > > next-20231010-next-20231010-gc0a6edb636cb+ #1 > > > <4>[4.392061] Hardware name: System manufacturer System Product > > Name/Z170M-PLUS, BIOS 3610 03/29/2018 > > > <4>[4.392063] RIP: 0010:thermal_zone_trip_id+0x61/0x70 > > > <4>[4.392066] Code: 74 0c 83 c0 01 39 c8 75 f0 b8 c3 ff ff ff 5b 5d > > > c3 cc > cc > > cc cc 48 8d bf f0 05 00 00 be ff ff ff ff e8 63 a4 2d 00 85 c0 75 b5 > > <0f> 0b eb b1 > > 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 > > > <4>[4.392069] RSP: 0018:c9000156bda8 EFLAGS: 00010246 > > > <4>[4.392073] RAX: RBX: 888103828ae8 RCX: > > 0001 > > > <4>[4.392075] RDX: 8000 RSI: 823de5ab RDI: > > 823fdfba > > > <4>[4.392078] RBP: 888103a88800 R08: 888103828ae8 R09: > > 0001 > > > <4>[4.392080] R10: 0001 R11: 88811494d3c0 R12: > > 888103a88818 > > > <4>[4.392082] R13: 8881108bfa00 R14: 888103794408 R15: > > 0001 > > > <4>[4.392084] FS: 7f1f0d6d28c0() > GS:88822e68() > > knlGS: > > > <4>[4.392087] CS: 0010 DS: ES: CR0: 80050033 > > > <4>[4.392089] CR2: 55857c50b750 CR3: 000111efa005 > CR4: > > 003706f0 > > > <4>[4.392091] DR0: DR1: > DR2: > > > > > <4>[4.392093] DR3: DR6: fffe0ff0 DR7: > > 0400 > > > <4>[4.392095] Call Trace: > > > <4>[4.392097] > > > <4>[4.392100] ? __warn+0x7f/0x170 > > > <4>[4.392104] ? thermal_zone_trip_id+0x61/0x70 > > > <4>[4.392109] ? report_bug+0x1f8/0x200 > > > <4>[4.392116] ? handle_bug+0x3c/0x70 > > > <4>[4.392119] ? exc_invalid_op+0x18/0x70 > > > <4>[4.392123] ? asm_exc_invalid_op+0x1a/0x20 > > > <4>[4.392133] ? thermal_zone_trip_id+0x61/0x70 > > > <4>[4.392137] ? thermal_zone_trip_id+0x5d/0x70 > > > <4>[4.392141] trip_point_show+0x18/0x40 > > > <4>[4.392145] dev_attr_show+0x15/0x60 > > > <4>[4.392149] sysfs_kf_seq_show+0xb5/0x100 > > > <4>[4.392154] seq_read_iter+0x111/0x450 > > > <4>[4.392158] ? check_object+0x133/0x320 > > > <4>[4.392164] vfs_read+0x20d/0x300 > > > <4>[4.392175] ksys_read+0x64/0xe0 > > > <4>[4.392180] do_syscall_64+0x3c/0x90 > > > <4>[4.392183] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 > > > <4>[4.392187] RIP: 0033:0x7f1f0e193392 > > > > > > Can you please check what could be the reason for this issue? > > > > Well, one more unuseful lockdep assertion has
[Intel-gfx] [PATCH] drm/i915/bios: Clamp VBT HDMI level shift on BDW
From: Ville Syrjälä
Apparently some BDW machines (eg. HP Pavilion 15-ab) shipped with
a VBT inherited from some earlier HSW model. On HSW the HDMI level
shift value could go up to 11, whereas on BDW the maximum value is
9.
The DDI code does clamp the bogus value, but it does so with
a WARN which we don't really want. To avoid that let's just sanitize
the bogus VBT HDMI level shift value ahead of time for all BDW machines.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9461
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4e8f1e91bb08..8f83f0ead27f 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2473,6 +2473,27 @@ static void sanitize_device_type(struct
intel_bios_encoder_data *devdata,
devdata->child.device_type |= DEVICE_TYPE_NOT_HDMI_OUTPUT;
}
+static void sanitize_hdmi_level_shift(struct intel_bios_encoder_data *devdata,
+ enum port port)
+{
+ struct drm_i915_private *i915 = devdata->i915;
+
+ if (!intel_bios_encoder_supports_dvi(devdata))
+ return;
+
+ /*
+* Some BDW machines (eg. HP Pavilion 15-ab) shipped
+* with a HSW VBT where the level shifter value goes
+* up to 11, whereas the BDW max is 9.
+*/
+ if (IS_BROADWELL(i915) && devdata->child.hdmi_level_shifter_value > 9) {
+ drm_dbg_kms(>drm, "Bogus port %c VBT HDMI level shift %d,
adjusting to %d\n",
+ port_name(port),
devdata->child.hdmi_level_shifter_value, 9);
+
+ devdata->child.hdmi_level_shifter_value = 9;
+ }
+}
+
static bool
intel_bios_encoder_supports_crt(const struct intel_bios_encoder_data *devdata)
{
@@ -2652,6 +2673,7 @@ static void parse_ddi_port(struct intel_bios_encoder_data
*devdata)
}
sanitize_device_type(devdata, port);
+ sanitize_hdmi_level_shift(devdata, port);
}
static bool has_ddi_port_info(struct drm_i915_private *i915)
--
2.41.0
Re: [Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer cache coherency settings
On Thu, Oct 12, 2023 at 09:40:23PM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of Ville
> > Syrjala
> > Sent: Monday, October 9, 2023 6:52 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer
> > cache coherency settings
> >
> > From: Ville Syrjälä
> >
> > The display engine does not snoop the caches so shoukd to mark the DSB
>
> Nit: Typo here
>
> I am not sure on the cache behaviour so someone from core can also ack.
> To me , looks logically correct.
> Reviewed-by: Uma Shankar
Thanks. This series is now merged. Fingers crossed DSB will behave
nicely...
>
> > command buffer as I915_CACHE_NONE.
> > i915_gem_object_create_internal() always gives us I915_CACHE_LLC on LLC
> > platforms. And to make things 100% correct we should also clflush at the
> > end, if
> > necessary.
> >
> > Note that currently this is a non-issue as we always write the command
> > buffer
> > through a WC mapping, so a cache flush is not actually needed. But we might
> > actually want to consider a WB mapping since we also end up reading from the
> > command buffer (in the indexed reg write handling). Either that or we
> > should do
> > something else to avoid those reads (might actually be even more sensible on
> > DGFX since we end up reading over PCIe). But we should measure the overhead
> > first...
> >
> > Anyways, no real harm in adding the belts and suspenders here so that the
> > code
> > will work correctly regardless of how we map the buffer. If we do get a WC
> > mapping (as we request)
> > i915_gem_object_flush_map() will be a nop. Well, apart form a wmb() which
> > may
> > just flush the WC buffer a bit earlier than would otherwise happen (at the
> > latest
> > the mmio accesses would trigger the WC flush).
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_dsb.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> > b/drivers/gpu/drm/i915/display/intel_dsb.c
> > index 7410ba3126f9..78b6fe24dcd8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> > @@ -316,6 +316,8 @@ void intel_dsb_finish(struct intel_dsb *dsb)
> >DSB_FORCE_DEWAKE, 0);
> >
> > intel_dsb_align_tail(dsb);
> > +
> > + i915_gem_object_flush_map(dsb->vma->obj);
> > }
> >
> > static int intel_dsb_dewake_scanline(const struct intel_crtc_state
> > *crtc_state)
> > @@ -462,13 +464,18 @@ struct intel_dsb *intel_dsb_prepare(const struct
> > intel_crtc_state *crtc_state,
> > /* ~1 qword per instruction, full cachelines */
> > size = ALIGN(max_cmds * 8, CACHELINE_BYTES);
> >
> > - if (HAS_LMEM(i915))
> > + if (HAS_LMEM(i915)) {
> > obj = i915_gem_object_create_lmem(i915, PAGE_ALIGN(size),
> >
> > I915_BO_ALLOC_CONTIGUOUS);
> > - else
> > + if (IS_ERR(obj))
> > + goto out_put_rpm;
> > + } else {
> > obj = i915_gem_object_create_internal(i915, PAGE_ALIGN(size));
> > - if (IS_ERR(obj))
> > - goto out_put_rpm;
> > + if (IS_ERR(obj))
> > + goto out_put_rpm;
> > +
> > + i915_gem_object_set_cache_coherency(obj,
> > I915_CACHE_NONE);
> > + }
> >
> > vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, 0);
> > if (IS_ERR(vma)) {
> > --
> > 2.41.0
>
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH v2] drm/i915: Flush WC GGTT only on required platforms
gen8_ggtt_invalidate() is only needed for limited set of platforms
where GGTT is mapped as WC otherwise this can cause unwanted
side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not
valid.
v2: Add a func to detect wc ggtt detection (Ville)
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Jonathan Cavitt
Cc: John Harrison
Cc: Andi Shyti
Cc: Ville Syrjälä
Cc: # v6.2+
Suggested-by: Matt Roper
Signed-off-by: Nirmoy Das
Acked-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 35 +++-
1 file changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632..401667f83f96 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -195,6 +195,21 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
spin_unlock_irq(>lock);
}
+static bool needs_wc_ggtt_mapping(struct drm_i915_private *i915)
+{
+ /*
+* On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
+* will be dropped. For WC mappings in general we have 64 byte burst
+* writes when the WC buffer is flushed, so we can't use it, but have to
+* resort to an uncached mapping. The WC issue is easily caught by the
+* readback check when writing GTT PTE entries.
+*/
+ if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
+ return true;
+
+ return false;
+}
+
static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
{
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
@@ -202,8 +217,12 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
/*
* Note that as an uncached mmio write, this will flush the
* WCB of the writes into the GGTT before it triggers the invalidate.
+*
+* Only perform this when GGTT is mapped as WC, see ggtt_probe_common().
*/
- intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ if (needs_wc_ggtt_mapping(ggtt->vm.i915))
+ intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
+ GFX_FLSH_CNTL_EN);
}
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -1126,17 +1145,11 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt,
u64 size)
GEM_WARN_ON(pci_resource_len(pdev, GEN4_GTTMMADR_BAR) !=
gen6_gttmmadr_size(i915));
phys_addr = pci_resource_start(pdev, GEN4_GTTMMADR_BAR) +
gen6_gttadr_offset(i915);
- /*
-* On BXT+/ICL+ writes larger than 64 bit to the GTT pagetable range
-* will be dropped. For WC mappings in general we have 64 byte burst
-* writes when the WC buffer is flushed, so we can't use it, but have to
-* resort to an uncached mapping. The WC issue is easily caught by the
-* readback check when writing GTT PTE entries.
-*/
- if (IS_GEN9_LP(i915) || GRAPHICS_VER(i915) >= 11)
- ggtt->gsm = ioremap(phys_addr, size);
- else
+ if (needs_wc_ggtt_mapping(i915))
ggtt->gsm = ioremap_wc(phys_addr, size);
+ else
+ ggtt->gsm = ioremap(phys_addr, size);
+
if (!ggtt->gsm) {
drm_err(>drm, "Failed to map the ggtt page table\n");
return -ENOMEM;
--
2.41.0
Re: [Intel-gfx] [PATCH v2] debugobjects: stop accessing objects after releasing spinlock
On Mon, Sep 25 2023 at 15:13, Andrzej Hajda wrote: > After spinlock release object can be modified/freed by concurrent thread. > Using it in such case is error prone, even for printing object state. It cannot be freed. If that happens then the calling code will have an UAF problem on the tracked item too. If there is a concurrent modification then again, the calling code is lacking serialization on the tracked object. debugobject fundamentally relies on the call site being consistent simply because it _cannot_ invoke the fixup callbacks with the hash bucket lock held. What's the actualy problem you are trying to solve here. The changelog does not explain anything except of handwaving about modified/freed. Thanks, tglx
[Intel-gfx] [PATCH 4/4] drm/i915: Fix glk+ degamma LUT conversions
From: Ville Syrjälä
The current implementation of change_lut_val_precision() is just
a convoluted way of shifting by 8. Implement the proper rounding
by just using drm_color_lut_extract() and intel_color_lut_pack()
like everyone else does.
And as the uapi can't handle >=1.0 values but the hardware
can we need to clamp the results appropriately in the readout
path.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 54 +++---
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index a4b30614bd63..1cfbb3650304 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1526,14 +1526,27 @@ static int glk_degamma_lut_size(struct drm_i915_private
*i915)
return 35;
}
-/*
- * change_lut_val_precision: helper function to upscale or downscale lut
values.
- * Parameters 'to' and 'from' needs to be less than 32. This should be
sufficient
- * as currently there are no lut values exceeding 32 bit.
- */
-static u32 change_lut_val_precision(u32 lut_val, int to, int from)
+static u32 glk_degamma_lut(const struct drm_color_lut *color)
+{
+ return color->green;
+}
+
+static void glk_degamma_lut_pack(struct drm_color_lut *entry, u32 val)
+{
+ /* PRE_CSC_GAMC_DATA is 3.16, clamp to 0.16 */
+ entry->red = entry->green = entry->blue = min(val, 0xu);
+}
+
+static u32 mtl_degamma_lut(const struct drm_color_lut *color)
+{
+ return drm_color_lut_extract(color->green, 24);
+}
+
+static void mtl_degamma_lut_pack(struct drm_color_lut *entry, u32 val)
{
- return mul_u32_u32(lut_val, (1 << to)) / (1 << from);
+ /* PRE_CSC_GAMC_DATA is 3.24, clamp to 0.16 */
+ entry->red = entry->green = entry->blue =
+ intel_color_lut_pack(min(val, 0xffu), 24);
}
static void glk_load_degamma_lut(const struct intel_crtc_state *crtc_state,
@@ -1570,20 +1583,16 @@ static void glk_load_degamma_lut(const struct
intel_crtc_state *crtc_state,
* ToDo: Extend to max 7.0. Enable 32 bit input value
* as compared to just 16 to achieve this.
*/
- u32 lut_val;
-
- if (DISPLAY_VER(i915) >= 14)
- lut_val = change_lut_val_precision(lut[i].green, 24,
16);
- else
- lut_val = lut[i].green;
-
ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
- lut_val);
+ DISPLAY_VER(i915) >= 14 ?
+ mtl_degamma_lut([i]) :
glk_degamma_lut([i]));
}
/* Clamp values > 1.0. */
while (i++ < glk_degamma_lut_size(i915))
- ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe), 1 << 16);
+ ilk_lut_write(crtc_state, PRE_CSC_GAMC_DATA(pipe),
+ DISPLAY_VER(i915) >= 14 ?
+ 1 << 24 : 1 << 16);
ilk_lut_write(crtc_state, PRE_CSC_GAMC_INDEX(pipe), 0);
}
@@ -3573,17 +3582,10 @@ static struct drm_property_blob
*glk_read_degamma_lut(struct intel_crtc *crtc)
for (i = 0; i < lut_size; i++) {
u32 val = intel_de_read_fw(dev_priv, PRE_CSC_GAMC_DATA(pipe));
- /*
-* For MTL and beyond, convert back the 24 bit lut values
-* read from HW to 16 bit values to maintain parity with
-* userspace values
-*/
if (DISPLAY_VER(dev_priv) >= 14)
- val = change_lut_val_precision(val, 16, 24);
-
- lut[i].red = val;
- lut[i].green = val;
- lut[i].blue = val;
+ mtl_degamma_lut_pack([i], val);
+ else
+ glk_degamma_lut_pack([i], val);
}
intel_de_write_fw(dev_priv, PRE_CSC_GAMC_INDEX(pipe),
--
2.41.0
[Intel-gfx] [PATCH 3/4] drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack()
From: Ville Syrjälä
Use min() instead of clamp() since the color values
involved are unsigned. No functional changes.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index b01f463af861..a4b30614bd63 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -909,7 +909,7 @@ static void i965_lut_10p6_pack(struct drm_color_lut *entry,
u32 ldw, u32 udw)
static u16 i965_lut_11p6_max_pack(u32 val)
{
/* PIPEGCMAX is 11.6, clamp to 10.6 */
- return clamp_val(val, 0, 0x);
+ return min(val, 0xu);
}
static u32 ilk_lut_10(const struct drm_color_lut *color)
--
2.41.0
[Intel-gfx] [PATCH 2/4] drm/i915: Adjust LUT rounding rules
From: Ville Syrjälä
drm_color_lut_extract() rounding was changed to follow the
OpenGL int<->float conversion rules. Adjust intel_color_lut_pack()
to match.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 2a2a163ea652..b01f463af861 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -785,14 +785,12 @@ static void chv_assign_csc(struct intel_crtc_state
*crtc_state)
/* convert hw value with given bit_precision to lut property val */
static u32 intel_color_lut_pack(u32 val, int bit_precision)
{
- u32 max = 0x >> (16 - bit_precision);
-
- val = clamp_val(val, 0, max);
-
- if (bit_precision < 16)
- val <<= 16 - bit_precision;
-
- return val;
+ if (bit_precision > 16)
+ return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(val, (1 << 16) - 1),
+(1 << bit_precision) - 1);
+ else
+ return DIV_ROUND_CLOSEST(val * ((1 << 16) - 1),
+(1 << bit_precision) - 1);
}
static u32 i9xx_lut_8(const struct drm_color_lut *color)
--
2.41.0
[Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding
From: Ville Syrjälä
The current implementation of drm_color_lut_extract()
generates weird results. Eg. if we go through all the
values for 16->8bpc conversion we see the following pattern:
inout (count)
0 - 7f -> 0 (128)
80 - 17f -> 1 (256)
180 - 27f -> 2 (256)
280 - 37f -> 3 (256)
...
fb80 - fc7f -> fc (256)
fc80 - fd7f -> fd (256)
fd80 - fe7f -> fe (256)
fe80 - -> ff (384)
So less values map to 0 and more values map 0xff, which
doesn't seem particularly great.
To get just the same number of input values to map to
the same output values we'd just need to drop the rounding
entrirely. But perhaps a better idea would be to follow the
OpenGL int<->float conversion rules, in which case we get
the following results:
inout (count)
0 - 80 -> 0 (129)
81 - 181 -> 1 (257)
182 - 282 -> 2 (257)
283 - 383 -> 3 (257)
...
fc7c - fd7c -> fc (257)
fd7d - fe7d -> fd (257)
fe7e - ff7e -> fe (257)
ff7f - -> ff (129)
Note that since the divisor is constant the compiler
is able to optimize away the integer division in most
cases. The only exception is the _ULL() case on 32bit
architectures since that gets emitted as inline asm
via do_div() and thus the compiler doesn't get to
optimize it.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_color_mgmt.h | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 81c298488b0c..6be3cbe18944 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -36,20 +36,16 @@ struct drm_plane;
*
* Extract a degamma/gamma LUT value provided by user (in the form of
* _color_lut entries) and round it to the precision supported by the
- * hardware.
+ * hardware, following OpenGL int<->float conversion rules.
*/
static inline u32 drm_color_lut_extract(u32 user_input, int bit_precision)
{
- u32 val = user_input;
- u32 max = 0x >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
+ if (bit_precision > 16)
+ return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(user_input, (1 <<
bit_precision) - 1),
+(1 << 16) - 1);
+ else
+ return DIV_ROUND_CLOSEST(user_input * ((1 << bit_precision) -
1),
+(1 << 16) - 1);
}
u64 drm_color_ctm_s31_32_to_qm_n(u64 user_input, u32 m, u32 n);
--
2.41.0
[Intel-gfx] [PATCH 0/4] drm/i915: Fix LUT rounding
From: Ville Syrjälä The current LUT rounding is generating weird results. Adjust it to follow the OpenGL int<->float conversion rules. Ville Syrjälä (4): drm: Fix color LUT rounding drm/i915: Adjust LUT rounding rules drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack() drm/i915: Fix glk+ degamma LUT conversions drivers/gpu/drm/i915/display/intel_color.c | 70 +++--- include/drm/drm_color_mgmt.h | 18 +++--- 2 files changed, 42 insertions(+), 46 deletions(-) -- 2.41.0
Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms
On 10/13/2023 2:55 PM, Ville Syrjälä wrote:
On Fri, Oct 13, 2023 at 02:28:21PM +0200, Nirmoy Das wrote:
Hi Ville,
On 10/13/2023 12:50 PM, Ville Syrjälä wrote:
On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote:
gen8_ggtt_invalidate() is only needed for limitted set of platforms
where GGTT is mapped as WC
I know there is supposed to be some kind hw snooping of the ggtt
pte writes to invalidate the tlb, but are we sure GFX_FLSH_CNTL
has no other side effects we depend on?
I spent some time searching through the gfxspec. This GFX_FLSH_CNTL
register only seems to be for
invalidating TLB for GUnit and (from git log ) we started to do that to
enable WC based GGTT updates.
So if I am not missing anything obvious then this should be safe.
OK.
The only code related complaint I have is that you are now duplicating
that same platform check in two different places. It's always better to
have a single point of truth instead of two or more, so that there is
no risk of introducing bugs due to mismatches.
I agree. I will resend with a static helper function to detect that.
Thanks,
Nirmoy
Regards,
Nirmoy
otherwise this can cause unwanted
side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not
valid.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Jonathan Cavitt
Cc: John Harrison
Cc: Andi Shyti
Cc: # v6.2+
Suggested-by: Matt Roper
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632..c2858d434bce 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -197,13 +197,17 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
{
+ struct drm_i915_private *i915 = ggtt->vm.i915;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
/*
* Note that as an uncached mmio write, this will flush the
* WCB of the writes into the GGTT before it triggers the invalidate.
+*
+* Only perform this when GGTT is mapped as WC, see ggtt_probe_common().
*/
- intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
+ intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
GFX_FLSH_CNTL_EN);
}
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
--
2.41.0
Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms
On Fri, Oct 13, 2023 at 02:28:21PM +0200, Nirmoy Das wrote:
> Hi Ville,
>
> On 10/13/2023 12:50 PM, Ville Syrjälä wrote:
> > On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote:
> >> gen8_ggtt_invalidate() is only needed for limitted set of platforms
> >> where GGTT is mapped as WC
> > I know there is supposed to be some kind hw snooping of the ggtt
> > pte writes to invalidate the tlb, but are we sure GFX_FLSH_CNTL
> > has no other side effects we depend on?
>
> I spent some time searching through the gfxspec. This GFX_FLSH_CNTL
> register only seems to be for
>
> invalidating TLB for GUnit and (from git log ) we started to do that to
> enable WC based GGTT updates.
>
>
> So if I am not missing anything obvious then this should be safe.
OK.
The only code related complaint I have is that you are now duplicating
that same platform check in two different places. It's always better to
have a single point of truth instead of two or more, so that there is
no risk of introducing bugs due to mismatches.
>
>
> Regards,
>
> Nirmoy
>
> >
> >> otherwise this can cause unwanted
> >> side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not
> >> valid.
> >>
> >> Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> >> Cc: Rodrigo Vivi
> >> Cc: Tvrtko Ursulin
> >> Cc: Joonas Lahtinen
> >> Cc: Jani Nikula
> >> Cc: Jonathan Cavitt
> >> Cc: John Harrison
> >> Cc: Andi Shyti
> >> Cc: # v6.2+
> >> Suggested-by: Matt Roper
> >> Signed-off-by: Nirmoy Das
> >> ---
> >> drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 +-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> >> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> >> index 4d7d88b92632..c2858d434bce 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> >> @@ -197,13 +197,17 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
> >>
> >> static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
> >> {
> >> + struct drm_i915_private *i915 = ggtt->vm.i915;
> >>struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> >>
> >>/*
> >> * Note that as an uncached mmio write, this will flush the
> >> * WCB of the writes into the GGTT before it triggers the invalidate.
> >> + *
> >> + * Only perform this when GGTT is mapped as WC, see ggtt_probe_common().
> >> */
> >> - intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
> >> + if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
> >> + intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
> >> GFX_FLSH_CNTL_EN);
> >> }
> >>
> >> static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
> >> --
> >> 2.41.0
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove the modparam verbose_state_checks
== Series Details == Series: drm/i915: Remove the modparam verbose_state_checks URL : https://patchwork.freedesktop.org/series/125047/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13746_full -> Patchwork_125047v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_125047v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_125047v1_full, please notify your bug team (lgci.bug.fil...@intel.com) 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_125047v1_full: ### IGT changes ### Possible regressions * igt@kms_hdr@bpc-switch-suspend@pipe-a-dp-1: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13746/shard-apl1/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-apl4/igt@kms_hdr@bpc-switch-susp...@pipe-a-dp-1.html * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom: - shard-rkl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13746/shard-rkl-6/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-rkl-7/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html Known issues Here are the changes found in Patchwork_125047v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@render-ccs: - shard-dg2: NOTRUN -> [FAIL][5] ([i915#6122]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-dg2-7/igt@api_intel...@render-ccs.html * igt@drm_fdinfo@busy-hang@bcs0: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#8414]) +10 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-dg2-3/igt@drm_fdinfo@busy-h...@bcs0.html * igt@gem_basic@multigpu-create-close: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#7697]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-dg2-3/igt@gem_ba...@multigpu-create-close.html * igt@gem_ctx_persistence@engines-cleanup: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-snb4/igt@gem_ctx_persiste...@engines-cleanup.html * igt@gem_ctx_persistence@hang: - shard-dg2: NOTRUN -> [SKIP][9] ([i915#8555]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-dg2-7/igt@gem_ctx_persiste...@hang.html * igt@gem_ctx_sseu@mmap-args: - shard-tglu: NOTRUN -> [SKIP][10] ([i915#280]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-tglu-4/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@hibernate: - shard-tglu: [PASS][11] -> [ABORT][12] ([i915#7975] / [i915#8213] / [i915#8398]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13746/shard-tglu-3/igt@gem_...@hibernate.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-tglu-10/igt@gem_...@hibernate.html * igt@gem_eio@unwedge-stress: - shard-dg1: [PASS][13] -> [FAIL][14] ([i915#5784]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13746/shard-dg1-15/igt@gem_...@unwedge-stress.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-dg1-16/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-out-fence: - shard-rkl: NOTRUN -> [SKIP][15] ([i915#4525]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-rkl-7/igt@gem_exec_balan...@parallel-out-fence.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglu: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 other test fail [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13746/shard-tglu-6/igt@gem_exec_fair@basic-f...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-tglu-2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-pace-share: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#3539] / [i915#4852]) +1 other test skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-dg2-7/igt@gem_exec_f...@basic-pace-share.html * igt@gem_exec_fence@concurrent: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#4812]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_125047v1/shard-dg2-3/igt@gem_exec_fe...@concurrent.html * igt@gem_exec_params@rsvd2-dirt: -
Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms
Hi Ville,
On 10/13/2023 12:50 PM, Ville Syrjälä wrote:
On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote:
gen8_ggtt_invalidate() is only needed for limitted set of platforms
where GGTT is mapped as WC
I know there is supposed to be some kind hw snooping of the ggtt
pte writes to invalidate the tlb, but are we sure GFX_FLSH_CNTL
has no other side effects we depend on?
I spent some time searching through the gfxspec. This GFX_FLSH_CNTL
register only seems to be for
invalidating TLB for GUnit and (from git log ) we started to do that to
enable WC based GGTT updates.
So if I am not missing anything obvious then this should be safe.
Regards,
Nirmoy
otherwise this can cause unwanted
side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not
valid.
Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Jonathan Cavitt
Cc: John Harrison
Cc: Andi Shyti
Cc: # v6.2+
Suggested-by: Matt Roper
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 4d7d88b92632..c2858d434bce 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -197,13 +197,17 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
{
+ struct drm_i915_private *i915 = ggtt->vm.i915;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
/*
* Note that as an uncached mmio write, this will flush the
* WCB of the writes into the GGTT before it triggers the invalidate.
+*
+* Only perform this when GGTT is mapped as WC, see ggtt_probe_common().
*/
- intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
+ if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
+ intel_uncore_write_fw(uncore, GFX_FLSH_CNTL_GEN6,
GFX_FLSH_CNTL_EN);
}
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
--
2.41.0
Re: [Intel-gfx] [PATCH] drm/i915: Retry gtt fault when out of fence register
Hi Ville,
> If we can't find a free fence register to handle a fault in the GMADR
> range just return VM_FAULT_NOPAGE without populating the PTE so that
> userspace will retry the access and trigger another fault. Eventually
> we should find a free fence and the fault will get properly handled.
>
> A further improvement idea might be to reserve a fence (or one per CPU?)
> for the express purpose of handling faults without having to retry. But
> that would require some additional work.
>
> Looks like this may have gotten broken originally by
> commit 39965b376601 ("drm/i915: don't trash the gtt when running out of
> fences")
> as that changed the errno to -EDEADLK which wasn't handle by the gtt
> fault code either. But later in commit 2feeb52859fc ("drm/i915/gt: Fix
> -EDEADLK handling regression") I changed it again to -ENOBUFS as -EDEADLK
> was now getting used for the ww mutex dance. So this fix only makes
> sense after that last commit.
>
> Cc: sta...@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9479
> Fixes: 2feeb52859fc ("drm/i915/gt: Fix -EDEADLK handling regression")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Andi Shyti
Andi
