[Intel-gfx] ✗ Fi.CI.IGT: failure for i915/mtl: Enable idle messaging for GSC CS (rev2)
== Series Details ==
Series: i915/mtl: Enable idle messaging for GSC CS (rev2)
URL : https://patchwork.freedesktop.org/series/110349/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110349v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110349v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110349v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110349v2_full:
### IGT changes ###
Possible regressions
* igt@i915_suspend@forcewake:
- shard-snb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb7/igt@i915_susp...@forcewake.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/shard-snb6/igt@i915_susp...@forcewake.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ppgtt@blt-vs-render-ctx0:
- {shard-rkl}:[PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-rkl-1/igt@gem_pp...@blt-vs-render-ctx0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/shard-rkl-5/igt@gem_pp...@blt-vs-render-ctx0.html
Known issues
Here are the changes found in Patchwork_110349v2_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-snb: ([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], [FAIL][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]) ([i915#4338])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb7/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb7/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb7/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb7/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb4/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb4/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb4/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb4/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb4/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb2/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb2/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-snb2/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/shard-snb7/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/shard-snb7/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/shard-snb7/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11
[Intel-gfx] ✗ Fi.CI.IGT: failure for mei: add timeout to send (rev2)
== Series Details == Series: mei: add timeout to send (rev2) URL : https://patchwork.freedesktop.org/series/110495/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110495v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110495v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110495v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110495v2_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@preempt-other-chain: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-skl2/igt@gem_exec_sched...@preempt-other-chain.html Known issues Here are the changes found in Patchwork_110495v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-hang: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-hang.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][3] ([i915#3354]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][4] -> [FAIL][5] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/igt@gem_exec_f...@basic-deadline.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-glk9/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb1/igt@gem_huc_c...@huc-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-skl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-skl7/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#7409]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-glk1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [INCOMPLETE][15] ([i915#7248]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-skl9/igt@gem_pr...@exhaustion.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-apl3/igt@gem_workarou...@suspend-resume.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-apl8/igt@gem_workarou...@suspend-resume.html * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-skl9/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-hpd-for-each-pipe: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/shard-skl7/igt@kms_chamel...@dp-hpd-for-each-pipe.html * igt@kms_chamelium@vga-hpd-with-enabled-mode: - shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/P
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update workaround documentation (rev2)
== Series Details ==
Series: drm/i915: Update workaround documentation (rev2)
URL : https://patchwork.freedesktop.org/series/110639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110639v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/index.html
Participating hosts (40 -> 39)
--
Additional (3): fi-kbl-soraka fi-hsw-4770 bat-atsm-1
Missing(4): bat-rpls-1 fi-rkl-11600 bat-dg1-6 bat-dg2-11
Known issues
Here are the changes found in Patchwork_110639v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][2] -> [FAIL][3] ([i915#7229])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.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_110639v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@gem_tiled_blits@basic:
- fi-pnv-d510:[PASS][7] -> [SKIP][8] ([fdo#109271])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: NOTRUN -> [DMESG-WARN][9] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3012])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][11] ([i915#7099])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][12] ([i915#1886])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:NOTRUN -> [INCOMPLETE][13] ([i915#4785])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +7
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +7
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1072]) +3
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][17] ([fdo#109271] / [i915#4312] /
[i915#5594])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][18] ([i915#2582]) -> [PASS][19] +4 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@fb...@read.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/bat-rpls-2/igt@fb...@read.html
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][20] ([i915#7029]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[21]:
https://intel-gfx-ci.01.org/tree/dr
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: CAGF and RC6 changes for MTL (rev13)
== Series Details ==
Series: i915: CAGF and RC6 changes for MTL (rev13)
URL : https://patchwork.freedesktop.org/series/108156/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_108156v13
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_108156v13 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108156v13, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/index.html
Participating hosts (40 -> 38)
--
Additional (2): fi-hsw-4770 bat-atsm-1
Missing(4): bat-rpls-1 bat-kbl-2 fi-rkl-11600 bat-dg2-11
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108156v13:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@dmabuf:
- fi-bxt-dsi: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-bxt-dsi/igt@i915_selftest@l...@dmabuf.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/fi-bxt-dsi/igt@i915_selftest@l...@dmabuf.html
Known issues
Here are the changes found in Patchwork_108156v13 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][3] -> [FAIL][4] ([i915#7229])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#7056])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@migrate:
- bat-adlp-4: [PASS][8] -> [INCOMPLETE][9] ([i915#7308] /
[i915#7348])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-adlp-4/igt@i915_selftest@l...@migrate.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/bat-adlp-4/igt@i915_selftest@l...@migrate.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271]) +9 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1072]) +3
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- bat-adlp-4: NOTRUN -> [FAIL][13] ([i915#4312])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/bat-adlp-4/igt@run...@aborted.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][14] ([i915#7029]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v13/bat-dg2-8/igt@gem_huc_c...@huc-copy.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#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/in
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/tests/drm_kunit_helpers.o
Caused by commit
44a3928324e9 ("drm/tests: Add Kunit Helpers")
I have used the drm-misc tree from next-20221115 for today.
--
Cheers,
Stephen Rothwell
pgpysbHsfqCz6.pgp
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On Tue, Nov 15, 2022 at 03:15:03PM -0800, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 08:33:47AM -0800, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 04:20:54PM +, Matthew Auld wrote:
On 15/11/2022 16:15, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 11:05:21AM +, Matthew Auld wrote:
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was that
changed somewhere?
No, it applies to any vma (partial or non-partial).
It was so from the beginning.
Doesn't __i915_vma_unbind_async() return an error when mm.pages !=
vma->pages? IIRC this was discussed before. Just trying to think
about the consequences of this change.
I am not seeing any such restriction. Let me probe and check if there
is any such restriction anywhere in the call chain.
I checked and I am not seeing any restriction anywher in the call chain.
Note that just like binding case, unbinding is also synchronous unless
there is a pending activity, in which case, it will be asynchronous.
Niranjana
Niranjana
Niranjana
Niranjana
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct
i915_address_space *vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1727,7 +1729,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1787,7 +1803,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(&vma->vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1798,7 +1814,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(&vma->vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(&vma->vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(&vma->vm->mutex);
+ /*
+ * Ensure any asynchronous binding is complete while using
+ * async unbind as we will be releasing the vma here.
+ */
+ if (async && i915_active_wait(&vma->active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_i
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: CAGF and RC6 changes for MTL (rev13)
== Series Details == Series: i915: CAGF and RC6 changes for MTL (rev13) URL : https://patchwork.freedesktop.org/series/108156/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
Hi all,
On Wed, 16 Nov 2022 10:47:52 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>
> between commit:
>
> eca13f3c67b6 ("drm/amdgpu: use the last IB as gang leader v2")
>
> from the drm-misc-fixes tree and commit:
>
> 1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index de5cb056c9ad,0528c2b1db6e..
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@@ -1197,10 -1201,7 +1203,10 @@@ static int amdgpu_cs_sync_rings(struct
> }
>
> for (i = 0; i < p->gang_size; ++i) {
> +if (p->jobs[i] == leader)
> +continue;
> +
> - r = amdgpu_sync_clone(&leader->sync, &p->jobs[i]->sync);
> + r = amdgpu_sync_push_to_job(&p->sync, p->jobs[i]);
> if (r)
> return r;
> }
> @@@ -1241,14 -1243,11 +1247,14 @@@ static int amdgpu_cs_submit(struct amdg
> for (i = 0; i < p->gang_size; ++i)
> drm_sched_job_arm(&p->jobs[i]->base);
>
> -for (i = 0; i < (p->gang_size - 1); ++i) {
> +for (i = 0; i < p->gang_size; ++i) {
> struct dma_fence *fence;
>
> +if (p->jobs[i] == leader)
> +continue;
> +
> fence = &p->jobs[i]->base.s_fence->scheduled;
> - r = amdgpu_sync_fence(&leader->sync, fence);
> + r = drm_sched_job_add_dependency(&leader->base, fence);
> if (r)
> goto error_cleanup;
> }
Note that I had to keep the declaration of "leader" in amdgpu_cs_sync_rings().
--
Cheers,
Stephen Rothwell
pgpITu1TzJMEc.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Media GT and Render GT share common GGTT (rev4)
== Series Details ==
Series: drm/i915/mtl: Media GT and Render GT share common GGTT (rev4)
URL : https://patchwork.freedesktop.org/series/110321/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110321v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/index.html
Participating hosts (40 -> 38)
--
Additional (1): fi-hsw-4770
Missing(3): bat-rpls-1 bat-kbl-2 bat-dg2-11
Known issues
Here are the changes found in Patchwork_110321v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_parallel@engines@contexts:
- fi-bdw-gvtdvm: [PASS][3] -> [INCOMPLETE][4] ([i915#7506])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-bdw-gvtdvm/igt@gem_exec_parallel@engi...@contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-bdw-gvtdvm/igt@gem_exec_parallel@engi...@contexts.html
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3012])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([fdo#111827])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-vga1:
- fi-pnv-d510:[PASS][9] -> [FAIL][10] ([i915#2122])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vbl...@a-vga1.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1072]) +3
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-bdw-gvtdvm: NOTRUN -> [FAIL][12] ([i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-bdw-gvtdvm/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][13] ([i915#2582]) -> [PASS][14] +4 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@fb...@read.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/bat-rpls-2/igt@fb...@read.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}: [DMESG-WARN][15] ([i915#6434]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][17] ([i915#7029]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@slpc:
- {bat-adln-1}: [DMESG-FAIL][19] ([i915#6997]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-adln-1/igt@i915_selftest@l...@slpc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/bat-adln-1/igt@i915_selftest@l...@slpc.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][21] ([i915#4817]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of
[Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
include/drm/gpu_scheduler.h
between commit:
2cf9886e2816 ("drm/scheduler: remove drm_sched_dependency_optimized")
from the drm-misc tree and commit:
06a2d7cc3f04 ("drm/amdgpu: revert "implement tdr advanced mode"")
from the amdgpu tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/drm/gpu_scheduler.h
index cec147f7c50b,0168ff469ae0..
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@@ -532,10 -528,9 +532,7 @@@ void drm_sched_wakeup(struct drm_gpu_sc
void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job
*bad);
void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery);
void drm_sched_resubmit_jobs(struct drm_gpu_scheduler *sched);
- void drm_sched_resubmit_jobs_ext(struct drm_gpu_scheduler *sched, int max);
void drm_sched_increase_karma(struct drm_sched_job *bad);
- void drm_sched_reset_karma(struct drm_sched_job *bad);
- void drm_sched_increase_karma_ext(struct drm_sched_job *bad, int type);
-bool drm_sched_dependency_optimized(struct dma_fence* fence,
- struct drm_sched_entity *entity);
void drm_sched_fault(struct drm_gpu_scheduler *sched);
void drm_sched_job_kickout(struct drm_sched_job *s_job);
pgpwcoB8kxuct.pgp
Description: OpenPGP digital signature
[Intel-gfx] linux-next: manual merge of the drm-misc tree with the origin tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/vc4/vc4_hdmi.c
between commit:
682f99b8ae88 ("drm/vc4: hdmi: Take our lock to reset the link")
from the origin tree and commits:
d218750805a3 ("drm/vc4: hdmi: Pass vc4_hdmi to
vc4_hdmi_supports_scrambling()")
0a99962c0dbf ("drm/vc4: hdmi: Fix pointer dereference before check")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/vc4/vc4_hdmi.c
index d7fcc7a4c082,6b223a5fcf6f..
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@@ -349,12 -348,9 +348,13 @@@ static int vc4_hdmi_reset_link(struct d
if (!crtc_state->active)
return 0;
+ mutex_lock(&vc4_hdmi->mutex);
+
- if (!vc4_hdmi_supports_scrambling(encoder)) {
+ vc4_hdmi = connector_to_vc4_hdmi(connector);
- if (!vc4_hdmi_supports_scrambling(vc4_hdmi))
++ if (!vc4_hdmi_supports_scrambling(vc4_hdmi)) {
+ mutex_unlock(&vc4_hdmi->mutex);
return 0;
+ }
scrambling_needed =
vc4_hdmi_mode_needs_scrambling(&vc4_hdmi->saved_adjusted_mode,
vc4_hdmi->output_bpc,
pgpTYbxmt4CF_.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Media GT and Render GT share common GGTT (rev4)
== Series Details == Series: drm/i915/mtl: Media GT and Render GT share common GGTT (rev4) URL : https://patchwork.freedesktop.org/series/110321/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH] drm/i915: Fix unhandled deadlock in grab_vma()
Hi Thomas, It is a user-space application that crashes due to receiving an -ENOSPC. This occurs after code reaches the line below where grab_vma() fails (due to deadlock) and consequently i915_gem_evict_for_node() returns -ENOSPC. I provided the call stack for when this happens in my previous message: https://github.com/torvalds/linux/blame/59d0d52c30d4991ac4b329f049cc37118e00f5b0/drivers/gpu/drm/i915/i915_gem_evict.c#L386 Context: This crash is happening on an intel GeminiLake chromebook, when running a video seek h264 stress test, and it is reproducible 100%. To troubleshoot, I did a git bisect and found the following commit to be the culprit (which is when grab_vma() has been introduced): https://github.com/torvalds/linux/commit/7e00897be8bf13ef9c68c95a8e386b714c29ad95 I also have crash dumps and further logs that I can send you if needed. But please let me know how to share those with you, since pasting them here does not seem reasonable to me. Thanks, Mani On Mon, Nov 14, 2022 at 11:48 PM Thomas Hellström wrote: > > Hi, Mani. > > On 11/14/22 03:16, Mani Milani wrote: > > Thank you for your comments. > > > > To Thomas's point, the crash always seems to happen when the following > > sequence of events occurs: > > > > 1. When inside "i915_gem_evict_vm()", the call to > > "i915_gem_object_trylock(vma->obj, ww)" fails (due to deadlock), and > > eviction of a vma is skipped as a result. Basically if the code > > reaches here: > > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i915/i915_gem_evict.c#L468 > > And here is the stack dump for this scenario: > > Call Trace: > > > > dump_stack_lvl+0x68/0x95 > > i915_gem_evict_vm+0x1d2/0x369 > > eb_validate_vmas+0x54a/0x6ae > > eb_relocate_parse+0x4b/0xdb > > i915_gem_execbuffer2_ioctl+0x6f5/0xab6 > > ? i915_gem_object_prepare_write+0xfb/0xfb > > drm_ioctl_kernel+0xda/0x14d > > drm_ioctl+0x27f/0x3b7 > > ? i915_gem_object_prepare_write+0xfb/0xfb > > __se_sys_ioctl+0x7a/0xbc > > do_syscall_64+0x56/0xa1 > > ? exit_to_user_mode_prepare+0x3d/0x8c > > entry_SYSCALL_64_after_hwframe+0x61/0xcb > > RIP: 0033:0x78302de5fae7 > > Code: c0 0f 89 74 ff ff ff 48 83 c4 08 49 c7 c4 ff ff ff ff 5b 4c > > 89 e0 41 5c 41 5d 5d c3 0f 1f 80 00 00 00 00 b8 10 00 00 00 0f 05 <48> > > 3d 01 f0 ff ff 73 01 c3 48 8b 0d 51 c3 0c 00 f7 d8 64 89 01 48 > > RSP: 002b:7ffe64b87f78 EFLAGS: 0246 ORIG_RAX: 0010 > > RAX: ffda RBX: 03cc0047 RCX: 78302de5fae7 > > RDX: 7ffe64b87fd0 RSI: 40406469 RDI: 000d > > RBP: 7ffe64b87fa0 R08: 0013 R09: 03cc004d0950 > > R10: 0200 R11: 0246 R12: 000d > > R13: R14: 7ffe64b87fd0 R15: 40406469 > > > > It is worth noting that "i915_gem_evict_vm()" still returns success in > > this case. > > > > 2. After step 1 occurs, the next call to "grab_vma()" always fails > > (with "i915_gem_object_trylock(vma->obj, ww)" failing also due to > > deadlock), which then results in the crash. > > Here is the stack dump for this scenario: > > Call Trace: > > > > dump_stack_lvl+0x68/0x95 > > grab_vma+0x6c/0xd0 > > i915_gem_evict_for_node+0x178/0x23b > > i915_gem_gtt_reserve+0x5a/0x82 > > i915_vma_insert+0x295/0x29e > > i915_vma_pin_ww+0x41e/0x5c7 > > eb_validate_vmas+0x5f5/0x6ae > > eb_relocate_parse+0x4b/0xdb > > i915_gem_execbuffer2_ioctl+0x6f5/0xab6 > > ? i915_gem_object_prepare_write+0xfb/0xfb > > drm_ioctl_kernel+0xda/0x14d > > drm_ioctl+0x27f/0x3b7 > > ? i915_gem_object_prepare_write+0xfb/0xfb > > __se_sys_ioctl+0x7a/0xbc > > do_syscall_64+0x56/0xa1 > > ? exit_to_user_mode_prepare+0x3d/0x8c > > entry_SYSCALL_64_after_hwframe+0x61/0xcb > > RIP: 0033:0x78302de5fae7 > > Code: c0 0f 89 74 ff ff ff 48 83 c4 08 49 c7 c4 ff ff ff ff 5b 4c > > 89 e0 41 5c 41 5d 5d c3 0f 1f 80 00 00 00 00 b8 10 00 00 00 0f 05 <48> > > 3d 01 f0 ff ff 73 01 c3 48 8b 0d 51 c3 0c 00 f7 d8 64 89 01 48 > > RSP: 002b:7ffe64b87f78 EFLAGS: 0246 ORIG_RAX: 0010 > > RAX: ffda RBX: 03cc0047 RCX: 78302de5fae7 > > RDX: 7ffe64b87fd0 RSI: 40406469 RDI: 000d > > RBP: 7ffe64b87fa0 R08: 0013 R09: 03cc004d0950 > > R10: 0200 R11: 0246 R12: 000d > > R13: R14: 7ffe64b87fd0 R15: 40406469 > > > > > > My Notes: > > - I verified the two "i915_gem_object_trylock()" failures I mentioned > > above are due to deadlock by slightly modifying the code to call > > "i915_gem_object_lock()" only in those exact cases and subsequent to > > the trylock failure, only to look at the return error code. > > - The two cases mentioned above, are the only cases where > > "i915
[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
between commit:
eca13f3c67b6 ("drm/amdgpu: use the last IB as gang leader v2")
from the drm-misc-fixes tree and commit:
1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index de5cb056c9ad,0528c2b1db6e..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@@ -1197,10 -1201,7 +1203,10 @@@ static int amdgpu_cs_sync_rings(struct
}
for (i = 0; i < p->gang_size; ++i) {
+ if (p->jobs[i] == leader)
+ continue;
+
- r = amdgpu_sync_clone(&leader->sync, &p->jobs[i]->sync);
+ r = amdgpu_sync_push_to_job(&p->sync, p->jobs[i]);
if (r)
return r;
}
@@@ -1241,14 -1243,11 +1247,14 @@@ static int amdgpu_cs_submit(struct amdg
for (i = 0; i < p->gang_size; ++i)
drm_sched_job_arm(&p->jobs[i]->base);
- for (i = 0; i < (p->gang_size - 1); ++i) {
+ for (i = 0; i < p->gang_size; ++i) {
struct dma_fence *fence;
+ if (p->jobs[i] == leader)
+ continue;
+
fence = &p->jobs[i]->base.s_fence->scheduled;
- r = amdgpu_sync_fence(&leader->sync, fence);
+ r = drm_sched_job_add_dependency(&leader->base, fence);
if (r)
goto error_cleanup;
}
pgpawrKK9RSSa.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix build failure with debug and extra logging enabled
== Series Details ==
Series: drm/i915: Fix build failure with debug and extra logging enabled
URL : https://patchwork.freedesktop.org/series/110930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110930v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/index.html
Participating hosts (40 -> 39)
--
Additional (1): fi-hsw-4770
Missing(2): bat-rpls-1 bat-dg2-11
Known issues
Here are the changes found in Patchwork_110930v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#7056])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3012])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1072]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][7] ([i915#2582]) -> [PASS][8] +4 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@fb...@read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/bat-rpls-2/igt@fb...@read.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}: [DMESG-WARN][9] ([i915#6434]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][11] ([i915#7029]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/bat-dg2-8/igt@gem_huc_c...@huc-copy.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
[i915#7056]: https://gitlab.freedesktop.org/drm/intel/issues/7056
[i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
Build changes
-
* Linux: CI_DRM_12382 -> Patchwork_110930v1
CI-20190529: 20190529
CI_DRM_12382: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7057: e2138d48c2c506816868c16cf3ba64f81bdead41 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110930v1: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
560f043bb4b7 drm/i915: Fix build failure with debug and extra logging enabled
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/index.html
Re: [Intel-gfx] [PATCH] drm/i915: Update workaround documentation
On Tue, Nov 15, 2022 at 11:26:11AM -0800, Lucas De Marchi wrote: > There were several updates in the driver on how the workarounds are > handled since its documentation was written. Update the documentation to > reflect the current reality. > > v2: > - Remove footnote that was wrongly referenced, adding back the > reference in the correct paragraph. > - Remove "Display workarounds" and just mention "display IP" under > "Other" category since all of them are peppered around the driver. > > Cc: Matt Roper > Signed-off-by: Lucas De Marchi > Acked-by: Balasubramani Vivekanandan # > v1 Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 80 + > 1 file changed, 50 insertions(+), 30 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 213160f29ec3..290f9f91fdf4 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -18,42 +18,62 @@ > /** > * DOC: Hardware workarounds > * > - * This file is intended as a central place to implement most [1]_ of the > - * required workarounds for hardware to work as originally intended. They > fall > - * in five basic categories depending on how/when they are applied: > + * Hardware workarounds are register programming documented to be executed in > + * the driver that fall outside of the normal programming sequences for a > + * platform. There are some basic categories of workarounds, depending on > + * how/when they are applied: > * > - * - Workarounds that touch registers that are saved/restored to/from the HW > - * context image. The list is emitted (via Load Register Immediate > commands) > - * everytime a new context is created. > - * - GT workarounds. The list of these WAs is applied whenever these > registers > - * revert to default values (on GPU reset, suspend/resume [2]_, etc..). > - * - Display workarounds. The list is applied during display clock-gating > - * initialization. > - * - Workarounds that whitelist a privileged register, so that UMDs can > manage > - * them directly. This is just a special case of a MMMIO workaround (as we > - * write the list of these to/be-whitelisted registers to some special HW > - * registers). > - * - Workaround batchbuffers, that get executed automatically by the hardware > - * on every HW context restore. > + * - Context workarounds: workarounds that touch registers that are > + * saved/restored to/from the HW context image. The list is emitted (via > Load > + * Register Immediate commands) once when initializing the device and > saved in > + * the default context. That default context is then used on every context > + * creation to have a "primed golden context", i.e. a context image that > + * already contains the changes needed to all the registers. > * > - * .. [1] Please notice that there are other WAs that, due to their nature, > - *cannot be applied from a central place. Those are peppered around the > rest > - *of the code, as needed. > + * - Engine workarounds: the list of these WAs is applied whenever the > specific > + * engine is reset. It's also possible that a set of engine classes share a > + * common power domain and they are reset together. This happens on some > + * platforms with render and compute engines. In this case (at least) one > of > + * them need to keeep the workaround programming: the approach taken in the > + * driver is to tie those workarounds to the first compute/render engine > that > + * is registered. When executing with GuC submission, engine resets are > + * outside of kernel driver control, hence the list of registers involved > in > + * written once, on engine initialization, and then passed to GuC, that > + * saves/restores their values before/after the reset takes place. See > + * ``drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c`` for reference. > * > - * .. [2] Technically, some registers are powercontext saved & restored, so > they > - *survive a suspend/resume. In practice, writing them again is not too > - *costly and simplifies things. We can revisit this in the future. > + * - GT workarounds: the list of these WAs is applied whenever these > registers > + * revert to their default values: on GPU reset, suspend/resume [1]_, etc. > + * > + * - Register whitelist: some workarounds need to be implemented in > userspace, > + * but need to touch privileged registers. The whitelist in the kernel > + * instructs the hardware to allow the access to happen. From the kernel > side, > + * this is just a special case of a MMIO workaround (as we write the list > of > + * these to/be-whitelisted registers to some special HW registers). > + * > + * - Workaround batchbuffers: buffers that get executed automatically by the > + * hardware on every HW context restore. These buffers are created and > + *
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On Tue, Nov 15, 2022 at 08:33:47AM -0800, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 04:20:54PM +, Matthew Auld wrote:
On 15/11/2022 16:15, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 11:05:21AM +, Matthew Auld wrote:
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was that
changed somewhere?
No, it applies to any vma (partial or non-partial).
It was so from the beginning.
Doesn't __i915_vma_unbind_async() return an error when mm.pages !=
vma->pages? IIRC this was discussed before. Just trying to think
about the consequences of this change.
I am not seeing any such restriction. Let me probe and check if there
is any such restriction anywhere in the call chain.
I checked and I am not seeing any restriction anywher in the call chain.
Niranjana
Niranjana
Niranjana
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct
i915_address_space *vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1727,7 +1729,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1787,7 +1803,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(&vma->vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1798,7 +1814,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(&vma->vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(&vma->vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(&vma->vm->mutex);
+ /*
+ * Ensure any asynchronous binding is complete while using
+ * async unbind as we will be releasing the vma here.
+ */
+ if (async && i915_active_wait(&vma->active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h
b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/mtl: Enable idle messaging for GSC CS (rev2)
== Series Details ==
Series: i915/mtl: Enable idle messaging for GSC CS (rev2)
URL : https://patchwork.freedesktop.org/series/110349/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110349v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/index.html
Participating hosts (40 -> 38)
--
Additional (1): fi-hsw-4770
Missing(3): bat-rpls-1 bat-dg2-11 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_110349v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#3012])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][4] -> [FAIL][5] ([i915#6298])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1072]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][7] ([i915#2582]) -> [PASS][8] +4 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@fb...@read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/bat-rpls-2/igt@fb...@read.html
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][9] ([i915#7029]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/bat-dg2-8/igt@gem_huc_c...@huc-copy.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
[i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
[i915#7348]: https://gitlab.freedesktop.org/drm/intel/issues/7348
Build changes
-
* Linux: CI_DRM_12382 -> Patchwork_110349v2
CI-20190529: 20190529
CI_DRM_12382: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7057: e2138d48c2c506816868c16cf3ba64f81bdead41 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110349v2: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
2830a42563af drm/i915/mtl: Enable Idle Messaging for GSC CS
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110349v2/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for mei: add timeout to send (rev2)
== Series Details ==
Series: mei: add timeout to send (rev2)
URL : https://patchwork.freedesktop.org/series/110495/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110495v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/index.html
Participating hosts (40 -> 39)
--
Additional (1): fi-hsw-4770
Missing(2): bat-rpls-1 bat-dg2-11
Known issues
Here are the changes found in Patchwork_110495v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#3012])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([fdo#111827])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/fi-rkl-11600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1072]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}: [DMESG-WARN][6] ([i915#6434]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][8] ([i915#7029]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [INCOMPLETE][10] ([i915#4817]) -> [FAIL][11]
([fdo#103375])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
[i915#7346]: https://gitlab.freedesktop.org/drm/intel/issues/7346
Build changes
-
* Linux: CI_DRM_12382 -> Patchwork_110495v2
CI-20190529: 20190529
CI_DRM_12382: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7057: e2138d48c2c506816868c16cf3ba64f81bdead41 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110495v2: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
282c22ad7906 mei: add timeout to send
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v2/index.html
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ttm: never purge busy objects (rev2)
== Series Details == Series: drm/i915/ttm: never purge busy objects (rev2) URL : https://patchwork.freedesktop.org/series/110601/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110601v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110601v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110601v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110601v2_full: ### IGT changes ### Possible regressions * igt@gem_exec_fence@syncobj-repeat: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-skl2/igt@gem_exec_fe...@syncobj-repeat.html * igt@kms_plane_alpha_blend@alpha-7efc@pipe-b-edp-1: - shard-tglb: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb1/igt@kms_plane_alpha_blend@alpha-7...@pipe-b-edp-1.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-tglb8/igt@kms_plane_alpha_blend@alpha-7...@pipe-b-edp-1.html Known issues Here are the changes found in Patchwork_110601v2_full that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@unaligned-read: - shard-skl: [PASS][4] -> [DMESG-WARN][5] ([i915#1982]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-skl9/igt@fb...@unaligned-read.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-skl7/igt@fb...@unaligned-read.html * igt@gem_ctx_persistence@legacy-engines-hang: - shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hang.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][7] ([i915#3354]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb1/igt@gem_huc_c...@huc-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [INCOMPLETE][16] ([i915#7248]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-skl10/igt@gem_pr...@exhaustion.html * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3886]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-skl10/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@vga-hpd-enable-disable-mode: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-skl2/igt@kms_chamel...@vga-hpd-enable-disable-mode.html * igt@kms_chamelium@vga-hpd-with-enabled-mode: - shard-snb: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/shard-snb6/igt@kms_chamel...@vga-hpd-with-enabled-mode.html * igt@kms_cursor_crc@cursor-offscreen-32x10: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271]) +35 similar issues
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix vma allocator debug
== Series Details ==
Series: drm/i915: Fix vma allocator debug
URL : https://patchwork.freedesktop.org/series/110906/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110906v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110906v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110906v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110906v1_full:
### IGT changes ###
Possible regressions
* igt@gem_caching@writes:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-skl4/igt@gem_cach...@writes.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-skl4/igt@gem_cach...@writes.html
* igt@kms_universal_plane@universal-plane-pipe-d-functional:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb2/igt@kms_universal_pl...@universal-plane-pipe-d-functional.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-tglb8/igt@kms_universal_pl...@universal-plane-pipe-d-functional.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ppgtt@blt-vs-render-ctx0:
- {shard-rkl}:[PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-rkl-1/igt@gem_pp...@blt-vs-render-ctx0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-rkl-5/igt@gem_pp...@blt-vs-render-ctx0.html
Known issues
Here are the changes found in Patchwork_110906v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-hang:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hang.html
* igt@gem_eio@unwedge-stress:
- shard-snb: NOTRUN -> [FAIL][8] ([i915#3354])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-snb5/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2846])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@verify-random-ccs:
- shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-skl4/igt@gem_lmem_swapp...@verify-random-ccs.html
* igt@gem_pread@exhaustion:
- shard-skl: NOTRUN -> [INCOMPLETE][16] ([i915#7248])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-skl7/igt@gem_pr...@exhaustion.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-apl7/igt@gem_workarou...@suspend-resume-context.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-apl8/igt@gem_workarou...@suspend-resume-context.html
* igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +2
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/shard-skl7/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium@dp-hpd-for-each-pipe:
- shard-skl: NOTRUN -> [SKIP]
[Intel-gfx] [PATCH] drm/i915: Update workaround documentation
There were several updates in the driver on how the workarounds are handled since its documentation was written. Update the documentation to reflect the current reality. v2: - Remove footnote that was wrongly referenced, adding back the reference in the correct paragraph. - Remove "Display workarounds" and just mention "display IP" under "Other" category since all of them are peppered around the driver. Cc: Matt Roper Signed-off-by: Lucas De Marchi Acked-by: Balasubramani Vivekanandan # v1 --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 80 + 1 file changed, 50 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 213160f29ec3..290f9f91fdf4 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -18,42 +18,62 @@ /** * DOC: Hardware workarounds * - * This file is intended as a central place to implement most [1]_ of the - * required workarounds for hardware to work as originally intended. They fall - * in five basic categories depending on how/when they are applied: + * Hardware workarounds are register programming documented to be executed in + * the driver that fall outside of the normal programming sequences for a + * platform. There are some basic categories of workarounds, depending on + * how/when they are applied: * - * - Workarounds that touch registers that are saved/restored to/from the HW - * context image. The list is emitted (via Load Register Immediate commands) - * everytime a new context is created. - * - GT workarounds. The list of these WAs is applied whenever these registers - * revert to default values (on GPU reset, suspend/resume [2]_, etc..). - * - Display workarounds. The list is applied during display clock-gating - * initialization. - * - Workarounds that whitelist a privileged register, so that UMDs can manage - * them directly. This is just a special case of a MMMIO workaround (as we - * write the list of these to/be-whitelisted registers to some special HW - * registers). - * - Workaround batchbuffers, that get executed automatically by the hardware - * on every HW context restore. + * - Context workarounds: workarounds that touch registers that are + * saved/restored to/from the HW context image. The list is emitted (via Load + * Register Immediate commands) once when initializing the device and saved in + * the default context. That default context is then used on every context + * creation to have a "primed golden context", i.e. a context image that + * already contains the changes needed to all the registers. * - * .. [1] Please notice that there are other WAs that, due to their nature, - *cannot be applied from a central place. Those are peppered around the rest - *of the code, as needed. + * - Engine workarounds: the list of these WAs is applied whenever the specific + * engine is reset. It's also possible that a set of engine classes share a + * common power domain and they are reset together. This happens on some + * platforms with render and compute engines. In this case (at least) one of + * them need to keeep the workaround programming: the approach taken in the + * driver is to tie those workarounds to the first compute/render engine that + * is registered. When executing with GuC submission, engine resets are + * outside of kernel driver control, hence the list of registers involved in + * written once, on engine initialization, and then passed to GuC, that + * saves/restores their values before/after the reset takes place. See + * ``drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c`` for reference. * - * .. [2] Technically, some registers are powercontext saved & restored, so they - *survive a suspend/resume. In practice, writing them again is not too - *costly and simplifies things. We can revisit this in the future. + * - GT workarounds: the list of these WAs is applied whenever these registers + * revert to their default values: on GPU reset, suspend/resume [1]_, etc. + * + * - Register whitelist: some workarounds need to be implemented in userspace, + * but need to touch privileged registers. The whitelist in the kernel + * instructs the hardware to allow the access to happen. From the kernel side, + * this is just a special case of a MMIO workaround (as we write the list of + * these to/be-whitelisted registers to some special HW registers). + * + * - Workaround batchbuffers: buffers that get executed automatically by the + * hardware on every HW context restore. These buffers are created and + * programmed in the default context so the hardware always go through those + * programming sequences when switching contexts. The support for workaround + * batchbuffers is enabled these hardware mechanisms: * - * Layout - * ~~ + * #. INDIRECT_CTX: A batchbuffer and an offset are provided in the
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/1] drm/i915: Export LMEM max memory bandwidth via sysfs.
== Series Details == Series: series starting with [1/1] drm/i915: Export LMEM max memory bandwidth via sysfs. URL : https://patchwork.freedesktop.org/series/110902/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110902v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110902v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110902v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110902v1_full: ### IGT changes ### Possible regressions * igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscaling@pipe-a-valid-mode: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb8/igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscal...@pipe-a-valid-mode.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/shard-tglb8/igt@kms_flip_scaled_crc@flip-64bpp-linear-to-16bpp-linear-downscal...@pipe-a-valid-mode.html Known issues Here are the changes found in Patchwork_110902v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][3], [PASS][4], [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], [FAIL][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]) ([i915#4392]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/shard-glk9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/shard-glk9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/shard-glk9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/shard-glk9/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/shard-glk8/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/shard-glk8/boot.html [34]: https://intel-gfx-ci.01.org
Re: [Intel-gfx] [PATCH] drm/i915: Update workaround documentation
On Mon, Nov 14, 2022 at 01:04:30PM -0800, Matt Roper wrote: On Mon, Nov 07, 2022 at 04:30:28PM -0800, Lucas De Marchi wrote: There were several updates in the driver on how the workarounds are handled since its documentation was written. Update the documentation to reflect the current reality. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 87 + 1 file changed, 56 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index 3cdf5c24dbc5..0db3713c1beb 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -17,43 +17,68 @@ /** * DOC: Hardware workarounds * - * This file is intended as a central place to implement most [1]_ of the - * required workarounds for hardware to work as originally intended. They fall - * in five basic categories depending on how/when they are applied: + * This is intended as a central place to implement most [1]_ of the Your footnotes don't hook up properly anymore. The original code had [1] and [2], but the new code hooks [1] to what used to be [2]. rewording this for next version Since we moved this file under gt/ a while back, I wonder if we should note somehow that sgunit/soc workarounds and display workarounds aren't expected to be part of this file? I'm trying to make this agnostic to "this file" since it doesn't look correct when reading the html documentation. Next version I'm rewording some of this to just reference "central place". + * required workarounds for hardware to work as originally intended. Hardware + * workarounds are register programming documented to be executed in the driver + * that fall outside of the normal programming sequences for a platform. There + * are some basic categories of workarounds, depending on how/when they are + * applied: * - * - Workarounds that touch registers that are saved/restored to/from the HW - * context image. The list is emitted (via Load Register Immediate commands) - * everytime a new context is created. - * - GT workarounds. The list of these WAs is applied whenever these registers - * revert to default values (on GPU reset, suspend/resume [2]_, etc..). - * - Display workarounds. The list is applied during display clock-gating - * initialization. - * - Workarounds that whitelist a privileged register, so that UMDs can manage - * them directly. This is just a special case of a MMMIO workaround (as we - * write the list of these to/be-whitelisted registers to some special HW - * registers). - * - Workaround batchbuffers, that get executed automatically by the hardware - * on every HW context restore. + * - Context workarounds: workarounds that touch registers that are + * saved/restored to/from the HW context image. The list is emitted (via Load + * Register Immediate commands) once when initializing the device and saved in + * the default context. That default context is then used on every context + * creation to have a "primed golden context", i.e. a context image that + * already contains the changes needed to all the registers. * - * .. [1] Please notice that there are other WAs that, due to their nature, - *cannot be applied from a central place. Those are peppered around the rest - *of the code, as needed. + * - Engine workarounds: the list of these WAs is applied whenever the specific + * engine is reset. It's also possible that a set of engine classes share a + * common power domain and they are reset together. This happens on some + * platforms with render and compute engines. In this case (at least) one of + * them need to keeep the workaround programming: the approach taken in the + * driver is to tie those workarounds to the first compute/render engine that + * is registered. When executing with GuC submission, engine resets are + * outside of kernel driver control, hence the list of registers involved in + * written once, on engine initialization, and then passed to GuC, that + * saves/restores their values before/after the reset takes place. See + * ``drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c`` for reference. * - * .. [2] Technically, some registers are powercontext saved & restored, so they - *survive a suspend/resume. In practice, writing them again is not too - *costly and simplifies things. We can revisit this in the future. + * - GT workarounds: the list of these WAs is applied whenever these registers + * revert to their default values: on GPU reset, suspend/resume, etc. This is where the new [1] used to be referenced from. * - * Layout - * ~~ + * - Register whitelist: some workarounds need to be implemented in userspace, + * but need to touch privileged registers. The whitelist in the kernel + * instructs the hardware to allow the access to happen. From the kernel side, + * this is just a special case of a M
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: call i915_request_await_object from _i915_vma_move_to_active
On 08.11.2022 11:24, Matthew Auld wrote: On 19/10/2022 22:59, Andrzej Hajda wrote: Since almost all calls to i915_vma_move_to_active are prepended with i915_request_await_object, let's call the latter from _i915_vma_move_to_active by default and add flag allowing bypassing it. Adjust all callers accordingly. The patch should not introduce functional changes. Signed-off-by: Andrzej Hajda I thought someone already reviewed this series. Anyway, Reviewed-by: Matthew Auld Gently ping for merge. Regards Andrzej
Re: [Intel-gfx] [PATCH 2/3] Documentation/gpu: Limit index to maxdepth=2
On Tue, Nov 15, 2022 at 03:18:01PM +0530, Balasubramani Vivekanandan wrote: On 07.11.2022 09:32, Lucas De Marchi wrote: With a lot of sub-section it's a little bit hard to find the information needed in the main GPU index. Limit the maxdepth to 2 so it doesn't get poluted with noise from each driver and from other sections. Signed-off-by: Lucas De Marchi --- Documentation/gpu/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index b99dede9a5b1..1d9402d519be 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -3,6 +3,7 @@ Linux GPU Driver Developer's Guide == .. toctree:: + :maxdepth: 2 I have a bit different opinion here. I find it helpful to search for a topic if the headers remain uncollapsed. A top level view is anyways available in the TOC shown in the left side of the page which shows only the immediate next level headers. I think the left side doesn't render very well. I'd still like to have depth 2 for an overview, without going too deep in the innerworks of each and every driver. Looking around I found there is a lot of use of maxdepth in the indexes (git grep ":maxdepth:" -- Documentation), so thought it would be something to adopt here. Anyway, I don't mind dropping these 2 patches if people don't agree with me :) thanks Lucas De Marchi
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Monday, November 14, 2022 4:43 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
>
> Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash when
> changing cdclk
>
> On Mon, Nov 14, 2022 at 04:07:13PM -0800, Srivatsa, Anusha wrote:
> >
> >
> > > -Original Message-
> > > From: Roper, Matthew D
> > > Sent: Monday, November 14, 2022 4:01 PM
> > > To: Srivatsa, Anusha
> > > Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
> > >
> > > Subject: Re: [PATCH 2/3] drm/i915/display: Do both crawl and squash
> > > when changing cdclk
> > >
> > > On Mon, Nov 14, 2022 at 03:14:33PM -0800, Srivatsa, Anusha wrote:
> > > ...
> > > > > > +static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > > > > > + const struct intel_cdclk_config *cdclk_config,
> > > > > > + enum pipe pipe)
> > > > > > +{
> > > > > > + struct intel_cdclk_config mid_cdclk_config;
> > > > > > + int cdclk = cdclk_config->cdclk;
> > > > > > + int ret;
> > > > >
> > > > > You should initialize ret to 0 here since you don't set it in
> > > > > the new branch of the if/else ladder below.
> > > > >
> > > > > > +
> > > > > > + /* Inform power controller of upcoming frequency change.
> */
> > > > > > + if (DISPLAY_VER(dev_priv) >= 14) {
> > > > > > + /* DISPLAY14+ do not follow the PUnit mailbox
> > > > > communication,
> > > > >
> > > > > "Display versions 14 and above" or "Xe_LPD+ and beyond"
> > > > >
> > > > > Also, this is another case where "/*" should be on its own line.
> > > > >
> > > > > > +* skip this step.
> > > > > > +*/
> > > > > > + } else if (DISPLAY_VER(dev_priv) >= 11) {
> > > > > > + ret = skl_pcode_request(&dev_priv->uncore,
> > > > > SKL_PCODE_CDCLK_CONTROL,
> > > > > > +
> SKL_CDCLK_PREPARE_FOR_CHANGE,
> > > > > > +
> SKL_CDCLK_READY_FOR_CHANGE,
> > > > > > +
> SKL_CDCLK_READY_FOR_CHANGE, 3);
> > > > > > } else {
> > > > > > /*
> > > > > > -* The timeout isn't specified, the 2ms used here is
> based on
> > > > > > -* experiment.
> > > > > > -* FIXME: Waiting for the request completion could
> be
> > > > > delayed
> > > > > > -* until the next PCODE request based on BSpec.
> > > > > > +* BSpec requires us to wait up to 150usec, but that
> leads to
> > > > > > +* timeouts; the 2ms used here is based on
> experiment.
> > > > > > */
> > > > > > ret = snb_pcode_write_timeout(&dev_priv->uncore,
> > > > > >
> > > > > HSW_PCODE_DE_WRITE_FREQ_REQ,
> > > > > > - cdclk_config-
> >voltage_level,
> > > > > > - 150, 2);
> > > > > > + 0x8000, 150, 2);
> > > > >
> > > > > The switch from cdclk_config->voltage_level to a magic number
> > > > > (0x8000) on old platforms doesn't seem to be related to the
> > > > > rest of this patch. Ditto for the comment update about 150usec
> > > > > not being
> > > enough.
> > > > > Were those intended for a different patch?
> > > > Well, initially both squash and crawl support for MTl was the
> > > > intention. The change came to be a part of this patch because MTL
> > > > doesn't go through the Punit mailbox communication like previous
> > > > platforms and hence the churn. Thinking out loud if changing the
> > > > commit message makes more sense or a separate patch. A separate
> > > > patch would just remove make sure MTL does not touch the bits of
> > > > code Punit code. And the next patch would be the actual
> > > > squash_crawl-mid_cdclk_config patch.
> > >
> > > Okay, it looks like part of my confusion is just that the code
> > > movement made the diff deltas somewhat non-intuitive; due to code
> > > ordering changes, it's actually giving a diff of two completely
> > > different code blocks that just happen to look similar; you're not
> > > actually
> changing the value here.
> > >
> > > However I still think there might be a problem here. For pre-MTL
> > > platforms there are supposed to be two pcode transactions, one
> > > before the frequency change and one after. Before your patch, the
> 'before'
> > > transaction used a hardcoded 0x8000 and the 'after' transaction
> > > used cdclk_config->voltage_level [1]. Your patch keeps the 'before'
> > > step at the beginning of bxt_set_cdclk, but it seems to drop the
> > > 'after' step as far as I can see. I don't believe that was intentional
> > > was it?
> >
> > That was not the intention here. I think the Pcode thing needs to be a
> > separate patch? Might make reviewing easy.
>
> The pcode handling in the current code is what we consider correct-ish
> (although as noted in [1] below, not 100% correct). So I'm not sure what you
> mean by a separate patch for the pcode thing.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ttm: never purge busy objects (rev2)
== Series Details ==
Series: drm/i915/ttm: never purge busy objects (rev2)
URL : https://patchwork.freedesktop.org/series/110601/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110601v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/index.html
Participating hosts (40 -> 38)
--
Missing(2): bat-rpls-1 bat-dg2-11
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110601v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_mocs:
- {bat-adln-1}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-adln-1/igt@i915_selftest@live@gt_mocs.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/bat-adln-1/igt@i915_selftest@live@gt_mocs.html
Known issues
Here are the changes found in Patchwork_110601v2 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][3] ([i915#7029]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: [DMESG-WARN][5] ([i915#6434]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/bat-rpls-2/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#7029]: https://gitlab.freedesktop.org/drm/intel/issues/7029
Build changes
-
* Linux: CI_DRM_12382 -> Patchwork_110601v2
CI-20190529: 20190529
CI_DRM_12382: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7057: e2138d48c2c506816868c16cf3ba64f81bdead41 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_110601v2: cb74864693414b221b3601572e75449558126e8b @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
8fc1b9729634 drm/i915/ttm: never purge busy objects
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110601v2/index.html
Re: [Intel-gfx] [PATCH v5 3/9] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format
On 11/15/2022 4:30 PM, Ville Syrjälä wrote:
On Tue, Nov 15, 2022 at 12:23:53PM +0530, Nautiyal, Ankit K wrote:
On 11/11/2022 2:36 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:14:05PM +0530, Ankit Nautiyal wrote:
The decision to use DFP output format conversion capabilities should be
during compute_config phase.
This patch uses the members of intel_dp->dfp to only store the
format conversion capabilities of the DP device and uses the crtc_state
sink_format member, to program the protocol-converter for
colorspace/format conversion.
v2: Use sink_format to determine the color conversion config for the
pcon (Ville).
v3: Fix typo: missing 'break' in switch case (lkp kernel test robot).
v4: Add helper to check if DP supports YCBCR420.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 122
1 file changed, 84 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0e4f7b467970..95d0c653db7f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -790,6 +790,7 @@ intel_dp_output_format(struct intel_connector *connector,
enum intel_output_format sink_format)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
if (!connector->base.ycbcr_420_allowed ||
sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
@@ -799,6 +800,10 @@ intel_dp_output_format(struct intel_connector *connector,
intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_RGB;
+ /* Prefer 4:2:0 passthrough over 4:4:4->4:2:0 conversion */
+ if (DISPLAY_VER(i915) >= 11 && intel_dp->dfp.ycbcr420_passthrough)
+ return INTEL_OUTPUT_FORMAT_YCBCR420;
+
if (intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_YCBCR444;
else
The else branch here is also 420, so the whole logic
here doesn't seem to flow entirely sensibly.
Thinking a bit more abstractly, could we restate
this whole problem as something more like this?
if (source_can_output(sink_format))
return sink_format;
if (source_can_output(RGB) &&
dfp_can_convert_from_rgb(sink_format))
return RGB;
if (source_can_output(YCBCR444) &&
dfp_can_convert_from_ycbcr444(sink_format))
return YCBCR444;
This make sense and will also help to add 422 support easier.
I am only seeing one problem: about how to have DSC considerations
during source_can_output( ).
Gen 11+ should support YCBCR420. So for any ycbcr420_only mode we should
have sink_format, and output_format : YCbCr420.
This works well for cases where DSC doesn't get in picture. When higher
modes like 8k60 ycbcr420_only are involved, we need to use DSC.
Currently, our DSC1.1 does not support YCbCr420. The problem is that we
go for, dsc_compute_config at a later time.
This issue might have been masked, due to the messy order of checks in
intel_dp_output_format.
Specifically With HDMI2.1 PCONs supporting color conv, for such a case
we can have output_format as RGB, and sink_format as YCbCr420.
The DSC compression with RGB and then configure PCON to Decompress,
conv. to YCbCr420.
So can we put a check in source_can_output for Gen11+ where DSC might be
required, so that with source_can_output(YCBCR420) returns false in such
case, where DSC is the only way?
I'm thinking it should work well enough without any extra checks
since we'll always try RGB before YCbC4 4:2:0. I guess the only
case where it could fail is if the sink only supports 4:2:0 for
that particular mode. Then we'd also try direct YCbC4 4:2:0 output
on icl+. Dunno if such sinks are still a thing when DSC is in the
picture.
There indeed are some HDMI 8k Panels that have 8k@60 in Ycbcr420 only mode.
These do not have DSC, so without DSC these can support 8k@60 only in
YCbCr420.
(We have a SONY XBR-Z8H in lab, and there are some in market from
Samsung too, which support 8k@60 in YCbcr420 only).
With PCON we can support these. As mentioned above, we need to send
compressed stream in RGB to PCON.
PCON decompresses, converts RGB444 to Ycbcr420. The sink is sent 8k@60
Ycbcr420 uncompressed.
Hmm. Do PCONs even support DSC + color conversion/etc. at the
same time? They'd have to decompress and potentially recompress
the data in that case.
Yes there are PCONs that support 3 modes of operations along with color
conversion.
DSC1.2 pass-through: A DSC1.2 compressed just gets forwarded to DSC1.2
supporting HDMI2.1sink.
DSC1.1->DSC1.2 : DSC1.1 compressed stream is decompressed and then
re-compressed again with DSC1.2 and forward to DSC1.2 supporting HDMI2.1
sink.
DSC1.x->uncompress: DSC1.x is decompressed and sent to HDMI sink that
does not support DSC.
(the case mentioned above, uses this 3rd option)
The problem with adding DSC chec
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On Tue, Nov 15, 2022 at 04:20:54PM +, Matthew Auld wrote:
On 15/11/2022 16:15, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 11:05:21AM +, Matthew Auld wrote:
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was that changed
somewhere?
No, it applies to any vma (partial or non-partial).
It was so from the beginning.
Doesn't __i915_vma_unbind_async() return an error when mm.pages !=
vma->pages? IIRC this was discussed before. Just trying to think about
the consequences of this change.
I am not seeing any such restriction. Let me probe and check if there
is any such restriction anywhere in the call chain.
Niranjana
Niranjana
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct
i915_address_space *vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1727,7 +1729,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1787,7 +1803,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(&vma->vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1798,7 +1814,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(&vma->vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(&vma->vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(&vma->vm->mutex);
+ /*
+ * Ensure any asynchronous binding is complete while using
+ * async unbind as we will be releasing the vma here.
+ */
+ if (async && i915_active_wait(&vma->active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h
b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/ttm: never purge busy objects (rev2)
== Series Details == Series: drm/i915/ttm: never purge busy objects (rev2) URL : https://patchwork.freedesktop.org/series/110601/ State : warning == Summary == Error: dim checkpatch failed b44746463714 drm/i915/ttm: never purge busy objects -:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #25: [ +0.005879] Code: 89 fb 48 85 f6 74 11 8b 55 4c 48 8b 7d 30 45 31 c0 31 c9 e8 18 6a e5 e0 80 7d 60 00 74 20 48 8b 45 68 total: 0 errors, 1 warnings, 0 checks, 10 lines checked
Re: [Intel-gfx] [PATCH] drm/i915: Fix vma allocator debug
On 15/11/2022 10:46, Andrzej Hajda wrote:
On 15.11.2022 11:17, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a missing colon which I accidentally removed in the recent logging
changes.
Signed-off-by: Tvrtko Ursulin
Fixes: a10234fda466 ("drm/i915: Partial abandonment of legacy DRM
logging macros")
Cc: Andrzej Hajda
Reviewed-by: Andrzej Hajda
Thanks, pushed!
Regards,
Tvrtko
Regards
Andrzej
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 3b969d679c1e..947fde68e5f5 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -73,7 +73,7 @@ static void vma_print_allocator(struct i915_vma
*vma, const char *reason)
char buf[512];
if (!vma->node.stack) {
- drm_dbg(&to_i915(vma->obj->base.dev)->drm
+ drm_dbg(&to_i915(vma->obj->base.dev)->drm,
"vma.node [%08llx + %08llx] %s: unknown owner\n",
vma->node.start, vma->node.size, reason);
return;
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On 15/11/2022 16:15, Niranjana Vishwanathapura wrote:
On Tue, Nov 15, 2022 at 11:05:21AM +, Matthew Auld wrote:
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was that changed
somewhere?
No, it applies to any vma (partial or non-partial).
It was so from the beginning.
Doesn't __i915_vma_unbind_async() return an error when mm.pages !=
vma->pages? IIRC this was discussed before. Just trying to think about
the consequences of this change.
Niranjana
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct
i915_address_space *vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c
b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1727,7 +1729,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1787,7 +1803,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(&vma->vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1798,7 +1814,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(&vma->vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(&vma->vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(&vma->vm->mutex);
+ /*
+ * Ensure any asynchronous binding is complete while using
+ * async unbind as we will be releasing the vma here.
+ */
+ if (async && i915_active_wait(&vma->active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h
b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
#define assert_vma_held(vma)
dma_resv_assert_held((vma)->obj->base.resv)
diff --git a/includ
Re: [Intel-gfx] [PATCH v2] drm/i915/ttm: never purge busy objects
On 15.11.2022 11:46, Matthew Auld wrote:
In i915_gem_madvise_ioctl() we immediately purge the object is not
currently used, like when the mm.pages are NULL. With shmem the pages
might still be hanging around or are perhaps swapped out. Similarly with
ttm we might still have the pages hanging around on the ttm resource,
like with lmem or shmem, but here we need to be extra careful since
async unbinds are possible as well as in-progress kernel moves. In
i915_ttm_purge() we expect the pipeline-gutting to nuke the ttm resource
for us, however if it's busy the memory is only moved to a ghost object,
which then leads to broken behaviour when for example clearing the
i915_tt->filp, since the actual ttm_tt is still alive and populated,
even though it's been moved to the ghost object. When we later destroy
the ghost object we hit the following, since the filp is now NULL:
[ +0.006982] #PF: supervisor read access in kernel mode
[ +0.005149] #PF: error_code(0x) - not-present page
[ +0.005147] PGD 11631d067 P4D 11631d067 PUD 115972067 PMD 0
[ +0.005676] Oops: [#1] PREEMPT SMP NOPTI
[ +0.012962] Workqueue: events ttm_device_delayed_workqueue [ttm]
[ +0.006022] RIP: 0010:i915_ttm_tt_unpopulate+0x3a/0x70 [i915]
[ +0.005879] Code: 89 fb 48 85 f6 74 11 8b 55 4c 48 8b 7d 30 45 31 c0 31 c9 e8
18 6a e5 e0 80 7d 60 00 74 20 48 8b 45 68
8b 55 08 4c 89 e7 5b 5d <48> 8b 40 20 83 e2 01 41 5c 89 d1 48 8b 70
30 e9 42 b2 ff ff 4c 89
[ +0.018782] RSP: :c9000bf6fd70 EFLAGS: 00010202
[ +0.005244] RAX: RBX: 8883e12ae380 RCX:
[ +0.007150] RDX: 800e RSI: 823559b4 RDI: 8883e12ae3c0
[ +0.007142] RBP: 888103b65d48 R08: 0001 R09: 0001
[ +0.007144] R10: 0001 R11: 88829c2c8040 R12: 8883e12ae3c0
[ +0.007148] R13: 0001 R14: 888115184140 R15: 888115184248
[ +0.007154] FS: () GS:88844db0()
knlGS:
[ +0.008108] CS: 0010 DS: ES: CR0: 80050033
[ +0.005763] CR2: 0020 CR3: 00013fdb4004 CR4: 003706e0
[ +0.007152] DR0: DR1: DR2:
[ +0.007145] DR3: DR6: fffe0ff0 DR7: 0400
[ +0.007154] Call Trace:
[ +0.002459]
[ +0.002126] ttm_tt_unpopulate.part.0+0x17/0x70 [ttm]
[ +0.005068] ttm_bo_tt_destroy+0x1c/0x50 [ttm]
[ +0.004464] ttm_bo_cleanup_memtype_use+0x25/0x40 [ttm]
[ +0.005244] ttm_bo_cleanup_refs+0x90/0x2c0 [ttm]
[ +0.004721] ttm_bo_delayed_delete+0x235/0x250 [ttm]
[ +0.004981] ttm_device_delayed_workqueue+0x13/0x40 [ttm]
[ +0.005422] process_one_work+0x248/0x560
[ +0.004028] worker_thread+0x4b/0x390
[ +0.003682] ? process_one_work+0x560/0x560
[ +0.004199] kthread+0xeb/0x120
[ +0.003163] ? kthread_complete_and_exit+0x20/0x20
[ +0.004815] ret_from_fork+0x1f/0x30
v2:
- Just use ttm_bo_wait() directly (Niranjana)
- Add testcase reference
Testcase: igt@gem_madvise@dontneed-evict-race
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Reported-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
Cc: # v5.15+
Reviewed-by: Niranjana Vishwanathapura
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e4e55e3f4e41..34793863ea45 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -603,6 +603,10 @@ static int i915_ttm_truncate(struct drm_i915_gem_object
*obj)
WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
+ err = ttm_bo_wait(bo, true, false);
+ if (err)
+ return err;
+
err = i915_ttm_move_notify(bo);
if (err)
return err;
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On Tue, Nov 15, 2022 at 04:58:42PM +0100, Andi Shyti wrote:
Hi Niranjana,
On Sat, Nov 12, 2022 at 11:57:32PM -0800, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct i915_address_space
*vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
I still like the defines on this, they look cleaner, but it's a
matter of taste.
Ok, will change.
Niranjana
Reviewed-by: Andi Shyti
Andi
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On Tue, Nov 15, 2022 at 11:05:21AM +, Matthew Auld wrote:
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was that changed somewhere?
No, it applies to any vma (partial or non-partial).
It was so from the beginning.
Niranjana
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct i915_address_space
*vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1727,7 +1729,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1787,7 +1803,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(&vma->vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1798,7 +1814,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(&vma->vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(&vma->vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(&vma->vm->mutex);
+ /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+ if (async && i915_active_wait(&vma->active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
#define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
diff -
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
Hi Niranjana,
On Sat, Nov 12, 2022 at 11:57:32PM -0800, Niranjana Vishwanathapura wrote:
> Asynchronously unbind the vma upon vm_unbind call.
> Fall back to synchronous unbind if backend doesn't support
> async unbind or if async unbind fails.
>
> No need for vm_unbind out fence support as i915 will internally
> handle all sequencing and user need not try to sequence any
> operation with the unbind completion.
>
> v2: use i915_vma_destroy_async in vm_unbind ioctl
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
> .../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
> drivers/gpu/drm/i915/i915_vma.c | 51 +--
> drivers/gpu/drm/i915/i915_vma.h | 1 +
> include/uapi/drm/i915_drm.h | 3 +-
> 4 files changed, 51 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> index d87d1210365b..36651b447966 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> @@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct
> i915_address_space *vm,
>*/
> obj = vma->obj;
> i915_gem_object_lock(obj, NULL);
> - i915_vma_destroy(vma);
> + i915_vma_destroy_async(vma);
> i915_gem_object_unlock(obj);
>
> i915_gem_object_put(obj);
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 7cf77c67d755..483d25f2425c 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -42,6 +42,8 @@
> #include "i915_vma.h"
> #include "i915_vma_resource.h"
>
> +static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
> +
> static inline void assert_vma_held_evict(const struct i915_vma *vma)
> {
> /*
> @@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
> spin_unlock_irq(>->closed_lock);
> }
>
> -static void force_unbind(struct i915_vma *vma)
> +static void force_unbind(struct i915_vma *vma, bool async)
I still like the defines on this, they look cleaner, but it's a
matter of taste.
Reviewed-by: Andi Shyti
Andi
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix vma allocator debug
== Series Details ==
Series: drm/i915: Fix vma allocator debug
URL : https://patchwork.freedesktop.org/series/110906/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110906v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/index.html
Participating hosts (40 -> 39)
--
Additional (2): fi-kbl-soraka fi-hsw-4770
Missing(3): bat-rpls-1 fi-rkl-11600 bat-dg2-11
Known issues
Here are the changes found in Patchwork_110906v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.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_110906v1/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
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][4] -> [INCOMPLETE][5] ([i915#7056])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271]) +9 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.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_110906v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@requests:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][9] ([i915#7352])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +7
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1072]) +3
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][13] ([i915#4312] / [i915#4991])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/fi-kbl-soraka/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][14] ([i915#2582]) -> [PASS][15] +4 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@fb...@read.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/bat-rpls-2/igt@fb...@read.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}: [DMESG-WARN][16] ([i915#6434]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][18] ([i915#7029]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-dg2-8/igt@gem_huc_c...@huc-copy.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110906v1/bat-dg2-8/igt@gem_huc_c...@huc-copy.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issue
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915: Export LMEM max memory bandwidth via sysfs.
== Series Details ==
Series: series starting with [1/1] drm/i915: Export LMEM max memory bandwidth
via sysfs.
URL : https://patchwork.freedesktop.org/series/110902/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12382 -> Patchwork_110902v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/index.html
Participating hosts (40 -> 39)
--
Missing(1): bat-dg2-11
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110902v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s3-without-i915:
- {bat-rpls-1}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-rpls-1/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_110902v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_blits@basic:
- fi-pnv-d510:[PASS][3] -> [SKIP][4] ([fdo#109271]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6] ([i915#6972] /
[i915#7120])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-ilk-650: [PASS][7] -> [DMESG-WARN][8] ([i915#164])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/fi-ilk-650/igt@i915_susp...@basic-s2idle-without-i915.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/fi-ilk-650/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_flip@basic-plain-flip:
- bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#4078])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-dg1-6/igt@kms_f...@basic-plain-flip.html
* igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/fi-bsw-nick/igt@run...@aborted.html
Possible fixes
* igt@fbdev@nullptr:
- {bat-rpls-1}: [SKIP][11] ([i915#2582]) -> [PASS][12] +4 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-1/igt@fb...@nullptr.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-rpls-1/igt@fb...@nullptr.html
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][13] ([i915#2582]) -> [PASS][14] +4 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@fb...@read.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-rpls-2/igt@fb...@read.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}: [DMESG-WARN][15] ([i915#6434]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@mman:
- {bat-rpls-1}: [TIMEOUT][17] ([i915#6794]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-1/igt@i915_selftest@l...@mman.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-rpls-1/igt@i915_selftest@l...@mman.html
* igt@i915_selftest@live@slpc:
- {bat-adln-1}: [DMESG-FAIL][19] ([i915#6997]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-adln-1/igt@i915_selftest@l...@slpc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-adln-1/igt@i915_selftest@l...@slpc.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-rpls-1}: [SKIP][21] ([i915#1849]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-1/igt@kms_frontbuffer_track...@basic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110902v1/bat-rpls-1/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- {bat-rpls-1}: [SKIP][23] ([fdo#109295] / [i915#1845] / [i915#3708])
-> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/bat-rpls-1/i
Re: [Intel-gfx] [PATCH v2 1/4] i915: Move list_count() to list.h for broader use
On Mon, 14 Nov 2022, Andy Shevchenko wrote:
> Some of the existing users, and definitely will be new ones, want to
> count existing nodes in the list. Provide a generic API for that by
> moving code from i915 to list.h.
I think I'd find list_length() a much more natural name for this.
*shrug*
Acked-by: Jani Nikula
regardless of what you decide to do with name or static inline etc.
>
> Signed-off-by: Andy Shevchenko
> ---
> v2: dropped the duplicate code in i915 (LKP)
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 13 +
> include/linux/list.h | 13 +
> 2 files changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 6ae8b07cfaa1..b5d474be564d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -2085,17 +2085,6 @@ static void print_request_ring(struct drm_printer *m,
> struct i915_request *rq)
> }
> }
>
> -static unsigned long list_count(struct list_head *list)
> -{
> - struct list_head *pos;
> - unsigned long count = 0;
> -
> - list_for_each(pos, list)
> - count++;
> -
> - return count;
> -}
> -
> static unsigned long read_ul(void *p, size_t x)
> {
> return *(unsigned long *)(p + x);
> @@ -2270,7 +2259,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
> spin_lock_irqsave(&engine->sched_engine->lock, flags);
> engine_dump_active_requests(engine, m);
>
> - drm_printf(m, "\tOn hold?: %lu\n",
> + drm_printf(m, "\tOn hold?: %zu\n",
> list_count(&engine->sched_engine->hold));
> spin_unlock_irqrestore(&engine->sched_engine->lock, flags);
>
> diff --git a/include/linux/list.h b/include/linux/list.h
> index 61762054b4be..098eccf8c1b6 100644
> --- a/include/linux/list.h
> +++ b/include/linux/list.h
> @@ -655,6 +655,19 @@ static inline void list_splice_tail_init(struct
> list_head *list,
>!list_is_head(pos, (head)); \
>pos = n, n = pos->prev)
>
> +/**
> + * list_count - count nodes in the list
> + * @head:the head for your list.
> + */
> +#define list_count(head) \
> +({ \
> + struct list_head *__tmp;\
> + size_t __i = 0; \
> + list_for_each(__tmp, head) \
> + __i++; \
> + __i;\
> +})
> +
> /**
> * list_entry_is_head - test if the entry points to the head of the list
> * @pos: the type * to cursor
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PULL] gvt-next
On Fri, Nov 11, 2022 at 04:59:03PM +0800, Zhenyu Wang wrote:
> Hi,
>
> Here's current accumulated changes in gvt-next. Sorry that I delayed
> to refresh them on time for upstream...It contains mostly kernel doc,
> typo fixes and small code cleanups, as details below.
>
> btw, one gvt change for next https://patchwork.freedesktop.org/patch/58/
> is still pending, I need a backmerge from linus tree e.g with recent vfio/mdev
> consolidate change with gvt and Jason's fix for destroy device, to apply Zhi's
> change cleanly. Pls help on that.
>
> Thanks!
> ---
> The following changes since commit a6ebd538364b1e9e6048faaafbc0188172ed50c3:
>
> drm/i915/sdvo: Fix debug print (2022-10-28 14:46:21 +0300)
>
> are available in the Git repository at:
>
> https://github.com/intel/gvt-linux.git tags/gvt-next-2022-11-11
>
> for you to fetch changes up to 50468ca2e2e1ce882f060a8c263f678affe112db:
>
> drm/i915/gvt: Remove the unused function get_pt_type() (2022-11-08 15:34:06
> +0800)
>
>
> gvt-next-2022-11-11
>
> - kernel doc fixes
> - remove vgpu->released sanity check
> - small clean up
>
>
> Colin Ian King (1):
> drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
dim: d7e4e9579f01 ("drm/i915/reg: Fix spelling mistake "Unsupport" ->
"Unsupported""): committer Signed-off-by missing.
could you please fix this before we can merge this pr?
>
> Jiapeng Chong (4):
> drm/i915/gvt: Fix kernel-doc
> drm/i915/gvt: Fix kernel-doc
> drm/i915/gvt: Fix kernel-doc
> drm/i915/gvt: Remove the unused function get_pt_type()
>
> Julia Lawall (1):
> drm/i915/gvt: fix typo in comment
>
> Mauro Carvalho Chehab (1):
> drm/i915: gvt: fix kernel-doc trivial warnings
>
> Paulo Miguel Almeida (1):
> i915/gvt: remove hardcoded value on crc32_start calculation
>
> Zhi Wang (1):
> drm/i915/gvt: remove the vgpu->released and its sanity check
>
> wangjianli (1):
> drm/i915: fix repeated words in comments
>
> drivers/gpu/drm/i915/gvt/aperture_gm.c | 4 ++--
> drivers/gpu/drm/i915/gvt/cfg_space.c| 2 +-
> drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
> drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
> drivers/gpu/drm/i915/gvt/gtt.c | 9 ++---
> drivers/gpu/drm/i915/gvt/gvt.h | 2 --
> drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
> drivers/gpu/drm/i915/gvt/kvmgt.c| 4
> drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
> drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
> drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
> 11 files changed, 14 insertions(+), 25 deletions(-)
Re: [Intel-gfx] [PATCH v2] drm/i915: remove circ_buf.h includes
On Tue, 15 Nov 2022, "Jiri Slaby (SUSE)" wrote:
> The last user of macros from that include was removed in 2018 by the
> commit below.
>
> Fixes: 6cc42152b02b ("drm/i915: Remove support for legacy debugfs crc
> interface")
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Jiri Slaby (SUSE)
Pushed to drm-intel-next, thanks for the patch!
BR,
Jani.
> ---
>
> Notes:
> [v2] fixed e-mail setup
>
> drivers/gpu/drm/i915/display/intel_pipe_crc.c | 1 -
> drivers/gpu/drm/i915/i915_irq.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> index 673454fbf784..e9774670e3f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/display/intel_pipe_crc.c
> @@ -24,7 +24,6 @@
> *
> */
>
> -#include
> #include
> #include
> #include
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b0180ea38de0..a815a45a6e6b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -28,7 +28,6 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> -#include
> #include
> #include
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: Enable Idle Messaging for GSC CS
On Tue, Nov 15, 2022 at 07:14:40PM +0530, Badal Nilawar wrote:
> From: Vinay Belgaumkar
>
> By defaut idle mesaging is disabled for GSC CS so to unblock RC6
> entry on media tile idle messaging need to be enabled.
>
> v2:
> - Fix review comments (Vinay)
> - Set GSC idle hysterisis to 5 us (Badal)
btw, no need for the cover letter in single/standalone patches.
This history here is enough.
>
> Bspec: 71496
>
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Vinay Belgaumkar
> Signed-off-by: Badal Nilawar
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18 ++
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index b0a4a2dbe3ee..5522885b2db0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -15,6 +15,22 @@
> #include "intel_rc6.h"
> #include "intel_ring.h"
> #include "shmem_utils.h"
> +#include "intel_gt_regs.h"
> +
> +static void intel_gsc_idle_msg_enable(struct intel_engine_cs *engine)
> +{
> + struct drm_i915_private *i915 = engine->i915;
> +
> + if (IS_METEORLAKE(i915) && engine->id == GSC0) {
> + intel_uncore_write(engine->gt->uncore,
> +RC_PSMI_CTRL_GSCCS,
> +_MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
> + /* 5 us hysterisis */
typo
> + intel_uncore_write(engine->gt->uncore,
> +PWRCTX_MAXCNT_GSCCS,
> +0xA);
you said 5 above, but used 10 here, why?
> + }
> +}
>
> static void dbg_poison_ce(struct intel_context *ce)
> {
> @@ -275,6 +291,8 @@ void intel_engine_init__pm(struct intel_engine_cs *engine)
>
> intel_wakeref_init(&engine->wakeref, rpm, &wf_ops);
> intel_engine_init_heartbeat(engine);
> +
> + intel_gsc_idle_msg_enable(engine);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 07031e03f80c..20472eb15364 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -913,6 +913,10 @@
> #define MSG_IDLE_FW_MASKREG_GENMASK(13, 9)
> #define MSG_IDLE_FW_SHIFT 9
>
> +#define RC_PSMI_CTRL_GSCCS _MMIO(0x11a050)
> +#defineIDLE_MSG_DISABLE BIT(0)
REG_BIT should be preferred.
> +#define PWRCTX_MAXCNT_GSCCS _MMIO(0x11a054)
> +
> #define FORCEWAKE_MEDIA_GEN9 _MMIO(0xa270)
> #define FORCEWAKE_RENDER_GEN9_MMIO(0xa278)
>
> --
> 2.25.1
>
[Intel-gfx] [PATCH v3] drm/i915/mtl: Media GT and Render GT share common GGTT
On XE_LPM+ platforms the media engines are carved out into a separate
GT but have a common GGTMMADR address range which essentially makes
the GGTT address space to be shared between media and render GT. As a
result any updates in GGTT shall invalidate TLB of GTs sharing it and
similarly any operation on GGTT requiring an action on a GT will have to
involve all GTs sharing it. setup_private_pat was being done on a per
GGTT based as that doesn't touch any GGTT structures moved it to per GT
based.
BSPEC: 63834
v2:
1. Add details to commit msg
2. includes fix for failure to add item to ggtt->gt_list, as suggested
by Lucas
3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
it.
4. setup_private_pat moved out of intel_gt_tiles_init
v3:
1. Move out for_each_gt from i915_driver.c (Jani Nikula)
Cc: Matt Roper
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 54 +--
drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 ++
drivers/gpu/drm/i915/gt/intel_gtt.h | 4 ++
drivers/gpu/drm/i915/i915_driver.c| 12 ++---
drivers/gpu/drm/i915/i915_gem.c | 2 +
drivers/gpu/drm/i915/i915_gem_evict.c | 51 +++--
drivers/gpu/drm/i915/i915_vma.c | 5 ++-
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +
9 files changed, 111 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 8145851ad23d..7644738b9cdb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -8,6 +8,7 @@
#include
#include
+#include
#include
#include
@@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
void i915_ggtt_suspend(struct i915_ggtt *ggtt)
{
+ struct intel_gt *gt;
+
i915_ggtt_suspend_vm(&ggtt->vm);
ggtt->invalidate(ggtt);
- intel_gt_check_and_clear_faults(ggtt->vm.gt);
+ list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+ intel_gt_check_and_clear_faults(gt);
}
void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
{
- struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct drm_i915_private *i915 = ggtt->vm.i915;
gen8_ggtt_invalidate(ggtt);
- if (GRAPHICS_VER(i915) >= 12)
- intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
- GEN12_GUC_TLB_INV_CR_INVALIDATE);
- else
- intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+ if (GRAPHICS_VER(i915) >= 12) {
+ struct intel_gt *gt;
+
+ list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+ 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);
+ }
}
u64 gen8_ggtt_pte_encode(dma_addr_t addr,
@@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
- setup_private_pat(ggtt->vm.gt);
-
return ggtt_probe_common(ggtt, size);
}
@@ -1196,7 +1203,14 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct
intel_gt *gt)
*/
int i915_ggtt_probe_hw(struct drm_i915_private *i915)
{
- int ret;
+ struct intel_gt *gt;
+ int ret, i;
+
+ for_each_gt(gt, i915, i) {
+ ret = intel_gt_assign_ggtt(gt);
+ if (ret)
+ return ret;
+ }
ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
if (ret)
@@ -1208,6 +1222,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
return 0;
}
+struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
+{
+ struct i915_ggtt *ggtt;
+
+ ggtt = drmm_kzalloc(&i915->drm, sizeof(*ggtt), GFP_KERNEL);
+ if (!ggtt)
+ return ERR_PTR(-ENOMEM);
+
+ INIT_LIST_HEAD(&ggtt->gt_list);
+
+ return ggtt;
+}
+
int i915_ggtt_enable_hw(struct drm_i915_private *i915)
{
if (GRAPHICS_VER(i915) < 6)
@@ -1296,9 +1323,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
void i915_ggtt_resume(struct i915_ggtt *ggtt)
{
+ struct intel_gt *gt;
bool flush;
- intel_gt_check_and_clear_faults(ggtt->vm.gt);
+ list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+ intel_gt_check_and_clear_faults(gt);
flush = i915_ggtt_resume_vm(&ggtt->vm);
@@ -1307,9 +1336,6 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
if (flush)
wbinvd_on_
Re: [Intel-gfx] [PATCH v2] mei: add timeout to send
On Tue, Nov 15, 2022 at 02:27:02PM +, Usyskin, Alexander wrote:
> > > - else
> > > + } else {
> > > dev_dbg(&cldev->dev, "memory ready command
> > sent\n");
> > > + cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
> >
> > What does the mode change have to do with a timeout?
> With timeout the mei_gfx_memory_ready may now fail gracefully
> and we should not move state if message is not sent.
>
> Should I split this fix into another patch or document in this one?
Split it into a different patch please.
> > > +/**
> > > + * __mei_cl_send_timeout - internal client send (write)
> > > + *
> > > + * @cl: host client
> > > + * @buf: buffer to send
> > > + * @length: buffer length
> > > + * @vtag: virtual tag
> > > + * @mode: sending mode
> > > + * @timeout: send timeout in milliseconds for blocking writes
> >
> > What do you mean "for blocking writes"?
>
> The timeout has no effect for non-blocking writes (bit in mode parameter),
> as they are returning immediately and are not waiting at all.
That's not obvious, please say that the timeout is affected by the mode
and how it is affected.
thanks,
greg k-h
Re: [Intel-gfx] [PATCH] drm/i915: Fix build failure with debug and extra logging enabled
On 15/11/2022 14:39, Janusz Krzysztofik wrote:
A comma is missing, fix it.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 3b969d679c1e2..947fde68e5f53 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -73,7 +73,7 @@ static void vma_print_allocator(struct i915_vma *vma, const
char *reason)
char buf[512];
if (!vma->node.stack) {
- drm_dbg(&to_i915(vma->obj->base.dev)->drm
+ drm_dbg(&to_i915(vma->obj->base.dev)->drm,
"vma.node [%08llx + %08llx] %s: unknown owner\n",
vma->node.start, vma->node.size, reason);
return;
Yep, thanks, however already sent this morning:
https://patchwork.freedesktop.org/series/110906/. Just waiting for CI to
give it a green light, which is a bit pointless, nevertheless it's the
process.
Regards,
Tvrtko
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/1] drm/i915: Export LMEM max memory bandwidth via sysfs.
== Series Details == Series: series starting with [1/1] drm/i915: Export LMEM max memory bandwidth via sysfs. URL : https://patchwork.freedesktop.org/series/110902/ State : warning == Summary == Error: dim checkpatch failed b196769302e7 drm/i915: Export LMEM max memory bandwidth via sysfs. -:43: CHECK:CAMELCASE: Avoid CamelCase: #43: FILE: drivers/gpu/drm/i915/i915_sysfs.c:238: +prelim_lmem_max_bw_Mbps_show(struct device *dev, struct device_attribute *attr, char *buff) -:58: CHECK:CAMELCASE: Avoid CamelCase: #58: FILE: drivers/gpu/drm/i915/i915_sysfs.c:253: +static DEVICE_ATTR_RO(prelim_lmem_max_bw_Mbps); -:66: CHECK:CAMELCASE: Avoid CamelCase: #66: FILE: drivers/gpu/drm/i915/i915_sysfs.c:261: + ret = sysfs_create_file(&kdev->kobj, &dev_attr_prelim_lmem_max_bw_Mbps.attr); total: 0 errors, 0 warnings, 3 checks, 53 lines checked
[Intel-gfx] [PATCH] drm/i915: Fix build failure with debug and extra logging enabled
A comma is missing, fix it.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 3b969d679c1e2..947fde68e5f53 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -73,7 +73,7 @@ static void vma_print_allocator(struct i915_vma *vma, const
char *reason)
char buf[512];
if (!vma->node.stack) {
- drm_dbg(&to_i915(vma->obj->base.dev)->drm
+ drm_dbg(&to_i915(vma->obj->base.dev)->drm,
"vma.node [%08llx + %08llx] %s: unknown owner\n",
vma->node.start, vma->node.size, reason);
return;
--
2.25.1
Re: [Intel-gfx] [PATCH v2] mei: add timeout to send
> > When driver wakes up the firmware from the low power state, it is sending
> > a memory ready message.
> > The send is done via synchronous/blocking function to ensure that
> firmware
> > is in ready state. However, in case of firmware undergoing reset send
> > might be block forever.
> > To address this issue a timeout is added to blocking write command on
> > the internal bus.
>
> Odd formatting of the text :(
Odd == not balanced? Will try to do better in V3
>
> >
> > Introduce the __mei_cl_send_timeout function to use instead of
> > __mei_cl_send in cases where timeout is required.
> > The mei_cl_write has only two callers and there is no need to split
> > it into two functions.
> >
> > Signed-off-by: Alexander Usyskin
> > ---
> > V2: address review comments:
> > - split __mei_cl_send and __mei_cl_send_timeout
> > - add units to timeout KDoc
> > - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro
> >
> > drivers/misc/mei/bus-fixup.c | 14 +-
> > drivers/misc/mei/bus.c | 22 --
> > drivers/misc/mei/client.c| 18 ++
> > drivers/misc/mei/client.h| 2 +-
> > drivers/misc/mei/main.c | 2 +-
> > drivers/misc/mei/mei_dev.h | 2 ++
> > 6 files changed, 47 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
> > index 71fbf0bc8453..9959b8e8e91d 100644
> > --- a/drivers/misc/mei/bus-fixup.c
> > +++ b/drivers/misc/mei/bus-fixup.c
> > @@ -188,17 +188,20 @@ static int mei_fwver(struct mei_cl_device *cldev)
> > return ret;
> > }
> >
> > +#define GFX_MEMORY_READY_TIMEOUT 200
>
> units?
Will add here too, sure.
>
> > +
> > static int mei_gfx_memory_ready(struct mei_cl_device *cldev)
> > {
> > struct mkhi_gfx_mem_ready req = {0};
> > - unsigned int mode = MEI_CL_IO_TX_INTERNAL;
> > + unsigned int mode = MEI_CL_IO_TX_INTERNAL |
> MEI_CL_IO_TX_BLOCKING;
> >
> > req.hdr.group_id = MKHI_GROUP_ID_GFX;
> > req.hdr.command = MKHI_GFX_MEMORY_READY_CMD_REQ;
> > req.flags = MKHI_GFX_MEM_READY_PXP_ALLOWED;
> >
> > dev_dbg(&cldev->dev, "Sending memory ready command\n");
> > - return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode);
> > + return __mei_cl_send_timeout(cldev->cl, (u8 *)&req, sizeof(req), 0,
> > +mode, GFX_MEMORY_READY_TIMEOUT);
> > }
> >
> > static void mei_mkhi_fix(struct mei_cl_device *cldev)
> > @@ -263,12 +266,13 @@ static void mei_gsc_mkhi_fix_ver(struct
> mei_cl_device *cldev)
> >
> > if (cldev->bus->pxp_mode == MEI_DEV_PXP_INIT) {
> > ret = mei_gfx_memory_ready(cldev);
> > - if (ret < 0)
> > + if (ret < 0) {
> > dev_err(&cldev->dev, "memory ready command
> failed %d\n", ret);
> > - else
> > + } else {
> > dev_dbg(&cldev->dev, "memory ready command
> sent\n");
> > + cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
>
> What does the mode change have to do with a timeout?
With timeout the mei_gfx_memory_ready may now fail gracefully
and we should not move state if message is not sent.
Should I split this fix into another patch or document in this one?
>
> > + }
> > /* we go to reset after that */
> > - cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
> > goto out;
> > }
> >
> > diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
> > index 1fbe127ff633..63043e8df980 100644
> > --- a/drivers/misc/mei/bus.c
> > +++ b/drivers/misc/mei/bus.c
> > @@ -32,8 +32,26 @@
> > *
> > * Return: written size bytes or < 0 on error
> > */
> > -ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t length, u8
> vtag,
> > +inline ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t
> length, u8 vtag,
> > unsigned int mode)
>
> Why inline? The compiler is smart enough.
Will drop
>
> > +{
> > + return __mei_cl_send_timeout(cl, buf, length, vtag, mode,
> MAX_SCHEDULE_TIMEOUT);
>
> So this will block for how long? Please document this.
>
> > +}
> > +
> > +/**
> > + * __mei_cl_send_timeout - internal client send (write)
> > + *
> > + * @cl: host client
> > + * @buf: buffer to send
> > + * @length: buffer length
> > + * @vtag: virtual tag
> > + * @mode: sending mode
> > + * @timeout: send timeout in milliseconds for blocking writes
>
> What do you mean "for blocking writes"?
The timeout has no effect for non-blocking writes (bit in mode parameter),
as they are returning immediately and are not waiting at all.
>
> And what do you use here to wait "for forever"?
The MAX_SCHEDULE_TIMEOUT indicates 'forever' - will add it in KDoc
This is implementation of Rodrigo's suggestion to use only wait with timeout
but with
maximum one if 'forever' is required.
>
> > + *
> > + * Return: written size bytes or < 0 on error
> > + */
> > +ssize_t __mei_cl_send_timeout(struct mei_cl *cl, const u8 *buf, size_t
> length,
Re: [Intel-gfx] [PATCH v2] drm/i915/ttm: never purge busy objects
On 11/15/2022 11:46 AM, Matthew Auld wrote:
In i915_gem_madvise_ioctl() we immediately purge the object is not
currently used, like when the mm.pages are NULL. With shmem the pages
might still be hanging around or are perhaps swapped out. Similarly with
ttm we might still have the pages hanging around on the ttm resource,
like with lmem or shmem, but here we need to be extra careful since
async unbinds are possible as well as in-progress kernel moves. In
i915_ttm_purge() we expect the pipeline-gutting to nuke the ttm resource
for us, however if it's busy the memory is only moved to a ghost object,
which then leads to broken behaviour when for example clearing the
i915_tt->filp, since the actual ttm_tt is still alive and populated,
even though it's been moved to the ghost object. When we later destroy
the ghost object we hit the following, since the filp is now NULL:
[ +0.006982] #PF: supervisor read access in kernel mode
[ +0.005149] #PF: error_code(0x) - not-present page
[ +0.005147] PGD 11631d067 P4D 11631d067 PUD 115972067 PMD 0
[ +0.005676] Oops: [#1] PREEMPT SMP NOPTI
[ +0.012962] Workqueue: events ttm_device_delayed_workqueue [ttm]
[ +0.006022] RIP: 0010:i915_ttm_tt_unpopulate+0x3a/0x70 [i915]
[ +0.005879] Code: 89 fb 48 85 f6 74 11 8b 55 4c 48 8b 7d 30 45 31 c0 31 c9 e8
18 6a e5 e0 80 7d 60 00 74 20 48 8b 45 68
8b 55 08 4c 89 e7 5b 5d <48> 8b 40 20 83 e2 01 41 5c 89 d1 48 8b 70
30 e9 42 b2 ff ff 4c 89
[ +0.018782] RSP: :c9000bf6fd70 EFLAGS: 00010202
[ +0.005244] RAX: RBX: 8883e12ae380 RCX:
[ +0.007150] RDX: 800e RSI: 823559b4 RDI: 8883e12ae3c0
[ +0.007142] RBP: 888103b65d48 R08: 0001 R09: 0001
[ +0.007144] R10: 0001 R11: 88829c2c8040 R12: 8883e12ae3c0
[ +0.007148] R13: 0001 R14: 888115184140 R15: 888115184248
[ +0.007154] FS: () GS:88844db0()
knlGS:
[ +0.008108] CS: 0010 DS: ES: CR0: 80050033
[ +0.005763] CR2: 0020 CR3: 00013fdb4004 CR4: 003706e0
[ +0.007152] DR0: DR1: DR2:
[ +0.007145] DR3: DR6: fffe0ff0 DR7: 0400
[ +0.007154] Call Trace:
[ +0.002459]
[ +0.002126] ttm_tt_unpopulate.part.0+0x17/0x70 [ttm]
[ +0.005068] ttm_bo_tt_destroy+0x1c/0x50 [ttm]
[ +0.004464] ttm_bo_cleanup_memtype_use+0x25/0x40 [ttm]
[ +0.005244] ttm_bo_cleanup_refs+0x90/0x2c0 [ttm]
[ +0.004721] ttm_bo_delayed_delete+0x235/0x250 [ttm]
[ +0.004981] ttm_device_delayed_workqueue+0x13/0x40 [ttm]
[ +0.005422] process_one_work+0x248/0x560
[ +0.004028] worker_thread+0x4b/0x390
[ +0.003682] ? process_one_work+0x560/0x560
[ +0.004199] kthread+0xeb/0x120
[ +0.003163] ? kthread_complete_and_exit+0x20/0x20
[ +0.004815] ret_from_fork+0x1f/0x30
v2:
- Just use ttm_bo_wait() directly (Niranjana)
- Add testcase reference
Testcase: igt@gem_madvise@dontneed-evict-race
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Reported-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
Acked-by: Nirmoy Das
Cc: # v5.15+
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e4e55e3f4e41..34793863ea45 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -603,6 +603,10 @@ static int i915_ttm_truncate(struct drm_i915_gem_object
*obj)
WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
+ err = ttm_bo_wait(bo, true, false);
+ if (err)
+ return err;
+
err = i915_ttm_move_notify(bo);
if (err)
return err;
Re: [Intel-gfx] [PATCH v2] mei: add timeout to send
On Tue, Nov 15, 2022 at 01:14:38PM +0200, Alexander Usyskin wrote:
> When driver wakes up the firmware from the low power state, it is sending
> a memory ready message.
> The send is done via synchronous/blocking function to ensure that firmware
> is in ready state. However, in case of firmware undergoing reset send
> might be block forever.
> To address this issue a timeout is added to blocking write command on
> the internal bus.
Odd formatting of the text :(
>
> Introduce the __mei_cl_send_timeout function to use instead of
> __mei_cl_send in cases where timeout is required.
> The mei_cl_write has only two callers and there is no need to split
> it into two functions.
>
> Signed-off-by: Alexander Usyskin
> ---
> V2: address review comments:
> - split __mei_cl_send and __mei_cl_send_timeout
> - add units to timeout KDoc
> - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro
>
> drivers/misc/mei/bus-fixup.c | 14 +-
> drivers/misc/mei/bus.c | 22 --
> drivers/misc/mei/client.c| 18 ++
> drivers/misc/mei/client.h| 2 +-
> drivers/misc/mei/main.c | 2 +-
> drivers/misc/mei/mei_dev.h | 2 ++
> 6 files changed, 47 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
> index 71fbf0bc8453..9959b8e8e91d 100644
> --- a/drivers/misc/mei/bus-fixup.c
> +++ b/drivers/misc/mei/bus-fixup.c
> @@ -188,17 +188,20 @@ static int mei_fwver(struct mei_cl_device *cldev)
> return ret;
> }
>
> +#define GFX_MEMORY_READY_TIMEOUT 200
units?
> +
> static int mei_gfx_memory_ready(struct mei_cl_device *cldev)
> {
> struct mkhi_gfx_mem_ready req = {0};
> - unsigned int mode = MEI_CL_IO_TX_INTERNAL;
> + unsigned int mode = MEI_CL_IO_TX_INTERNAL | MEI_CL_IO_TX_BLOCKING;
>
> req.hdr.group_id = MKHI_GROUP_ID_GFX;
> req.hdr.command = MKHI_GFX_MEMORY_READY_CMD_REQ;
> req.flags = MKHI_GFX_MEM_READY_PXP_ALLOWED;
>
> dev_dbg(&cldev->dev, "Sending memory ready command\n");
> - return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode);
> + return __mei_cl_send_timeout(cldev->cl, (u8 *)&req, sizeof(req), 0,
> + mode, GFX_MEMORY_READY_TIMEOUT);
> }
>
> static void mei_mkhi_fix(struct mei_cl_device *cldev)
> @@ -263,12 +266,13 @@ static void mei_gsc_mkhi_fix_ver(struct mei_cl_device
> *cldev)
>
> if (cldev->bus->pxp_mode == MEI_DEV_PXP_INIT) {
> ret = mei_gfx_memory_ready(cldev);
> - if (ret < 0)
> + if (ret < 0) {
> dev_err(&cldev->dev, "memory ready command failed
> %d\n", ret);
> - else
> + } else {
> dev_dbg(&cldev->dev, "memory ready command sent\n");
> + cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
What does the mode change have to do with a timeout?
> + }
> /* we go to reset after that */
> - cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
> goto out;
> }
>
> diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
> index 1fbe127ff633..63043e8df980 100644
> --- a/drivers/misc/mei/bus.c
> +++ b/drivers/misc/mei/bus.c
> @@ -32,8 +32,26 @@
> *
> * Return: written size bytes or < 0 on error
> */
> -ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t length, u8
> vtag,
> +inline ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t
> length, u8 vtag,
> unsigned int mode)
Why inline? The compiler is smart enough.
> +{
> + return __mei_cl_send_timeout(cl, buf, length, vtag, mode,
> MAX_SCHEDULE_TIMEOUT);
So this will block for how long? Please document this.
> +}
> +
> +/**
> + * __mei_cl_send_timeout - internal client send (write)
> + *
> + * @cl: host client
> + * @buf: buffer to send
> + * @length: buffer length
> + * @vtag: virtual tag
> + * @mode: sending mode
> + * @timeout: send timeout in milliseconds for blocking writes
What do you mean "for blocking writes"?
And what do you use here to wait "for forever"?
> + *
> + * Return: written size bytes or < 0 on error
> + */
> +ssize_t __mei_cl_send_timeout(struct mei_cl *cl, const u8 *buf, size_t
> length, u8 vtag,
> + unsigned int mode, unsigned long timeout)
> {
> struct mei_device *bus;
> struct mei_cl_cb *cb;
> @@ -108,7 +126,7 @@ ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf,
> size_t length, u8 vtag,
> cb->buf.size = 0;
> }
>
> - rets = mei_cl_write(cl, cb);
> + rets = mei_cl_write(cl, cb, timeout);
>
> if (mode & MEI_CL_IO_SGL && rets == 0)
> rets = length;
> diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
> index 6c8b71ae32c8..02c278202ad7 100644
> --- a/drivers/misc/mei/client.c
> +++ b/drivers/misc/mei/client.c
> @@ -1954,10 +1954,11 @@ int mei_cl_irq_write(struct mei_cl *cl
[Intel-gfx] [PATCH 1/1] drm/i915/mtl: Enable Idle Messaging for GSC CS
From: Vinay Belgaumkar
By defaut idle mesaging is disabled for GSC CS so to unblock RC6
entry on media tile idle messaging need to be enabled.
v2:
- Fix review comments (Vinay)
- Set GSC idle hysterisis to 5 us (Badal)
Bspec: 71496
Cc: Daniele Ceraolo Spurio
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b0a4a2dbe3ee..5522885b2db0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -15,6 +15,22 @@
#include "intel_rc6.h"
#include "intel_ring.h"
#include "shmem_utils.h"
+#include "intel_gt_regs.h"
+
+static void intel_gsc_idle_msg_enable(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ if (IS_METEORLAKE(i915) && engine->id == GSC0) {
+ intel_uncore_write(engine->gt->uncore,
+ RC_PSMI_CTRL_GSCCS,
+ _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
+ /* 5 us hysterisis */
+ intel_uncore_write(engine->gt->uncore,
+ PWRCTX_MAXCNT_GSCCS,
+ 0xA);
+ }
+}
static void dbg_poison_ce(struct intel_context *ce)
{
@@ -275,6 +291,8 @@ void intel_engine_init__pm(struct intel_engine_cs *engine)
intel_wakeref_init(&engine->wakeref, rpm, &wf_ops);
intel_engine_init_heartbeat(engine);
+
+ intel_gsc_idle_msg_enable(engine);
}
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 07031e03f80c..20472eb15364 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -913,6 +913,10 @@
#define MSG_IDLE_FW_MASK REG_GENMASK(13, 9)
#define MSG_IDLE_FW_SHIFT 9
+#defineRC_PSMI_CTRL_GSCCS _MMIO(0x11a050)
+#define IDLE_MSG_DISABLE BIT(0)
+#define PWRCTX_MAXCNT_GSCCS_MMIO(0x11a054)
+
#define FORCEWAKE_MEDIA_GEN9 _MMIO(0xa270)
#define FORCEWAKE_RENDER_GEN9 _MMIO(0xa278)
--
2.25.1
[Intel-gfx] [PATCH 0/1] i915/mtl: Enable idle messaging for GSC CS
This series includes code change to enable idle messaging for GSC CS. v2: - Dropped dependency patch and rebased - Fixed review comments Cc: Vinay Belgaumkar Vinay Belgaumkar (1): drm/i915/mtl: Enable Idle Messaging for GSC CS drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18 ++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 2 files changed, 22 insertions(+) -- 2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: remove circ_buf.h includes (rev2)
== Series Details ==
Series: drm/i915: remove circ_buf.h includes (rev2)
URL : https://patchwork.freedesktop.org/series/98130/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12380_full -> Patchwork_98130v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_98130v2_full absolutely need to
be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_98130v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_98130v2_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_fence@syncobj-timeline-wait:
- shard-skl: [PASS][1] -> [WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl9/igt@gem_exec_fe...@syncobj-timeline-wait.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/shard-skl6/igt@gem_exec_fe...@syncobj-timeline-wait.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_persistence@smoketest:
- {shard-rkl}:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-rkl-3/igt@gem_ctx_persiste...@smoketest.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/shard-rkl-2/igt@gem_ctx_persiste...@smoketest.html
Known issues
Here are the changes found in Patchwork_98130v2_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-skl: ([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], [PASS][41], [PASS][42], [PASS][43], [FAIL][44],
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50],
[PASS][51]) ([i915#5032])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl9/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl9/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl9/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl7/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl7/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl7/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl4/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl4/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl10/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl10/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl10/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12380/shard-skl1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/shard-skl9/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/shard-skl9/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/shard-skl7/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/shard-skl7/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98
Re: [Intel-gfx] [PATCH 07/20] drm/i915/mtl: Add support for PM DEMAND
> -Original Message-
> From: Sripada, Radhakrishna
> Sent: Tuesday, November 1, 2022 4:38 AM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Cc: Atwood, Matthew S ; Roper, Matthew D
> ; De Marchi, Lucas ;
> Souza, Jose
> Subject: RE: [PATCH 07/20] drm/i915/mtl: Add support for PM DEMAND
>
>
>
> > -Original Message-
> > From: Kahola, Mika
> > Sent: Friday, October 14, 2022 5:47 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Kahola, Mika ; Atwood, Matthew S
> > ; Roper, Matthew D
> > ; De Marchi, Lucas
> > ; Souza, Jose ;
> > Sripada, Radhakrishna
> > Subject: [PATCH 07/20] drm/i915/mtl: Add support for PM DEMAND
> >
> > Display14 introduces a new way to instruct the PUnit with power and
> > bandwidth requirements of DE. Add the functionality to program the
> > registers and handle waits using interrupts.
> > The current wait time for timeouts is programmed for 10 msecs to
> > factor in the worst case scenarios. Changes made to use REG_BIT for a
> > register that we touched(GEN8_DE_MISC_IER _MMIO).
> >
> > Bspec: 66451, 64636, 64602, 64603
> >
> > Cc: Matt Atwood
> > Cc: Matt Roper
> > Cc: Lucas De Marchi
> >
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Radhakrishna Sripada
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
> > drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> > drivers/gpu/drm/i915/display/intel_display.c | 14 +
> > .../drm/i915/display/intel_display_power.c| 8 +
> > drivers/gpu/drm/i915/i915_drv.h | 12 +
> > drivers/gpu/drm/i915/i915_irq.c | 22 +-
> > drivers/gpu/drm/i915/i915_reg.h | 33 +-
> > drivers/gpu/drm/i915/intel_pm.c | 286 ++
> > drivers/gpu/drm/i915/intel_pm.h | 35 +++
> > 9 files changed, 411 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 4ace026b29bd..6c467b6f2234 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -716,8 +716,8 @@ static unsigned int
> > intel_bw_num_active_planes(struct drm_i915_private *dev_priv
> > return num_active_planes;
> > }
> >
> > -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > - const struct intel_bw_state *bw_state)
> > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > + const struct intel_bw_state *bw_state)
> > {
> > unsigned int data_rate = 0;
> > enum pipe pipe;
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > b/drivers/gpu/drm/i915/display/intel_bw.h
> > index cb7ee3a24a58..b3eb82a71e6c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private
> > *dev_priv); int intel_bw_atomic_check(struct intel_atomic_state
> > *state); void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > const struct intel_crtc_state *crtc_state);
> > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > + const struct intel_bw_state *bw_state);
> > int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> > u32 points_mask);
> > int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 0a8749753e6e..5ce33319b70d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1079,6 +1079,9 @@ intel_get_crtc_new_encoder(const struct
> > intel_atomic_state *state,
> > num_encoders++;
> > }
> >
> > + if (!encoder)
> > + return NULL;
> > +
> > drm_WARN(encoder->base.dev, num_encoders != 1,
> > "%d encoders for pipe %c\n",
> > num_encoders, pipe_name(master_crtc->pipe)); @@ -6898,6
> +6901,10
> > @@ static int intel_atomic_check(struct drm_device *dev,
> > ret = intel_modeset_calc_cdclk(state);
> > if (ret)
> > return ret;
> > +
> > + ret = intel_pmdemand_atomic_check(state);
> > + if (ret)
> > + goto fail;
> > }
> >
> > ret = intel_atomic_check_crtcs(state); @@ -7521,6 +7528,7 @@ static
> > void intel_atomic_commit_tail(struct intel_atomic_state *state)
> > }
> >
> > intel_sagv_pre_plane_update(state);
> > + intel_pmdemand_pre_plane_update(state);
> >
> > /* Complete the events for pipes that have now been disabled */
> > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > @@ -7622,6 +7630,7 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> > intel_verify_planes(
[Intel-gfx] [PATCH v2] mei: add timeout to send
When driver wakes up the firmware from the low power state, it is sending
a memory ready message.
The send is done via synchronous/blocking function to ensure that firmware
is in ready state. However, in case of firmware undergoing reset send
might be block forever.
To address this issue a timeout is added to blocking write command on
the internal bus.
Introduce the __mei_cl_send_timeout function to use instead of
__mei_cl_send in cases where timeout is required.
The mei_cl_write has only two callers and there is no need to split
it into two functions.
Signed-off-by: Alexander Usyskin
---
V2: address review comments:
- split __mei_cl_send and __mei_cl_send_timeout
- add units to timeout KDoc
- use MAX_SCHEDULE_TIMEOUT to squash wait to one macro
drivers/misc/mei/bus-fixup.c | 14 +-
drivers/misc/mei/bus.c | 22 --
drivers/misc/mei/client.c| 18 ++
drivers/misc/mei/client.h| 2 +-
drivers/misc/mei/main.c | 2 +-
drivers/misc/mei/mei_dev.h | 2 ++
6 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 71fbf0bc8453..9959b8e8e91d 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -188,17 +188,20 @@ static int mei_fwver(struct mei_cl_device *cldev)
return ret;
}
+#define GFX_MEMORY_READY_TIMEOUT 200
+
static int mei_gfx_memory_ready(struct mei_cl_device *cldev)
{
struct mkhi_gfx_mem_ready req = {0};
- unsigned int mode = MEI_CL_IO_TX_INTERNAL;
+ unsigned int mode = MEI_CL_IO_TX_INTERNAL | MEI_CL_IO_TX_BLOCKING;
req.hdr.group_id = MKHI_GROUP_ID_GFX;
req.hdr.command = MKHI_GFX_MEMORY_READY_CMD_REQ;
req.flags = MKHI_GFX_MEM_READY_PXP_ALLOWED;
dev_dbg(&cldev->dev, "Sending memory ready command\n");
- return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode);
+ return __mei_cl_send_timeout(cldev->cl, (u8 *)&req, sizeof(req), 0,
+mode, GFX_MEMORY_READY_TIMEOUT);
}
static void mei_mkhi_fix(struct mei_cl_device *cldev)
@@ -263,12 +266,13 @@ static void mei_gsc_mkhi_fix_ver(struct mei_cl_device
*cldev)
if (cldev->bus->pxp_mode == MEI_DEV_PXP_INIT) {
ret = mei_gfx_memory_ready(cldev);
- if (ret < 0)
+ if (ret < 0) {
dev_err(&cldev->dev, "memory ready command failed
%d\n", ret);
- else
+ } else {
dev_dbg(&cldev->dev, "memory ready command sent\n");
+ cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
+ }
/* we go to reset after that */
- cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
goto out;
}
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 1fbe127ff633..63043e8df980 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -32,8 +32,26 @@
*
* Return: written size bytes or < 0 on error
*/
-ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t length, u8 vtag,
+inline ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t length,
u8 vtag,
unsigned int mode)
+{
+ return __mei_cl_send_timeout(cl, buf, length, vtag, mode,
MAX_SCHEDULE_TIMEOUT);
+}
+
+/**
+ * __mei_cl_send_timeout - internal client send (write)
+ *
+ * @cl: host client
+ * @buf: buffer to send
+ * @length: buffer length
+ * @vtag: virtual tag
+ * @mode: sending mode
+ * @timeout: send timeout in milliseconds for blocking writes
+ *
+ * Return: written size bytes or < 0 on error
+ */
+ssize_t __mei_cl_send_timeout(struct mei_cl *cl, const u8 *buf, size_t length,
u8 vtag,
+ unsigned int mode, unsigned long timeout)
{
struct mei_device *bus;
struct mei_cl_cb *cb;
@@ -108,7 +126,7 @@ ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf,
size_t length, u8 vtag,
cb->buf.size = 0;
}
- rets = mei_cl_write(cl, cb);
+ rets = mei_cl_write(cl, cb, timeout);
if (mode & MEI_CL_IO_SGL && rets == 0)
rets = length;
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 6c8b71ae32c8..02c278202ad7 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1954,10 +1954,11 @@ int mei_cl_irq_write(struct mei_cl *cl, struct
mei_cl_cb *cb,
*
* @cl: host client
* @cb: write callback with filled data
+ * @timeout: send timeout in milliseconds for blocking writes
*
* Return: number of bytes sent on success, <0 on failure.
*/
-ssize_t mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb)
+ssize_t mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb, unsigned long
timeout)
{
struct mei_device *dev;
struct mei_msg_data *buf;
@@ -2081,11 +2082,20 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct
mei_cl_cb *cb)
Re: [Intel-gfx] [PATCH v7 20/20] drm/i915/vm_bind: Async vm_unbind support
On 13/11/2022 07:57, Niranjana Vishwanathapura wrote:
Asynchronously unbind the vma upon vm_unbind call.
Fall back to synchronous unbind if backend doesn't support
async unbind or if async unbind fails.
No need for vm_unbind out fence support as i915 will internally
handle all sequencing and user need not try to sequence any
operation with the unbind completion.
v2: use i915_vma_destroy_async in vm_unbind ioctl
Signed-off-by: Niranjana Vishwanathapura
This only does it for non-partial vma, right? Or was that changed somewhere?
Reviewed-by: Matthew Auld
---
.../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
drivers/gpu/drm/i915/i915_vma.c | 51 +--
drivers/gpu/drm/i915/i915_vma.h | 1 +
include/uapi/drm/i915_drm.h | 3 +-
4 files changed, 51 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
index d87d1210365b..36651b447966 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
@@ -210,7 +210,7 @@ static int i915_gem_vm_unbind_vma(struct i915_address_space
*vm,
*/
obj = vma->obj;
i915_gem_object_lock(obj, NULL);
- i915_vma_destroy(vma);
+ i915_vma_destroy_async(vma);
i915_gem_object_unlock(obj);
i915_gem_object_put(obj);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 7cf77c67d755..483d25f2425c 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -42,6 +42,8 @@
#include "i915_vma.h"
#include "i915_vma_resource.h"
+static struct dma_fence *__i915_vma_unbind_async(struct i915_vma *vma);
+
static inline void assert_vma_held_evict(const struct i915_vma *vma)
{
/*
@@ -1713,7 +1715,7 @@ void i915_vma_reopen(struct i915_vma *vma)
spin_unlock_irq(>->closed_lock);
}
-static void force_unbind(struct i915_vma *vma)
+static void force_unbind(struct i915_vma *vma, bool async)
{
if (!drm_mm_node_allocated(&vma->node))
return;
@@ -1727,7 +1729,21 @@ static void force_unbind(struct i915_vma *vma)
i915_vma_set_purged(vma);
atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- WARN_ON(__i915_vma_unbind(vma));
+ if (async) {
+ struct dma_fence *fence;
+
+ fence = __i915_vma_unbind_async(vma);
+ if (IS_ERR_OR_NULL(fence)) {
+ async = false;
+ } else {
+ dma_resv_add_fence(vma->obj->base.resv, fence,
+ DMA_RESV_USAGE_READ);
+ dma_fence_put(fence);
+ }
+ }
+
+ if (!async)
+ WARN_ON(__i915_vma_unbind(vma));
GEM_BUG_ON(drm_mm_node_allocated(&vma->node));
}
@@ -1787,7 +1803,7 @@ void i915_vma_destroy_locked(struct i915_vma *vma)
{
lockdep_assert_held(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
list_del_init(&vma->vm_link);
release_references(vma, vma->vm->gt, false);
}
@@ -1798,7 +1814,34 @@ void i915_vma_destroy(struct i915_vma *vma)
bool vm_ddestroy;
mutex_lock(&vma->vm->mutex);
- force_unbind(vma);
+ force_unbind(vma, false);
+ list_del_init(&vma->vm_link);
+ vm_ddestroy = vma->vm_ddestroy;
+ vma->vm_ddestroy = false;
+
+ /* vma->vm may be freed when releasing vma->vm->mutex. */
+ gt = vma->vm->gt;
+ mutex_unlock(&vma->vm->mutex);
+ release_references(vma, gt, vm_ddestroy);
+}
+
+void i915_vma_destroy_async(struct i915_vma *vma)
+{
+ bool vm_ddestroy, async = vma->obj->mm.rsgt;
+ struct intel_gt *gt;
+
+ if (dma_resv_reserve_fences(vma->obj->base.resv, 1))
+ async = false;
+
+ mutex_lock(&vma->vm->mutex);
+ /*
+* Ensure any asynchronous binding is complete while using
+* async unbind as we will be releasing the vma here.
+*/
+ if (async && i915_active_wait(&vma->active))
+ async = false;
+
+ force_unbind(vma, async);
list_del_init(&vma->vm_link);
vm_ddestroy = vma->vm_ddestroy;
vma->vm_ddestroy = false;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 737ef310d046..25f15965dab8 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -272,6 +272,7 @@ void i915_vma_reopen(struct i915_vma *vma);
void i915_vma_destroy_locked(struct i915_vma *vma);
void i915_vma_destroy(struct i915_vma *vma);
+void i915_vma_destroy_async(struct i915_vma *vma);
#define assert_vma_held(vma) dma_resv_assert_held((vma)->obj->base.resv)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e5600f358a15..431d40bb1dee 100644
--- a/include/uapi/d
Re: [Intel-gfx] [PATCH v5 3/9] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format
On Tue, Nov 15, 2022 at 12:23:53PM +0530, Nautiyal, Ankit K wrote:
>
> On 11/11/2022 2:36 AM, Ville Syrjälä wrote:
> > On Fri, Oct 28, 2022 at 03:14:05PM +0530, Ankit Nautiyal wrote:
> >> The decision to use DFP output format conversion capabilities should be
> >> during compute_config phase.
> >>
> >> This patch uses the members of intel_dp->dfp to only store the
> >> format conversion capabilities of the DP device and uses the crtc_state
> >> sink_format member, to program the protocol-converter for
> >> colorspace/format conversion.
> >>
> >> v2: Use sink_format to determine the color conversion config for the
> >> pcon (Ville).
> >>
> >> v3: Fix typo: missing 'break' in switch case (lkp kernel test robot).
> >>
> >> v4: Add helper to check if DP supports YCBCR420.
> >>
> >> Signed-off-by: Ankit Nautiyal
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dp.c | 122
> >> 1 file changed, 84 insertions(+), 38 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 0e4f7b467970..95d0c653db7f 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -790,6 +790,7 @@ intel_dp_output_format(struct intel_connector
> >> *connector,
> >> enum intel_output_format sink_format)
> >> {
> >>struct intel_dp *intel_dp = intel_attached_dp(connector);
> >> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >>
> >>if (!connector->base.ycbcr_420_allowed ||
> >>sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> >> @@ -799,6 +800,10 @@ intel_dp_output_format(struct intel_connector
> >> *connector,
> >>intel_dp->dfp.ycbcr_444_to_420)
> >>return INTEL_OUTPUT_FORMAT_RGB;
> >>
> >> + /* Prefer 4:2:0 passthrough over 4:4:4->4:2:0 conversion */
> >> + if (DISPLAY_VER(i915) >= 11 && intel_dp->dfp.ycbcr420_passthrough)
> >> + return INTEL_OUTPUT_FORMAT_YCBCR420;
> >> +
> >>if (intel_dp->dfp.ycbcr_444_to_420)
> >>return INTEL_OUTPUT_FORMAT_YCBCR444;
> >>else
> > The else branch here is also 420, so the whole logic
> > here doesn't seem to flow entirely sensibly.
> >
> > Thinking a bit more abstractly, could we restate
> > this whole problem as something more like this?
> >
> > if (source_can_output(sink_format))
> > return sink_format;
> >
> > if (source_can_output(RGB) &&
> > dfp_can_convert_from_rgb(sink_format))
> > return RGB;
> >
> > if (source_can_output(YCBCR444) &&
> > dfp_can_convert_from_ycbcr444(sink_format))
> > return YCBCR444;
>
> This make sense and will also help to add 422 support easier.
>
> I am only seeing one problem: about how to have DSC considerations
> during source_can_output( ).
>
> Gen 11+ should support YCBCR420. So for any ycbcr420_only mode we should
> have sink_format, and output_format : YCbCr420.
>
> This works well for cases where DSC doesn't get in picture. When higher
> modes like 8k60 ycbcr420_only are involved, we need to use DSC.
>
> Currently, our DSC1.1 does not support YCbCr420. The problem is that we
> go for, dsc_compute_config at a later time.
>
> This issue might have been masked, due to the messy order of checks in
> intel_dp_output_format.
>
> Specifically With HDMI2.1 PCONs supporting color conv, for such a case
> we can have output_format as RGB, and sink_format as YCbCr420.
>
> The DSC compression with RGB and then configure PCON to Decompress,
> conv. to YCbCr420.
>
> So can we put a check in source_can_output for Gen11+ where DSC might be
> required, so that with source_can_output(YCBCR420) returns false in such
> case, where DSC is the only way?
I'm thinking it should work well enough without any extra checks
since we'll always try RGB before YCbC4 4:2:0. I guess the only
case where it could fail is if the sink only supports 4:2:0 for
that particular mode. Then we'd also try direct YCbC4 4:2:0 output
on icl+. Dunno if such sinks are still a thing when DSC is in the
picture.
Hmm. Do PCONs even support DSC + color conversion/etc. at the
same time? They'd have to decompress and potentially recompress
the data in that case.
The problem with adding DSC checks into source_can_output() is
that we'd need to express those in a way that is also usable in
.mode_valid() since we'd want to use the same code there I think.
Looks like we do have some DSC stuff in there already, but it
doesn't seem to take that into account in the link bandwidth
check. So to me it looks like the whole DSC support is incomplete
anyway.
--
Ville Syrjälä
Intel
[Intel-gfx] [PATCH v2] drm/i915/ttm: never purge busy objects
In i915_gem_madvise_ioctl() we immediately purge the object is not
currently used, like when the mm.pages are NULL. With shmem the pages
might still be hanging around or are perhaps swapped out. Similarly with
ttm we might still have the pages hanging around on the ttm resource,
like with lmem or shmem, but here we need to be extra careful since
async unbinds are possible as well as in-progress kernel moves. In
i915_ttm_purge() we expect the pipeline-gutting to nuke the ttm resource
for us, however if it's busy the memory is only moved to a ghost object,
which then leads to broken behaviour when for example clearing the
i915_tt->filp, since the actual ttm_tt is still alive and populated,
even though it's been moved to the ghost object. When we later destroy
the ghost object we hit the following, since the filp is now NULL:
[ +0.006982] #PF: supervisor read access in kernel mode
[ +0.005149] #PF: error_code(0x) - not-present page
[ +0.005147] PGD 11631d067 P4D 11631d067 PUD 115972067 PMD 0
[ +0.005676] Oops: [#1] PREEMPT SMP NOPTI
[ +0.012962] Workqueue: events ttm_device_delayed_workqueue [ttm]
[ +0.006022] RIP: 0010:i915_ttm_tt_unpopulate+0x3a/0x70 [i915]
[ +0.005879] Code: 89 fb 48 85 f6 74 11 8b 55 4c 48 8b 7d 30 45 31 c0 31 c9 e8
18 6a e5 e0 80 7d 60 00 74 20 48 8b 45 68
8b 55 08 4c 89 e7 5b 5d <48> 8b 40 20 83 e2 01 41 5c 89 d1 48 8b 70
30 e9 42 b2 ff ff 4c 89
[ +0.018782] RSP: :c9000bf6fd70 EFLAGS: 00010202
[ +0.005244] RAX: RBX: 8883e12ae380 RCX:
[ +0.007150] RDX: 800e RSI: 823559b4 RDI: 8883e12ae3c0
[ +0.007142] RBP: 888103b65d48 R08: 0001 R09: 0001
[ +0.007144] R10: 0001 R11: 88829c2c8040 R12: 8883e12ae3c0
[ +0.007148] R13: 0001 R14: 888115184140 R15: 888115184248
[ +0.007154] FS: () GS:88844db0()
knlGS:
[ +0.008108] CS: 0010 DS: ES: CR0: 80050033
[ +0.005763] CR2: 0020 CR3: 00013fdb4004 CR4: 003706e0
[ +0.007152] DR0: DR1: DR2:
[ +0.007145] DR3: DR6: fffe0ff0 DR7: 0400
[ +0.007154] Call Trace:
[ +0.002459]
[ +0.002126] ttm_tt_unpopulate.part.0+0x17/0x70 [ttm]
[ +0.005068] ttm_bo_tt_destroy+0x1c/0x50 [ttm]
[ +0.004464] ttm_bo_cleanup_memtype_use+0x25/0x40 [ttm]
[ +0.005244] ttm_bo_cleanup_refs+0x90/0x2c0 [ttm]
[ +0.004721] ttm_bo_delayed_delete+0x235/0x250 [ttm]
[ +0.004981] ttm_device_delayed_workqueue+0x13/0x40 [ttm]
[ +0.005422] process_one_work+0x248/0x560
[ +0.004028] worker_thread+0x4b/0x390
[ +0.003682] ? process_one_work+0x560/0x560
[ +0.004199] kthread+0xeb/0x120
[ +0.003163] ? kthread_complete_and_exit+0x20/0x20
[ +0.004815] ret_from_fork+0x1f/0x30
v2:
- Just use ttm_bo_wait() directly (Niranjana)
- Add testcase reference
Testcase: igt@gem_madvise@dontneed-evict-race
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Reported-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
Cc: Andrzej Hajda
Cc: Nirmoy Das
Cc: # v5.15+
Reviewed-by: Niranjana Vishwanathapura
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e4e55e3f4e41..34793863ea45 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -603,6 +603,10 @@ static int i915_ttm_truncate(struct drm_i915_gem_object
*obj)
WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
+ err = ttm_bo_wait(bo, true, false);
+ if (err)
+ return err;
+
err = i915_ttm_move_notify(bo);
if (err)
return err;
--
2.38.1
Re: [Intel-gfx] [PATCH] drm/i915: Fix vma allocator debug
On 15.11.2022 11:17, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a missing colon which I accidentally removed in the recent logging
changes.
Signed-off-by: Tvrtko Ursulin
Fixes: a10234fda466 ("drm/i915: Partial abandonment of legacy DRM logging
macros")
Cc: Andrzej Hajda
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 3b969d679c1e..947fde68e5f5 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -73,7 +73,7 @@ static void vma_print_allocator(struct i915_vma *vma, const
char *reason)
char buf[512];
if (!vma->node.stack) {
- drm_dbg(&to_i915(vma->obj->base.dev)->drm
+ drm_dbg(&to_i915(vma->obj->base.dev)->drm,
"vma.node [%08llx + %08llx] %s: unknown owner\n",
vma->node.start, vma->node.size, reason);
return;
[Intel-gfx] [PATCH i-g-t] tests/i915/madvise: verify async eviction with madvise
Simple regression test for lmem to check if an in-progress async unbind
and eviction is syncronised with discarding the pages when marking
the object as DONTNEED.
Signed-off-by: Matthew Auld
Cc: Niranjana Vishwanathapura
Cc: Andrzej Hajda
Cc: Nirmoy Das
---
tests/i915/gem_madvise.c | 130 ++-
1 file changed, 129 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
index 2502d84c..d164df3a 100644
--- a/tests/i915/gem_madvise.c
+++ b/tests/i915/gem_madvise.c
@@ -36,8 +36,9 @@
#include
#include
-#include "drm.h"
+#include "igt_kmod.h"
#include "i915/gem_create.h"
+#include "i915/gem.h"
IGT_TEST_DESCRIPTION("Checks that the kernel reports EFAULT when trying to use"
" purged bo.");
@@ -188,6 +189,76 @@ dontneed_before_exec(void)
close(fd);
}
+#define PAGE_SIZE 4096
+
+static uint32_t batch_create_size(int fd, uint64_t size)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(fd, size);
+ gem_write(fd, handle, 0, &bbe, sizeof(bbe));
+
+ return handle;
+}
+
+static int upload(int fd, uint32_t handle)
+{
+ struct drm_i915_gem_exec_object2 exec[2] = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&exec),
+ .buffer_count = 2,
+ };
+
+ exec[0].handle = handle;
+ exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+ exec[1].handle = batch_create_size(fd, PAGE_SIZE);
+ exec[1].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+
+ gem_execbuf(fd, &execbuf);
+ return 0;
+}
+
+static void test_dontneed_evict_race(int fd,
+struct gem_memory_region *region)
+{
+ const uint64_t size = region->size >> 1;
+ uint64_t ahnd = get_reloc_ahnd(fd, 0);
+ uint32_t handle1;
+ igt_spin_t *spin;
+
+ handle1 = gem_create_in_memory_region_list(fd, size, 0,
+ ®ion->ci, 1);
+ spin = igt_spin_new(fd,
+ .ahnd = ahnd,
+ .dependency = handle1);
+
+ igt_fork(child, 1) {
+ uint32_t handle2;
+
+ fd = gem_reopen_driver(fd);
+
+ handle2 = gem_create_in_memory_region_list(fd,
+ size, 0,
+ ®ion->ci, 1);
+ /*
+* The actual move when evicting will be pipelined
+* behind the spinner, so can't fire until the spinner
+* is killed.
+*/
+ upload(fd, handle2);
+ gem_close(fd, handle2);
+ }
+
+ sleep(2); /* Give eviction time to find handle1 */
+ igt_spin_end(spin);
+ gem_madvise(fd, handle1, I915_MADV_DONTNEED);
+ igt_waitchildren();
+
+ igt_spin_free(fd, spin);
+ gem_close(fd, handle1);
+}
+
igt_main
{
igt_describe("Check signal for Segmentation Fault and bus error before"
@@ -209,4 +280,61 @@ igt_main
" purged bo for GPU.");
igt_subtest("dontneed-before-exec")
dontneed_before_exec();
+
+ igt_subtest_group {
+ struct drm_i915_query_memory_regions *regions;
+ int i915 = -1;
+
+ igt_fixture {
+ char *tmp;
+
+ if (igt_kmod_is_loaded("i915")) {
+ i915 = __drm_open_driver(DRIVER_INTEL);
+ igt_require_fd(i915);
+ igt_require_gem(i915);
+ igt_require(gem_has_lmem(i915));
+ close(i915);
+ }
+
+ igt_i915_driver_unload();
+ /*
+* To avoid running of ring space and stalling during
evicting
+* (while holding the dma-resv lock), we need to use a
smaller
+* lmem size, such we can easliy trigger eviction
without
+* needing to wait for more ring space. The point of
the test is
+* to mark the object as DONTNEED which has an
in-progress
+* pipilined unbind/move, which also requires grabbing
the
+* dma-resv lock.
+*/
+ igt_assert_eq(igt_i915_driver_load("lmem_size=128"), 0);
+
+ i915 = __drm_open_driver(DRIVER_INTEL);
+ igt_require_fd(i915);
+ igt_require_gem(i915);
+ igt_require(gem_has_lmem(i915));
+
+ tmp = __igt_params_get(i915, "lmem_size");
+ igt_skip_on(!tmp);
+ free(tmp);
+
+
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Add GT oriented dmesg output
On 10/11/2022 10:35, Michal Wajdeczko wrote:
On 10.11.2022 10:55, Tvrtko Ursulin wrote:
On 09/11/2022 19:57, Michal Wajdeczko wrote:
[snip]
Is it really a problem to merge this patch now to get the process
started? And other sub-components get updated as and when people get the
time to do them? You could maybe even help rather than posting
completely conflicting patch sets that basically duplicate all the
effort for no actual benefit.
Instead of merging this patch now, oriented on GT only, I would rather
wait until we discuss and plan solution for the all sub-components.
Yes, agreed.
Once that's done (with agreement on naming and output) we can start
converting exiting messages.
My proposal would be:
- use wrappers per component
This is passable to me but Jani has raised a concern on IRC that it
leads to a lot of macro duplication. Which is I think a valid point, but
which does not have a completely nice solution. Best I heard so far was
a suggestion from Joonas to add just a single component formatter macro
and use the existing drm_xxx helpers.
- use lower case names
I prefer this as well. Even though usual argument is for macros to be
upper case, I find the improved readability of lower case trumps that.
- don't add colon
Not sure, when I look at it below it looks a bit not structured enough
without the colon, but maybe it is just me.
#define i915_xxx(_i915, _fmt, ...) \
drm_xxx(&(_i915)->drm, _fmt, ##__VA_ARGS__)
#define gt_xxx(_gt, _fmt, ...) \
i915_xxx((_gt)->i915, "GT%u " _fmt, (_gt)->info.id, ..
#define guc_xxx(_guc, _fmt, ...) \
gt_xxx(guc_to_gt(_guc), "GuC " _fmt, ..
#define ct_xxx(_ct, _fmt, ...) \
guc_xxx(ct_to_guc(_ct), "CTB " _fmt, ..
where
xxx = { err, warn, notice, info, dbg }
and then for calls like:
i915_err(i915, "Foo failed (%pe)\n", ERR_PTR(err));
gt_err(gt, "Foo failed (%pe)\n", ERR_PTR(err));
guc_err(guc, "Foo failed (%pe)\n", ERR_PTR(err));
ct_err(ct, "Foo failed (%pe)\n", ERR_PTR(err));
Okay lets go with this then since we have allowed some time for comments
and no strict objections have been raised. Probably limit to to
GT/GuC/CT space for not, ie. not adding i915_ loggers.
My preference is just to have a colon in the GT identifier, lowercase or
uppercase I don't mind.
Regards,
Tvrtko
So the macro idea would be like this:
drm_err(I915_LOG("Foo failed (%pe)\n", i915), ERR_PTR(err));
drm_err(GT_LOG("Foo failed (%pe)\n", gt), ERR_PTR(err));
drm_err(GUC_LOG("Foo failed (%pe)\n", guc), ERR_PTR(err));
drm_err(CT_LOG("Foo failed (%pe)\n", ct), ERR_PTR(err));
Each component would just need to define a single macro and not have to
duplicate all the err, info, warn, notice, ratelimited, once, whatever
versions. Which is a benefit but it's a quite a bit uglier to read in
the code.
If there is a choice between having ugly code all over the place and few
more lines with helpers then without any doubts I would pick the latter.
And this seems to be option already used elsewhere, see:
#define dev_err(dev, fmt, ...) \
dev_printk_index_wrap ...
#define pci_err(pdev, fmt, arg...) \
dev_err(&(pdev)->dev, fmt, ##arg)
#define drm_err(drm, fmt, ...) \
__drm_printk((drm), err,, "*ERROR* " fmt, ##__VA_ARGS__)
#define drbd_err(obj, fmt, args...) \
drbd_printk(KERN_ERR, obj, fmt, ## args)
#define ch7006_err(client, format, ...) \
dev_err(&client->dev, format, __VA_ARGS__)
#define mthca_err(mdev, format, arg...) \
dev_err(&mdev->pdev->dev, format, ## arg)
#define ctx_err(ctx, fmt, arg...) \
cal_err((ctx)->cal, "ctx%u: " fmt, (ctx)->dma_ctx, ##arg)
#define mlx4_err(mdev, format, ...) \
dev_err(&(mdev)->persist->pdev->dev, format, ##__VA_ARGS__)
...
Michal
[1]
https://elixir.bootlin.com/linux/v6.1-rc4/source/include/linux/dev_printk.h#L143
[2]
https://elixir.bootlin.com/linux/v6.1-rc4/source/include/linux/pci.h#L2485
[3]
https://elixir.bootlin.com/linux/v6.1-rc4/source/include/drm/drm_print.h#L468
[4]
https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/block/drbd/drbd_int.h#L113
[5]
https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/gpu/drm/i2c/ch7006_priv.h#L139
[6]
https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/infiniband/hw/mthca/mthca_dev.h#L377
[7]
https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/media/platform/ti/cal/cal.h#L279
[8]
https://elixir.bootlin.com/linux/v6.1-rc4/source/drivers/net/ethernet/mellanox/mlx4/mlx4.h#L225
Perhaps macro could be called something other than XX_LOG to make it
more readable, don't know.
Regards,
Tvrtko
[Intel-gfx] [PATCH] drm/i915: Fix vma allocator debug
From: Tvrtko Ursulin
Add a missing colon which I accidentally removed in the recent logging
changes.
Signed-off-by: Tvrtko Ursulin
Fixes: a10234fda466 ("drm/i915: Partial abandonment of legacy DRM logging
macros")
Cc: Andrzej Hajda
---
drivers/gpu/drm/i915/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 3b969d679c1e..947fde68e5f5 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -73,7 +73,7 @@ static void vma_print_allocator(struct i915_vma *vma, const
char *reason)
char buf[512];
if (!vma->node.stack) {
- drm_dbg(&to_i915(vma->obj->base.dev)->drm
+ drm_dbg(&to_i915(vma->obj->base.dev)->drm,
"vma.node [%08llx + %08llx] %s: unknown owner\n",
vma->node.start, vma->node.size, reason);
return;
--
2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove circ_buf.h includes (rev2)
== Series Details == Series: drm/i915: remove circ_buf.h includes (rev2) URL : https://patchwork.freedesktop.org/series/98130/ State : success == Summary == CI Bug Log - changes from CI_DRM_12380 -> Patchwork_98130v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/index.html Participating hosts (38 -> 39) -- Additional (3): fi-pnv-d510 fi-tgl-dsi bat-dg1-5 Missing(2): bat-dg2-11 fi-rkl-11600 Known issues Here are the changes found in Patchwork_98130v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-pnv-d510:NOTRUN -> [FAIL][1] ([i915#7229]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html * igt@gem_lmem_swapping@basic: - fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-apl-guc/igt@gem_lmem_swapp...@basic.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4083]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#1155]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#6621]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@kms_addfb_basic@basic-x-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4212]) +7 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@kms_addfb_ba...@basic-x-tiled-legacy.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4215]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bsw-nick:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-bsw-nick/igt@kms_chamel...@common-hpd-after-suspend.html - fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html - fi-apl-guc: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-apl-guc/igt@kms_chamel...@common-hpd-after-suspend.html - fi-rkl-guc: NOTRUN -> [SKIP][13] ([fdo#111827]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-rkl-guc/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@hdmi-hpd-fast: - bat-dg1-5: NOTRUN -> [SKIP][14] ([fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4103] / [i915#4213]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-5: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@suspend-read-crc: - fi-bsw-nick:NOTRUN -> [SKIP][17] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-bsw-nick/igt@kms_pipe_crc_ba...@suspend-read-crc.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][18] ([fdo#109271]) +43 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/fi-pnv-d510/igt@kms_psr@primary_page_flip.html * igt@kms_psr@sprite_plane_onoff: - bat-dg1-5: NOTRUN -> [SKIP][19] ([i915#1072] / [i915#4078]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_98130v2/bat-dg1
Re: [Intel-gfx] [PATCH 2/3] Documentation/gpu: Limit index to maxdepth=2
On 07.11.2022 09:32, Lucas De Marchi wrote: > With a lot of sub-section it's a little bit hard to find the information > needed in the main GPU index. Limit the maxdepth to 2 so it doesn't get > poluted with noise from each driver and from other sections. > > Signed-off-by: Lucas De Marchi > --- > Documentation/gpu/index.rst | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst > index b99dede9a5b1..1d9402d519be 100644 > --- a/Documentation/gpu/index.rst > +++ b/Documentation/gpu/index.rst > @@ -3,6 +3,7 @@ Linux GPU Driver Developer's Guide > == > > .. toctree:: > + :maxdepth: 2 I have a bit different opinion here. I find it helpful to search for a topic if the headers remain uncollapsed. A top level view is anyways available in the TOC shown in the left side of the page which shows only the immediate next level headers. Regards, Bala > > introduction > drm-internals > -- > 2.38.1 >
Re: [Intel-gfx] [PATCH] drm/fb-helper: Try to protect cleanup against delayed setup
On 13.07.2021 15:59, Daniel Vetter wrote:
Some vague evidences suggests this can go wrong. Try to prevent it by
holding the right mutex and clearing ->deferred_setup to make sure we
later on don't accidentally try to re-register the fbdev when the
driver thought it had it all cleaned up already.
v2: I realized that this is fundamentally butchered, and CI complained
about lockdep splats. So limit the critical section again and just add
a few notes what the proper fix is.
References:
https://intel-gfx-ci.01.org/tree/linux-next/next-20201215/fi-byt-j1900/igt@i915_pm_...@module-reload.html
Signed-off-by: Daniel Vetter
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/drm_fb_helper.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9d82fda274eb..8f11e5abb222 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -598,6 +598,9 @@ EXPORT_SYMBOL(drm_fb_helper_alloc_fbi);
* A wrapper around unregister_framebuffer, to release the fb_info
* framebuffer device. This must be called before releasing all resources for
* @fb_helper by calling drm_fb_helper_fini().
+ *
+ * Note that this is fundamentally racy on hotunload because it doen't handle
+ * open fbdev file descriptors at all. Use drm_fbdev_generic_setup() instead.
*/
void drm_fb_helper_unregister_fbi(struct drm_fb_helper *fb_helper)
{
@@ -611,6 +614,9 @@ EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
* @fb_helper: driver-allocated fbdev helper, can be NULL
*
* This cleans up all remaining resources associated with @fb_helper.
+ *
+ * Note that this is fundamentally racy on hotunload because it doen't handle
+ * open fbdev file descriptors at all. Use drm_fbdev_generic_setup() instead.
*/
void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
{
@@ -2382,6 +2388,10 @@ static void drm_fbdev_client_unregister(struct
drm_client_dev *client)
{
struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+ mutex_lock(&fb_helper->lock);
+ fb_helper->deferred_setup = false;
+ mutex_unlock(&fb_helper->lock);
+
if (fb_helper->fbdev)
/* drm_fbdev_fb_destroy() takes care of cleanup */
drm_fb_helper_unregister_fbi(fb_helper);
Re: [Intel-gfx] (subset) [PATCH v9 11/25] drm/modes: Fill drm_cmdline mode from named modes
On Mon, 14 Nov 2022 14:00:30 +0100, Maxime Ripard wrote: > The current code to deal with named modes will only set the mode name, and > then it's up to drivers to try to match that name to whatever mode or > configuration they see fit. > > The plan is to remove that need and move the named mode handling out of > drivers and into the core, and only rely on modes and properties. Let's > start by properly filling drm_cmdline_mode from a named mode. > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [Intel-gfx] (subset) [PATCH v9 12/25] drm/connector: Add pixel clock to cmdline mode
On Mon, 14 Nov 2022 14:00:31 +0100, Maxime Ripard wrote: > We'll need to get the pixel clock to generate proper display modes for > all the current named modes. Let's add it to struct drm_cmdline_mode and > fill it when parsing the named mode. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [Intel-gfx] (subset) [PATCH v9 10/25] drm/modes: Switch to named mode descriptors
On Mon, 14 Nov 2022 14:00:29 +0100, Maxime Ripard wrote: > The current named mode parsing relies only on the mode name, and doesn't > allow to specify any other parameter. > > Let's convert that string list to an array of a custom structure that will > hold the name and some additional parameters in the future. > > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [Intel-gfx] (subset) [PATCH v9 09/25] drm/modes: Move named modes parsing to a separate function
On Mon, 14 Nov 2022 14:00:28 +0100, Maxime Ripard wrote: > The current construction of the named mode parsing doesn't allow to extend > it easily. Let's move it to a separate function so we can add more > parameters and modes. > > In order for the tests to still pass, some extra checks are needed, so > it's not a 1:1 move. > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [Intel-gfx] (subset) [PATCH v9 08/25] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On Mon, 14 Nov 2022 14:00:27 +0100, Maxime Ripard wrote: > drm_connector_pick_cmdline_mode() is in charge of finding a proper > drm_display_mode from the definition we got in the video= command line > argument. > > Let's add some unit tests to make sure we're not getting any regressions > there. > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [Intel-gfx] (subset) [PATCH v9 02/25] drm/tests: Add Kunit Helpers
On Mon, 14 Nov 2022 14:00:21 +0100, Maxime Ripard wrote: > As the number of kunit tests in KMS grows further, we start to have > multiple test suites that, for example, need to register a mock DRM > driver to interact with the KMS function they are supposed to test. > > Let's add a file meant to provide those kind of helpers to avoid > duplication. > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
Re: [Intel-gfx] (subset) [PATCH v9 01/25] docs/fb: Document current named modes
On Mon, 14 Nov 2022 14:00:20 +0100, Maxime Ripard wrote: > KMS supports a number of named modes already, but it's never been > documented anywhere, let's fix that. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Add missing checks for
cdclk crawling
URL : https://patchwork.freedesktop.org/series/110882/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12379_full -> Patchwork_110882v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110882v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110882v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110882v1_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_schedule@reorder-wide@vcs0:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl9/igt@gem_exec_schedule@reorder-w...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl4/igt@gem_exec_schedule@reorder-w...@vcs0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip_scaled_crc@flip-64bpp-xtile-to-16bpp-xtile-downscaling:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-dg1-17/igt@kms_flip_scaled_...@flip-64bpp-xtile-to-16bpp-xtile-downscaling.html
Known issues
Here are the changes found in Patchwork_110882v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-skl: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
[PASS][8], [PASS][9], [PASS][10], [FAIL][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]) ([i915#5032]) ->
([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], [PASS][41], [PASS][42],
[PASS][43], [PASS][44])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl9/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl9/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl7/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl7/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl4/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl4/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl2/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl2/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl1/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl1/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl1/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl10/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl10/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12379/shard-skl10/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl9/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl9/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl9/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl9/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl7/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl7/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl7/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110882v1/shard-skl6/boot.html
[33]:
https://intel-
[Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs.
Export lmem maximum memory bandwidth to the userspace via sysfs.
Signed-off-by: Himal Prasad Ghimiray
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/i915_sysfs.c | 27 +++
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c4921c9a60770..3ba1efa995ca9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6603,6 +6603,8 @@
#definePOWER_SETUP_I1_WATTSREG_BIT(31)
#definePOWER_SETUP_I1_SHIFT6 /* 10.6 fixed
point format */
#definePOWER_SETUP_I1_DATA_MASKREG_GENMASK(15, 0)
+#define PCODE_MEMORY_CONFIG 0x70
+#defineMEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH 0x0
#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
#define XEHP_PCODE_FREQUENCY_CONFIG 0x6e/* xehpsdv, pvc */
/* XEHP_PCODE_FREQUENCY_CONFIG sub-commands (param1) */
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 595e8b5749907..0a6efc300998b 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -37,7 +37,10 @@
#include "i915_drv.h"
#include "i915_sysfs.h"
+#include "i915_reg.h"
#include "intel_pm.h"
+#include "intel_pcode.h"
+
struct drm_i915_private *kdev_minor_to_i915(struct device *kdev)
{
@@ -231,11 +234,35 @@ static void i915_setup_error_capture(struct device *kdev)
{}
static void i915_teardown_error_capture(struct device *kdev) {}
#endif
+static ssize_t
+prelim_lmem_max_bw_Mbps_show(struct device *dev, struct device_attribute
*attr, char *buff)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+ u32 val;
+ int err;
+
+ err = snb_pcode_read_p(&i915->uncore, PCODE_MEMORY_CONFIG,
+ MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH,
+ 0x0, &val);
+ if (err)
+ return err;
+
+ return sysfs_emit(buff, "%u\n", val);
+}
+
+static DEVICE_ATTR_RO(prelim_lmem_max_bw_Mbps);
+
void i915_setup_sysfs(struct drm_i915_private *dev_priv)
{
struct device *kdev = dev_priv->drm.primary->kdev;
int ret;
+ if (IS_DG1(dev_priv) || IS_DG2(dev_priv)) {
+ ret = sysfs_create_file(&kdev->kobj,
&dev_attr_prelim_lmem_max_bw_Mbps.attr);
+ if (ret)
+ drm_err(&dev_priv->drm, "Setting up sysfs to read max
B/W failed\n");
+ }
+
if (HAS_L3_DPF(dev_priv)) {
ret = device_create_bin_file(kdev, &dpf_attrs);
if (ret)
--
2.25.1
