[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Not to try to re-enable PSR after being raised an irq aux error (rev2)
== Series Details == Series: drm/i915/display: Not to try to re-enable PSR after being raised an irq aux error (rev2) URL : https://patchwork.freedesktop.org/series/88072/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9870_full -> Patchwork_19808_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19808_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19808_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19808_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@userptr: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl10/igt@gem_exec_capt...@userptr.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-skl1/igt@gem_exec_capt...@userptr.html * igt@kms_color@pipe-b-ctm-negative: - shard-glk: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-glk3/igt@kms_co...@pipe-b-ctm-negative.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-glk3/igt@kms_co...@pipe-b-ctm-negative.html * igt@sysfs_heartbeat_interval@precise@vecs0: - shard-apl: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl1/igt@sysfs_heartbeat_interval@prec...@vecs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-apl8/igt@sysfs_heartbeat_interval@prec...@vecs0.html Known issues Here are the changes found in Patchwork_19808_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][7] ([i915#1839]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-tglb1/igt@feature_discov...@display-4x.html - shard-iclb: NOTRUN -> [SKIP][8] ([i915#1839]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-iclb8/igt@feature_discov...@display-4x.html * igt@gem_ctx_param@set-priority-not-supported: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109314]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1099]) +4 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-snb5/igt@gem_ctx_persiste...@idempotent.html * igt@gem_ctx_sseu@mmap-args: - shard-tglb: NOTRUN -> [SKIP][11] ([i915#280]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-tglb1/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][12] -> [TIMEOUT][13] ([i915#2369] / [i915#3063]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-tglb2/igt@gem_...@unwedge-stress.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-tglb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2846]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-kbl2/igt@gem_exec_f...@basic-deadline.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-kbl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl7/igt@gem_exec_fair@basic-n...@vcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-apl6/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][20] ([i915#2842]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: NOTRUN -> [FAIL][21] ([i915#2842]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][22] -> [FAIL][23] ([i915
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length
== Series Details == Series: series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length URL : https://patchwork.freedesktop.org/series/88132/ State : success == Summary == CI Bug Log - changes from CI_DRM_9870_full -> Patchwork_19807_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_19807_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19807_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19807_full: ### IGT changes ### Warnings * igt@runner@aborted: - shard-apl: ([FAIL][1], [FAIL][2], [FAIL][3], [FAIL][4], [FAIL][5]) ([i915#180] / [i915#2724] / [i915#3002]) -> ([FAIL][6], [FAIL][7], [FAIL][8]) ([i915#2724] / [i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl3/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl6/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl7/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl6/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl2/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-apl7/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-apl2/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-apl6/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_19807_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][9] ([i915#1839]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-tglb7/igt@feature_discov...@display-4x.html - shard-iclb: NOTRUN -> [SKIP][10] ([i915#1839]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-iclb7/igt@feature_discov...@display-4x.html * igt@gem_create@create-clear: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#3160]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl4/igt@gem_cre...@create-clear.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-skl1/igt@gem_cre...@create-clear.html * igt@gem_ctx_param@set-priority-not-supported: - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#109314]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-iclb7/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@idempotent: - shard-snb: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1099]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-snb7/igt@gem_ctx_persiste...@idempotent.html * igt@gem_ctx_sseu@mmap-args: - shard-tglb: NOTRUN -> [SKIP][15] ([i915#280]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-tglb7/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][16] -> [TIMEOUT][17] ([i915#2369] / [i915#2771] / [i915#3063]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl1/igt@gem_...@unwedge-stress.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-skl9/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: NOTRUN -> [FAIL][18] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][19] -> [FAIL][20] ([i915#2851]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#2842]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][23] -> [FAIL][24] ([i915#2842]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs1.html * i
[Intel-gfx] ✗ Fi.CI.IGT: failure for Default request/fence expiry + watchdog (rev3)
== Series Details ==
Series: Default request/fence expiry + watchdog (rev3)
URL : https://patchwork.freedesktop.org/series/87930/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9870_full -> Patchwork_19806_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_19806_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19806_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_19806_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_ringsize@idle@bcs0:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl10/igt@gem_ctx_ringsize@i...@bcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-skl7/igt@gem_ctx_ringsize@i...@bcs0.html
* {igt@gem_watchdog@far-fence@bcs0} (NEW):
- shard-glk: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-glk7/igt@gem_watchdog@far-fe...@bcs0.html
* {igt@gem_watchdog@far-fence@vcs0} (NEW):
- shard-apl: NOTRUN -> [FAIL][4] +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-apl1/igt@gem_watchdog@far-fe...@vcs0.html
* {igt@gem_watchdog@far-fence@vecs0} (NEW):
- shard-kbl: NOTRUN -> [FAIL][5] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-kbl7/igt@gem_watchdog@far-fe...@vecs0.html
Warnings
* igt@gem_userptr_blits@vma-merge:
- shard-apl: [INCOMPLETE][6] ([i915#2502] / [i915#2667]) ->
[FAIL][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl6/igt@gem_userptr_bl...@vma-merge.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-apl8/igt@gem_userptr_bl...@vma-merge.html
- shard-iclb: [INCOMPLETE][8] ([i915#2502] / [i915#2667]) ->
[FAIL][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-iclb7/igt@gem_userptr_bl...@vma-merge.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-iclb6/igt@gem_userptr_bl...@vma-merge.html
- shard-glk: [INCOMPLETE][10] ([i915#2502] / [i915#2667]) ->
[FAIL][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-glk6/igt@gem_userptr_bl...@vma-merge.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-glk6/igt@gem_userptr_bl...@vma-merge.html
- shard-kbl: [INCOMPLETE][12] ([i915#2502] / [i915#2667]) ->
[FAIL][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-kbl6/igt@gem_userptr_bl...@vma-merge.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-kbl4/igt@gem_userptr_bl...@vma-merge.html
- shard-tglb: [INCOMPLETE][14] ([i915#2502] / [i915#2667]) ->
[FAIL][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-tglb3/igt@gem_userptr_bl...@vma-merge.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-tglb7/igt@gem_userptr_bl...@vma-merge.html
- shard-skl: [INCOMPLETE][16] ([i915#2502] / [i915#2667]) ->
[FAIL][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl7/igt@gem_userptr_bl...@vma-merge.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-skl7/igt@gem_userptr_bl...@vma-merge.html
* igt@runner@aborted:
- shard-skl: ([FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21],
[FAIL][22], [FAIL][23]) ([i915#1814] / [i915#2029] / [i915#2724] / [i915#3002])
-> ([FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29],
[FAIL][30]) ([i915#1814] / [i915#2029] / [i915#2426] / [i915#3002])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl2/igt@run...@aborted.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl3/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl7/igt@run...@aborted.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl9/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl3/igt@run...@aborted.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl4/igt@run...@aborted.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-skl2/igt@run...@aborted.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-skl6/igt@run...@aborted.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/shard-skl8/igt@run...@aborted.html
[27]:
https://intel-gfx-ci.01.org/t
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
== Series Details == Series: drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT URL : https://patchwork.freedesktop.org/series/88128/ State : success == Summary == CI Bug Log - changes from CI_DRM_9870_full -> Patchwork_19805_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19805_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-tglb3/igt@feature_discov...@display-4x.html - shard-iclb: NOTRUN -> [SKIP][2] ([i915#1839]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-iclb8/igt@feature_discov...@display-4x.html * igt@gem_ctx_param@set-priority-not-supported: - shard-iclb: NOTRUN -> [SKIP][3] ([fdo#109314]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +4 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-snb5/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_ctx_sseu@mmap-args: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#280]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-tglb3/igt@gem_ctx_s...@mmap-args.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#2369]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl6/igt@gem_exec_capture@p...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-skl10/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-kbl2/igt@gem_exec_f...@basic-deadline.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-kbl6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: NOTRUN -> [FAIL][13] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-iclb6/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#2842]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-glk8/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271]) +308 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-snb: NOTRUN -> [FAIL][19] ([i915#2389]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-snb5/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1610] / [i915#2803]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl6/igt@gem_exec_schedule@u-fairsl...@rcs0.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-skl1/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_whisper@basic-forked-all: - shard-glk: [PASS][22] -> [DMESG-WARN][23] ([i915#118] / [i915#95]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/shard-glk7
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Shuffle DP code around (rev2)
== Series Details == Series: drm/i915: Shuffle DP code around (rev2) URL : https://patchwork.freedesktop.org/series/85878/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9870_full -> Patchwork_19804_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19804_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19804_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19804_full: ### IGT changes ### Possible regressions * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy@wc: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl4/igt@gem_userptr_blits@map-fixed-invalidate-overlap-b...@wc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl5/igt@gem_userptr_blits@map-fixed-invalidate-overlap-b...@wc.html * igt@sysfs_heartbeat_interval@precise@vecs0: - shard-apl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-apl1/igt@sysfs_heartbeat_interval@prec...@vecs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-apl8/igt@sysfs_heartbeat_interval@prec...@vecs0.html Warnings * igt@runner@aborted: - shard-skl: ([FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10]) ([i915#1814] / [i915#2029] / [i915#2724] / [i915#3002]) -> ([FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20]) ([i915#1436] / [i915#1814] / [i915#2029] / [i915#2426] / [i915#2724] / [i915#3002]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl2/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl3/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl7/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl9/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl3/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/shard-skl4/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl5/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl4/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl5/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl6/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl9/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl7/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl2/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl3/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl3/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-skl5/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_19804_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][21] ([i915#1839]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-tglb7/igt@feature_discov...@display-4x.html - shard-iclb: NOTRUN -> [SKIP][22] ([i915#1839]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-iclb8/igt@feature_discov...@display-4x.html * igt@gem_ctx_param@set-priority-not-supported: - shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109314]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#1099]) +2 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_ctx_sseu@mmap-args: - shard-tglb: NOTRUN -> [SKIP][25] ([i915#280]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/shard-tglb7/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][26] -> [TIMEOUT][27] ([i915#2369] / [i915#3063]) [
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs
On Fri, Mar 19, 2021 at 12:04:54AM +0200, Almahallawy, Khaled wrote:
> On Thu, 2021-03-18 at 20:06 +0200, Imre Deak wrote:
> > On Thu, Mar 18, 2021 at 07:49:13PM +0200, Imre Deak wrote:
> > > On Thu, Mar 18, 2021 at 07:33:20PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Mar 17, 2021 at 08:48:59PM +0200, Imre Deak wrote:
> > > > > The spec requires to use at least 3.2ms for the AUX timeout
> > > > > period if
> > > > > there are LT-tunable PHY Repeaters on the link (2.11.2). An
> > > > > upcoming
> > > > > spec update makes this more specific, by requiring a 3.2ms
> > > > > minimum
> > > > > timeout period for the LTTPR detection reading the 0xF-
> > > > > 0xF0007
> > > > > range (3.6.5.1).
> > > >
> > > > I'm pondering if we could reduce the timeout after having
> > > > determined
> > > > wherther LTTPRs are present or not? But maybe that wouldn't
> > > > really speed
> > > > up anything since we can't reduce the timeout until after
> > > > detecting
> > > > *something*. And once there is something there we shouldn't
> > > > really get
> > > > any more timeouts I guess. So probably a totally stupid idea.
> > >
> > > Right, if something is connected it would take anyway as much time
> > > as it
> > > takes for the sink to reply whether or not we decreased the
> > > timeout.
> > >
> > > However if nothing is connected, we have the excessive timeout
> > > Khaled
> > > already noticed (160 * 4ms = 6.4 sec on ICL+). I think to improve
> > > that
> > > we could scale the total number of retries by making it
> > > total_timeout/platform_specific_timeout (letting total_timeout=2sec
> > > for
> > > instance) or just changing the drm retry logic to be time based
> > > instead
> > > of the number of retries we use atm.
> >
> > Doh, reducing simply the HW timeouts would be enough to fix this.
>
> What about Lyude's suggestion (
> https://patchwork.freedesktop.org/patch/420369/#comment_756572)
> to drop the retries in intel_dp_aux_xfer()
> /* Must try at least 3 times according to DP spec */
> for (try = 0; try < 5; try++) {
>
> And use only the retries in drm_dpcd_access?
I think it would work if we can make the retries configurable and set it
to
retries = total_timeout / platform_specific_timeout_per_retry
where total_timeout would be something reasonable like 1 sec.
>
> Thanks
> Khaled
>
> >
> > > > Anyways, this seems about the only thing we can do given the
> > > > limited
> > > > hw capabilities.
> > > > Reviewed-by: Ville Syrjälä
> > > >
> > > > > Accordingly disable LTTPR detection until GLK, where the
> > > > > maximum timeout
> > > > > we can set is only 1.6ms.
> > > > >
> > > > > Link training in the non-transparent mode is known to fail at
> > > > > least on
> > > > > some SKL systems with a WD19 dock on the link, which exposes an
> > > > > LTTPR
> > > > > (see the References below). While this could have different
> > > > > reasons
> > > > > besides the too short AUX timeout used, not detecting LTTPRs
> > > > > (and so not
> > > > > using the non-transparent LT mode) fixes link training on these
> > > > > systems.
> > > > >
> > > > > While at it add a code comment about the platform specific
> > > > > maximum
> > > > > timeout values.
> > > > >
> > > > > v2: Add a comment about the g4x maximum timeout as well.
> > > > > (Ville)
> > > > >
> > > > > Reported-by: Takashi Iwai
> > > > > Reported-and-tested-by: Santiago Zarate <
> > > > > santiago.zar...@suse.com>
> > > > > Reported-and-tested-by: Bodo Graumann
> > > > > References:
> > > > > https://gitlab.freedesktop.org/drm/intel/-/issues/3166
> > > > > Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent
> > > > > mode link training")
> > > > > Cc: # v5.11
> > > > > Cc: Takashi Iwai
> > > > > Cc: Ville Syrjälä
> > > > > Signed-off-by: Imre Deak
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++
> > > > > .../gpu/drm/i915/display/intel_dp_link_training.c | 15
> > > > > ---
> > > > > 2 files changed, 19 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > > index eaebf123310a..10fe17b7280d 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > > @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct
> > > > > intel_dp *intel_dp,
> > > > > else
> > > > > precharge = 5;
> > > > >
> > > > > +/* Max timeout value on G4x-BDW: 1.6ms */
> > > > > if (IS_BROADWELL(dev_priv))
> > > > > timeout = DP_AUX_CH_CTL_TIME_OUT_600us;
> > > > > else
> > > > > @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct
> > > > > intel_dp *intel_dp,
> > > > > enum phy phy = intel_port_to_phy(i915, dig_port-
> > > > > >base.port);
> > > > > u32 ret;
> > > > >
> > > > > +/*
> > > > > + * Max timeout values:
> > > > > + * SKL-GLK: 1.6ms
> > > > > + * CNL: 3.2ms
> > > > > + * ICL+: 4ms
> > >
Re: [Intel-gfx] [PATCH] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
So basically we see this warning only in case of bigjoiner when drm_atomic_check gets called without setting the state->allow_modeset flag. So do you think that in i915, in intel_atomic_check_bigjoiner() we should only steal the crtc when allow_modeset flag is set in state? If we add this check there then the affected crtc wont count the slave crtc and we wont get this warning. Ville, Danvet? Manasi On Tue, Mar 16, 2021 at 10:35:09PM +0100, Daniel Vetter wrote: > On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen wrote: > > > > On Mon, 8 Mar 2021 16:52:58 -0800 > > "Navare, Manasi" wrote: > > > > > On Thu, Mar 04, 2021 at 10:42:23AM +0200, Pekka Paalanen wrote: > > > > On Wed, 3 Mar 2021 12:44:33 -0800 > > > > "Navare, Manasi" wrote: > > > > > > > > > On Wed, Mar 03, 2021 at 10:47:44AM +0200, Pekka Paalanen wrote: > > > > > > On Tue, 2 Mar 2021 12:41:32 -0800 > > > > > > Manasi Navare wrote: > > > > > > > > > > > > > In case of a modeset where a mode gets split across mutiple CRTCs > > > > > > > in the driver specific implementation (bigjoiner in i915) we > > > > > > > wrongly count > > > > > > > the affected CRTCs based on the drm_crtc_mask and indicate the > > > > > > > stolen CRTC as > > > > > > > an affected CRTC in atomic_check_only(). > > > > > > > This triggers a warning since affected CRTCs doent match > > > > > > > requested CRTC. > > > > > > > > > > > > > > To fix this in such bigjoiner configurations, we should only > > > > > > > increment affected crtcs if that CRTC is enabled in UAPI not > > > > > > > if it is just used internally in the driver to split the mode. > > > > > > > > > > > > Hi, > > > > > > > > > > > > I think that makes sense to me. Stealing CRTCs that are not > > > > > > currently > > > > > > used by the userspace (display server) should be ok, as long as that > > > > > > is completely invisible to userspace: meaning that it does not cause > > > > > > userspace to unexpectedly e.g. receive or miss per-crtc atomic > > > > > > completion events. > > > > > > > > > > Yes since we are only doing atomic_check_only() here, the stolen > > > > > > > > But the real not-test-only commit will follow if this test-only commit > > > > succeeds, and keeping the guarantees for the real commit are important. > > > > > > Hmm well after the actual real commit, since the second crtc is stolen > > > even though it is not being used for the display output, it is > > > used for joiner so the uapi.enable will be true after the real commit. > > > > > > so actually the assertion would fail in this case. > > > > > > @Ville @Danvet any suggestions here in that case? > > That is very bad. We can't frob uapi state like that. I think that > calls for even more checks to make sure kms drivers who try to play > clever games don't get it wrong, so we probably need to check uapi > enable and active state in another mask before/after ->atomic_check > too. Or something like that. > > > Hi, > > > > that is not what I was talking about, but sounds like you found a > > different problem. It seems like the problem you are talking about > > would be guaranteed to be hit if bigjoiner was used. Have you not > > tested this? > > > > However, I was talking about the real commit itself, not what happens > > on commits after it, see below. > > > > > > > crtc is completely invisible to the userspace and hence that is > > > > > indicated by uapi.enable which is not true for this stolen > > > > > crtc. However if allow modeset flag set, then it will do a full > > > > > modeset and indicate the uapi.enable for this stolen crtc as well > > > > > since that cannot be used for other modeset requested by userspace. > > > > > > > > > > > > > > > > > Can that also be asserted somehow, or does this already do that? > > > > > > > > > > Not clear what you want the assertion for? Could you elaborate > > > > > > > > As assertion that when the real atomic commit happens and then > > > > completion events are fired, they match exactly the affected crtcs mask. > > > > This is my concern and a question, although like I say below, only > > tangential to this patch. > > > > However, as this patch aims to allow bigjoiner usage, naturally the > > question will arise whether the completion events then match what > > userspace expects or not. Userspace does not expect completion events > > referring to the stolen CRTCs. > > Yeah we also must make sure that we don't send out events for these > additional crtc in bigjoiner usage. Sounds like igt testing didn't > catch this, I think we need a lot more igts here to make sure all > these surprises don't happen. > > Plus maybe triple-checking that drm_atomic_uapi.c makes sure we can't > send out events for stuff that userspace didn't ask for. > -Daniel > > > > > > > I understand this may be off-topic for this particular patch, but since > > > > we are discussing the topic, such checks would be really nice. I'm > > > > curious if such checks already exist. > > > > > > Thanks, > > pq > > > > > >
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs
On Thu, 2021-03-18 at 20:06 +0200, Imre Deak wrote:
> On Thu, Mar 18, 2021 at 07:49:13PM +0200, Imre Deak wrote:
> > On Thu, Mar 18, 2021 at 07:33:20PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 17, 2021 at 08:48:59PM +0200, Imre Deak wrote:
> > > > The spec requires to use at least 3.2ms for the AUX timeout
> > > > period if
> > > > there are LT-tunable PHY Repeaters on the link (2.11.2). An
> > > > upcoming
> > > > spec update makes this more specific, by requiring a 3.2ms
> > > > minimum
> > > > timeout period for the LTTPR detection reading the 0xF-
> > > > 0xF0007
> > > > range (3.6.5.1).
> > >
> > > I'm pondering if we could reduce the timeout after having
> > > determined
> > > wherther LTTPRs are present or not? But maybe that wouldn't
> > > really speed
> > > up anything since we can't reduce the timeout until after
> > > detecting
> > > *something*. And once there is something there we shouldn't
> > > really get
> > > any more timeouts I guess. So probably a totally stupid idea.
> >
> > Right, if something is connected it would take anyway as much time
> > as it
> > takes for the sink to reply whether or not we decreased the
> > timeout.
> >
> > However if nothing is connected, we have the excessive timeout
> > Khaled
> > already noticed (160 * 4ms = 6.4 sec on ICL+). I think to improve
> > that
> > we could scale the total number of retries by making it
> > total_timeout/platform_specific_timeout (letting total_timeout=2sec
> > for
> > instance) or just changing the drm retry logic to be time based
> > instead
> > of the number of retries we use atm.
>
> Doh, reducing simply the HW timeouts would be enough to fix this.
What about Lyude's suggestion (
https://patchwork.freedesktop.org/patch/420369/#comment_756572)
to drop the retries in intel_dp_aux_xfer()
/* Must try at least 3 times according to DP spec */
for (try = 0; try < 5; try++) {
And use only the retries in drm_dpcd_access?
Thanks
Khaled
>
> > > Anyways, this seems about the only thing we can do given the
> > > limited
> > > hw capabilities.
> > > Reviewed-by: Ville Syrjälä
> > >
> > > > Accordingly disable LTTPR detection until GLK, where the
> > > > maximum timeout
> > > > we can set is only 1.6ms.
> > > >
> > > > Link training in the non-transparent mode is known to fail at
> > > > least on
> > > > some SKL systems with a WD19 dock on the link, which exposes an
> > > > LTTPR
> > > > (see the References below). While this could have different
> > > > reasons
> > > > besides the too short AUX timeout used, not detecting LTTPRs
> > > > (and so not
> > > > using the non-transparent LT mode) fixes link training on these
> > > > systems.
> > > >
> > > > While at it add a code comment about the platform specific
> > > > maximum
> > > > timeout values.
> > > >
> > > > v2: Add a comment about the g4x maximum timeout as well.
> > > > (Ville)
> > > >
> > > > Reported-by: Takashi Iwai
> > > > Reported-and-tested-by: Santiago Zarate <
> > > > santiago.zar...@suse.com>
> > > > Reported-and-tested-by: Bodo Graumann
> > > > References:
> > > > https://gitlab.freedesktop.org/drm/intel/-/issues/3166
> > > > Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent
> > > > mode link training")
> > > > Cc: # v5.11
> > > > Cc: Takashi Iwai
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: Imre Deak
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++
> > > > .../gpu/drm/i915/display/intel_dp_link_training.c | 15
> > > > ---
> > > > 2 files changed, 19 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > index eaebf123310a..10fe17b7280d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > > @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct
> > > > intel_dp *intel_dp,
> > > > else
> > > > precharge = 5;
> > > >
> > > > + /* Max timeout value on G4x-BDW: 1.6ms */
> > > > if (IS_BROADWELL(dev_priv))
> > > > timeout = DP_AUX_CH_CTL_TIME_OUT_600us;
> > > > else
> > > > @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct
> > > > intel_dp *intel_dp,
> > > > enum phy phy = intel_port_to_phy(i915, dig_port-
> > > > >base.port);
> > > > u32 ret;
> > > >
> > > > + /*
> > > > +* Max timeout values:
> > > > +* SKL-GLK: 1.6ms
> > > > +* CNL: 3.2ms
> > > > +* ICL+: 4ms
> > > > +*/
> > > > ret = DP_AUX_CH_CTL_SEND_BUSY |
> > > > DP_AUX_CH_CTL_DONE |
> > > > DP_AUX_CH_CTL_INTERRUPT |
> > > > diff --git
> > > > a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > > index 19ba7c7cbaab..c0e25c75c105 100644
> > > > --- a/driv
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Not to try to re-enable PSR after being raised an irq aux error (rev2)
== Series Details == Series: drm/i915/display: Not to try to re-enable PSR after being raised an irq aux error (rev2) URL : https://patchwork.freedesktop.org/series/88072/ State : success == Summary == CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19808 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/index.html Known issues Here are the changes found in Patchwork_19808 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-kbl-8809g: [PASS][1] -> [TIMEOUT][2] ([i915#3145]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/fi-kbl-8809g/igt@gem_exec_gttf...@basic.html * igt@gem_linear_blits@basic: - fi-kbl-8809g: [PASS][3] -> [TIMEOUT][4] ([i915#2502] / [i915#3145]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-8809g/igt@gem_linear_bl...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/fi-kbl-8809g/igt@gem_linear_bl...@basic.html * igt@i915_selftest@live@blt: - fi-snb-2600:[PASS][5] -> [DMESG-FAIL][6] ([i915#1409]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-snb-2600/igt@i915_selftest@l...@blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/fi-snb-2600/igt@i915_selftest@l...@blt.html Possible fixes * igt@gem_wait@busy@all: - fi-bsw-nick:[FAIL][7] ([i915#3177]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-bsw-nick/igt@gem_wait@b...@all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/fi-bsw-nick/igt@gem_wait@b...@all.html [i915#1409]: https://gitlab.freedesktop.org/drm/intel/issues/1409 [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502 [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145 [i915#3177]: https://gitlab.freedesktop.org/drm/intel/issues/3177 Participating hosts (44 -> 40) -- Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9870 -> Patchwork_19808 CI-20190529: 20190529 CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19808: a05b1d62d8f30c41d918f7ff53d63f6da7f59622 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a05b1d62d8f3 drm/i915/display: Not to try to re-enable PSR after being raised an irq aux error == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19808/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length
Re-reported. -Original Message- From: Ville Syrjälä Sent: Thursday, March 18, 2021 1:53 PM To: intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length On Thu, Mar 18, 2021 at 08:09:43PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge > length > URL : https://patchwork.freedesktop.org/series/88132/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19807 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19807 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19807, 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_19807/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_19807: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live@execlists: > - fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-kbl-soraka > /igt@i915_selftest@l...@execlists.html <3> [1019.090846] i915 :00:02.0: [drm] *ERROR* AUX B/DDI B/PHY B: did not complete or timeout within 10ms (status 0xad4003ff) Unrelated to the patch since it doesn't touch the skl+ AUX code and this machine is a kbl. So seems to be just some random fail. > > > Known issues > > > Here are the changes found in Patchwork_19807 that come from known issues: > > ### IGT changes ### > > Issues hit > > * igt@core_hotunplug@unbind-rebind: > - fi-bwr-2160:[PASS][3] -> [FAIL][4] ([i915#3194]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-bwr-2160/i > gt@core_hotunp...@unbind-rebind.html > > > [i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194 > > > Participating hosts (44 -> 40) > -- > > Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u > > > Build changes > - > > * Linux: CI_DRM_9870 -> Patchwork_19807 > > CI-20190529: 20190529 > CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_19807: 89c9ce9bcfbf7286c2ec25ffaa26041909ec84d6 @ > git://anongit.freedesktop.org/gfx-ci/linux > > > == Linux commits == > > 89c9ce9bcfbf drm/i915: Remove stray newlines > 6b3f9e7ed7f6 drm/i915: Fix pre-skl DP AUX precharge length > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/index.html -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length
== Series Details == Series: series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length URL : https://patchwork.freedesktop.org/series/88132/ State : success == Summary == CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19807 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/index.html Known issues Here are the changes found in Patchwork_19807 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-bwr-2160:[PASS][1] -> [FAIL][2] ([i915#3194]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@execlists: - fi-kbl-soraka: [PASS][3] -> [DMESG-WARN][4] ([i915#3240]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html [i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194 [i915#3240]: https://gitlab.freedesktop.org/drm/intel/issues/3240 Participating hosts (44 -> 40) -- Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9870 -> Patchwork_19807 CI-20190529: 20190529 CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19807: 89c9ce9bcfbf7286c2ec25ffaa26041909ec84d6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 89c9ce9bcfbf drm/i915: Remove stray newlines 6b3f9e7ed7f6 drm/i915: Fix pre-skl DP AUX precharge length == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length
On Thu, Mar 18, 2021 at 08:09:43PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge > length > URL : https://patchwork.freedesktop.org/series/88132/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19807 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19807 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19807, 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_19807/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_19807: > > ### IGT changes ### > > Possible regressions > > * igt@i915_selftest@live@execlists: > - fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html <3> [1019.090846] i915 :00:02.0: [drm] *ERROR* AUX B/DDI B/PHY B: did not complete or timeout within 10ms (status 0xad4003ff) Unrelated to the patch since it doesn't touch the skl+ AUX code and this machine is a kbl. So seems to be just some random fail. > > > Known issues > > > Here are the changes found in Patchwork_19807 that come from known issues: > > ### IGT changes ### > > Issues hit > > * igt@core_hotunplug@unbind-rebind: > - fi-bwr-2160:[PASS][3] -> [FAIL][4] ([i915#3194]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html > > > [i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194 > > > Participating hosts (44 -> 40) > -- > > Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u > > > Build changes > - > > * Linux: CI_DRM_9870 -> Patchwork_19807 > > CI-20190529: 20190529 > CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @ > git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > Patchwork_19807: 89c9ce9bcfbf7286c2ec25ffaa26041909ec84d6 @ > git://anongit.freedesktop.org/gfx-ci/linux > > > == Linux commits == > > 89c9ce9bcfbf drm/i915: Remove stray newlines > 6b3f9e7ed7f6 drm/i915: Fix pre-skl DP AUX precharge length > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/index.html -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915/error: Fix typo "accesible"
Trivial fix. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Ricardo Ribalda --- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index f962693404b7..ea7d0398fb05 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -1503,7 +1503,7 @@ gt_record_uc(struct intel_gt_coredump *gt, memcpy(&error_uc->huc_fw, &uc->huc.fw, sizeof(uc->huc.fw)); /* Non-default firmware paths will be specified by the modparam. -* As modparams are generally accesible from the userspace make +* As modparams are generally accessible from the userspace make * explicit copies of the firmware paths. */ error_uc->guc_fw.path = kstrdup(uc->guc.fw.path, ALLOW_FAIL); -- 2.31.0.rc2.261.g7f71774620-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length
== Series Details == Series: series starting with [1/2] drm/i915: Fix pre-skl DP AUX precharge length URL : https://patchwork.freedesktop.org/series/88132/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19807 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19807 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19807, 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_19807/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19807: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_19807 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-bwr-2160:[PASS][3] -> [FAIL][4] ([i915#3194]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html [i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194 Participating hosts (44 -> 40) -- Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9870 -> Patchwork_19807 CI-20190529: 20190529 CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19807: 89c9ce9bcfbf7286c2ec25ffaa26041909ec84d6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 89c9ce9bcfbf drm/i915: Remove stray newlines 6b3f9e7ed7f6 drm/i915: Fix pre-skl DP AUX precharge length == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19807/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/display: move vbt check to intel_ddi_init()
On Tue, Feb 16, 2021 at 09:50:03PM +0200, Jani Nikula wrote:
On Mon, 15 Feb 2021, Lucas De Marchi wrote:
On Mon, Feb 15, 2021 at 12:35:50PM +0200, Jani Nikula wrote:
On Sat, 13 Feb 2021, Lucas De Marchi wrote:
On intel_ddi_init() we already check VBT if the port supports HDMI/DP
and bail out otherwise. Instad of checking if a single port is present
using VBT in intel_display.c, move the stronger check to
intel_ddi_init() and return early in case it's not supported. There
would be no way intel_bios_* would report support for hdmi/dp if the
port isn't present so this should cause no regressions for other
platforms.
Sorry, but this will regress machines that have no VBT.
I missed that init_vbt_missing_defaults() also sets
the supports_*.
I've been thinking about creating fake child devices for that case to
reduce the exceptions.
Adding a fake child would indeed be a good option. Are you going to
implement that soon or should I?
I'm working on it. Got a bit carried away with what I've had in mind for
ages regarding some other refactoring (e.g. getting rid of
i915->vbt.ddi_port_info[] altogether in order to bring pre- and post-ddi
platforms closer together). I'll try to get a smaller set ready first.
now that those patches are applied, can you take a look in these?
thanks
Lucas De Marchi
BR,
Jani.
thanks
Lucas De Marchi
BR,
Jani.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3b97c0091812..1235be0ba5d1 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3972,6 +3972,13 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
+ if (!intel_bios_is_port_present(dev_priv, port)) {
+ drm_dbg_kms(&dev_priv->drm,
+ "VBT says port %c is not present, respect it\n",
+ port_name(port));
+ return;
+ }
+
/*
* On platforms with HTI (aka HDPORT), if it's enabled at boot it may
* have taken over some of the PHYs and made them unavailable to the
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 23ec68498800..7aaf7a29d493 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11904,13 +11904,13 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
intel_ddi_init(dev_priv, PORT_C);
intel_ddi_init(dev_priv, PORT_D);
intel_ddi_init(dev_priv, PORT_E);
+
/*
-* On some ICL SKUs port F is not present. No strap bits for
-* this, so rely on VBT.
-* Work around broken VBTs on SKUs known to have no port F.
+* On some ICL SKUs port F is not present, but broken VBTs mark
+* the port as present. Only try to initialize port F for the
+* SKUs that may actually have it.
*/
- if (IS_ICL_WITH_PORT_F(dev_priv) &&
- intel_bios_is_port_present(dev_priv, PORT_F))
+ if (IS_ICL_WITH_PORT_F(dev_priv))
intel_ddi_init(dev_priv, PORT_F);
icl_dsi_init(dev_priv);
@@ -11964,10 +11964,8 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
/*
* On SKL we don't have a way to detect DDI-E so we rely on VBT.
*/
- if (IS_GEN9_BC(dev_priv) &&
- intel_bios_is_port_present(dev_priv, PORT_E))
+ if (IS_GEN9_BC(dev_priv))
intel_ddi_init(dev_priv, PORT_E);
-
} else if (HAS_PCH_SPLIT(dev_priv)) {
int found;
--
Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Default request/fence expiry + watchdog (rev3)
== Series Details ==
Series: Default request/fence expiry + watchdog (rev3)
URL : https://patchwork.freedesktop.org/series/87930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19806
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19806:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_parallel@engines@userptr:
- {fi-rkl-11500t}:[SKIP][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-rkl-11500t/igt@gem_exec_parallel@engi...@userptr.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/fi-rkl-11500t/igt@gem_exec_parallel@engi...@userptr.html
Known issues
Here are the changes found in Patchwork_19806 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_linear_blits@basic:
- fi-kbl-8809g: [PASS][3] -> [TIMEOUT][4] ([i915#2502] / [i915#3145])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
* igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g: [PASS][5] -> [TIMEOUT][6] ([i915#3145])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
[i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
Participating hosts (44 -> 40)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* IGT: IGT_6036 -> IGTPW_5624
* Linux: CI_DRM_9870 -> Patchwork_19806
CI-20190529: 20190529
CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_5624: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5624/index.html
IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19806: e814cfb2632dac33e0252fc578ca840503e63799 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e814cfb2632d drm/i915: Allow configuring default request expiry via modparam
b3ae72befaf0 drm/i915: Fail too long user submissions by default
ab49cf00b55d drm/i915: Request watchdog infrastructure
7fa9b24cf91f drm/i915: Handle async cancellation in sentinel assert
80086346fcaf drm/i915: Restrict sentinel requests further
d8733af339ce drm/i915: Individual request cancellation
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19806/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
On 3/18/2021 3:16 AM, Daniel Vetter wrote: > On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote: >> >> >> On 2/11/2021 7:34 AM, Daniel Vetter wrote: >>> On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote: On 2/9/2021 2:54 AM, Daniel Vetter wrote: > On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote: >> This patch adds tracking of which cgroup to make charges against for a >> given GEM object. We associate the current task's cgroup with GEM >> objects >> as they are created. First user of this is for charging DRM cgroup for >> device memory allocations. The intended behavior is for device drivers >> to >> make the cgroup charging calls at the time that backing store is >> allocated >> or deallocated for the object. >> >> Exported functions are provided for charging memory allocations for a >> GEM object to DRM cgroup. To aid in debugging, we store how many bytes >> have been charged inside the GEM object. Add helpers for setting and >> clearing the object's associated cgroup which will check that charges are >> not being leaked. >> >> For shared objects, this may make the charge against a cgroup that is >> potentially not the same cgroup as the process using the memory. Based >> on the memory cgroup's discussion of "memory ownership", this seems >> acceptable [1]. >> >> [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory >> Ownership" >> >> Signed-off-by: Brian Welty > > Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that > counts everything, why don't we also charge in these gem functions? I'm not sure what you mean exactly. You want to merge/move the charging logic proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into drm_gem_object_charge_mem() ? Or reading below, I think you are okay keeping the logic separated as is, but you want much of the code in kernel/cgroup/drm.c moved to drivers/gpu/cgroup ? Yes, I see that should allow to reduce number of exported functions. >>> >>> Both. I mean we'd need to look at the code again when it's shuffled, but >>> I'd say: >>> >>> - cgroup code and the charging for general gpu memory moves to >>> drivers/gpu/cgroup, so dma-buf heaps can use it too. >>> >>> - the charging for gem buffers moves into core gem code, so it happens for >>> all gpu drivers and all gem buffer allocations. >> >> Daniel, I'm not sure we're in sync on what 'charging for general gpu memory' >> means. Thus far, I have been proposing to charge/uncharge when backing >> store is >> allocated/freed. And thus, this would be done in DRM driver (so then also in >> the dma-buf exporter). >> I can't see how we'd hoist this part into drm gem code. >> The memory limit in this series is for VRAM usage/limit not GEM buffers... > > Yes this would be at gem buffer creation time. And just to get cgroups > for drm up&running. Okay, but it's not of the ones in Tejun's list to start with: https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html I hoped we would start by pursuing those (gpu.weight and gpu.memory.high) as first step. Limiting GEM buffers is essentially controlling virtual memory size, which tend to just always get set to unlimited. Would be nice to get consensus from maintainers before proceeding to implement this. > >> Unless you are talking about charging for GEM buffer creation? But this is >> more of a 'soft resource' more along lines of Kenny's earlier GEM buffer >> limit >> control. >> I raised issue with this then, and at the time, Tejun agreed we should keep >> to >> 'hard resource' controls, see [1] and [2]. >> >> [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/218071.html >> [2] https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html >> >>> >>> - this might or might not mean a bunch less exported stuff from the >>> cgroups files (since you don't need separate steps for linking a gem >>> object to a cgroup from the actual charging), and probably no exports >>> anymore for drivers (since they charge nothing). That will change >>> when we add charging for specific memory pools I guess, but we add that >>> when we add tha functionality. >> >> ... so considering VRAM charging, then yes, we very much need to have >> exported >> functions for drivers to do the charging. >> But these can be exported from drm.ko (or new .ko?) instead of kernel. Is >> that still preference? Also, if number of exported functions is concern, we >> can replace some of it with use of function pointers. > > So the reason I suggested we drop all this is because we won't charge > in drivers, we'll charge in ttm buffer management code. Which we'll > adopt for dg1 in upstream. But it will take some time. Okay, thanks for clarifying. I'm not familiar with where try_charge/uncharge
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Default request/fence expiry + watchdog (rev3)
== Series Details == Series: Default request/fence expiry + watchdog (rev3) URL : https://patchwork.freedesktop.org/series/87930/ State : warning == Summary == $ dim checkpatch origin/drm-tip d8733af339ce drm/i915: Individual request cancellation 80086346fcaf drm/i915: Restrict sentinel requests further 7fa9b24cf91f drm/i915: Handle async cancellation in sentinel assert ab49cf00b55d drm/i915: Request watchdog infrastructure b3ae72befaf0 drm/i915: Fail too long user submissions by default -:18: WARNING:TYPO_SPELLING: 'becuase' may be misspelled - perhaps 'because'? #18: And becuase of lack of agreement on usefulness and safety of fence error ^^^ total: 0 errors, 1 warnings, 0 checks, 102 lines checked e814cfb2632d drm/i915: Allow configuring default request expiry via modparam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
== Series Details == Series: drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT URL : https://patchwork.freedesktop.org/series/88128/ State : success == Summary == CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19805 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/index.html Known issues Here are the changes found in Patchwork_19805 that come from known issues: ### IGT changes ### Issues hit * igt@gem_linear_blits@basic: - fi-kbl-8809g: [PASS][1] -> [TIMEOUT][2] ([i915#2502] / [i915#3145]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-8809g/igt@gem_linear_bl...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/fi-kbl-8809g/igt@gem_linear_bl...@basic.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#2203]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502 [i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145 Participating hosts (44 -> 40) -- Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9870 -> Patchwork_19805 CI-20190529: 20190529 CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19805: 41a38a09cd25d9afbfb6247484dedf0efd9234d8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 41a38a09cd25 drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19805/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Shuffle DP code around (rev2)
== Series Details ==
Series: drm/i915: Shuffle DP code around (rev2)
URL : https://patchwork.freedesktop.org/series/85878/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9870 -> Patchwork_19804
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/index.html
Known issues
Here are the changes found in Patchwork_19804 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_linear_blits@basic:
- fi-kbl-8809g: [PASS][1] -> [TIMEOUT][2] ([i915#2502] / [i915#3145])
+1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/fi-kbl-8809g/igt@gem_linear_bl...@basic.html
* igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g: [PASS][3] -> [TIMEOUT][4] ([i915#3145])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/fi-kbl-8809g/igt@gem_tiled_fence_bl...@basic.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6] ([i915#2940])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9870/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][7] ([i915#1436])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/fi-bsw-nick/igt@run...@aborted.html
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
Participating hosts (44 -> 40)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_9870 -> Patchwork_19804
CI-20190529: 20190529
CI_DRM_9870: a9a5ed8d2432e5335e6c26118cefb2cfff28ae37 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6036: 5b535494abcdf5ce2b9be99b7bb5df8ab4733083 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19804: d486c1851a6e55ed332635f4a70fdb78b7bf7bdf @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d486c1851a6e drm/i915: Give g4x_{dp, hdmi}.c g4x_ namespace
b38592cfbe51 drm/i915: Introduce g4x_hdmi.c
0e432233fba9 drm/i915: Introduce g4x_dp.c
9b0d464b0d6a drm/i915: Split intel_ddi_encoder_reset() from
intel_dp_encoder_reset()
8e555cecf0d9 drm/i915: Relocate intel_dp_program_link_training_pattern()
0990a9e29ec5 drm/i915: Remove dead signal level debugs
d6b23f62e26b drm/i915: Remove dead TPS3->TPS2 fallback code
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19804/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: A typo fix
On 3/18/21 3:19 AM, Bhaskar Chowdhury wrote: > > s/bariers/barriers/ > > Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap > --- > drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c > b/drivers/gpu/drm/i915/gt/intel_timeline.c > index 037b0e3ccbed..25fc7f44fee0 100644 > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c > @@ -435,7 +435,7 @@ void intel_timeline_exit(struct intel_timeline *tl) > spin_unlock(&timelines->lock); > > /* > - * Since this timeline is idle, all bariers upon which we were waiting > + * Since this timeline is idle, all barriers upon which we were waiting >* must also be complete and so we can discard the last used barriers >* without loss of information. >*/ > -- > 2.26.2 > -- ~Randy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Remove stray newlines
From: Ville Syrjälä
A bunch of files have a stray newline at the end. Remove it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 1 -
drivers/gpu/drm/i915/display/skl_universal_plane.c | 1 -
drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c | 1 -
drivers/gpu/drm/i915/i915_params.h | 1 -
drivers/gpu/drm/i915/i915_vma_types.h | 1 -
5 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 8a52beaed2da..7391cd195d41 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -1038,4 +1038,3 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
plane_config->fb = intel_fb;
}
-
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 1f335cb09149..a06c474223c1 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -2263,4 +2263,3 @@ skl_get_initial_plane_config(struct intel_crtc *crtc,
error:
kfree(intel_fb);
}
-
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
index 129e0cf7dfe2..64e0b86bf258 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log_debugfs.c
@@ -121,4 +121,3 @@ void intel_guc_log_debugfs_register(struct intel_guc_log
*log,
intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), log);
}
-
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 48f47e44e848..18bbc92b642d 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -96,4 +96,3 @@ void i915_params_copy(struct i915_params *dest, const struct
i915_params *src);
void i915_params_free(struct i915_params *params);
#endif
-
diff --git a/drivers/gpu/drm/i915/i915_vma_types.h
b/drivers/gpu/drm/i915/i915_vma_types.h
index f5cb848b7a7e..c7614fbabb9c 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -282,4 +282,3 @@ struct i915_vma {
};
#endif
-
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Fix pre-skl DP AUX precharge length
From: Ville Syrjälä DP v1.1+ says: "The DisplayPort transmitter, which is the driving end for a request transaction, pre-charges the AUX-CH+ and AUX-CH- to a common mode voltage by transmitting 10 to 16 consecutive 0’s in Manchester II code. After the active pre-charge, the transmitter sends an AUX Sync pattern. The AUX Sync pattern must be as follows: Start with 16 consecutive 0s in Manchester-II code, which results in a transition from low to high in the middle of each bit period. Including active pre-charge pulses, there shall be 26 to 32 consecutive 0s before the end of the AUX_SYNC pattern." BDW bspec says: "Used to determine the precharge time for the Aux Channel. During this time the Aux Channel will drive the SYNC pattern. Every microsecond gives one additional SYNC pulse beyond the hard coded 26 SYNC pulses. The value is the number of microseconds times 2. Default is 3 decimal which gives 6us of precharge which is 6 extra SYN pulses for a total of 32." CPT bspec says the same thing apart from: "... Default is 5 decimal which gives 10us of precharge which is 10 extra SYNC pulses for a total of 36." So it looks like to match the max of 32 of the DP spec we should just always program this extra precharge time to 3. Unfortunately g4x/ibx bspec doesn't have this clarification, but since the cpt default was still the same 5 as for g4x/ibx let's assume the behaviour was always the same. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp_aux.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c b/drivers/gpu/drm/i915/display/intel_dp_aux.c index eaebf123310a..d5443d6d6123 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c @@ -126,12 +126,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); - u32 precharge, timeout; - - if (IS_GEN(dev_priv, 6)) - precharge = 3; - else - precharge = 5; + u32 timeout; if (IS_BROADWELL(dev_priv)) timeout = DP_AUX_CH_CTL_TIME_OUT_600us; @@ -145,7 +140,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp, timeout | DP_AUX_CH_CTL_RECEIVE_ERROR | (send_bytes << DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT) | - (precharge << DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) | + (3 << DP_AUX_CH_CTL_PRECHARGE_2US_SHIFT) | (aux_clock_divider << DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT); } -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Disable LTTPR support when the LTTPR rev < 1.4
On Thu, Mar 18, 2021 at 08:00:10PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 17, 2021 at 08:49:01PM +0200, Imre Deak wrote:
> > By the specification the 0xF - 0xF02FF range is only valid if the
> > LTTPR revision at 0xF is at least 1.4. Disable the LTTPR support
> > otherwise.
> >
> > Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link
> > training")
> > Cc: # v5.11
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > .../gpu/drm/i915/display/intel_dp_link_training.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index d8d90903226f..d92eb192c89d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -100,17 +100,23 @@ static bool intel_dp_read_lttpr_common_caps(struct
> > intel_dp *intel_dp)
> > return false;
> >
> > if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> > - intel_dp->lttpr_common_caps) < 0) {
> > - intel_dp_reset_lttpr_common_caps(intel_dp);
> > - return false;
> > - }
> > + intel_dp->lttpr_common_caps) < 0)
> > + goto reset_caps;
>
> BTW just noticed this oddball thing in the spec:
> "DPTX shall read specific registers within the LTTPR field (DPCD
> Addresses Fh through F0004h; see Table 2-198) to determine
> whether any LTTPR(s) are present and if so, how many. This read
> shall be in the form of a 5-byte native AUX Read transaction."
>
> Why exactly 5 bytes? I have no idea. Doesn't really make sense.
> Just wondering if we really need to respect that and some LTTPRs
> would fsck things up if we read more...
I pointed this out to spec people and the new version (2.1) will require
this to be 8 bytes. But yes, I do hope no existing ones depend on this
being 5 bytes.
> Anyways
> Reviewed-by: Ville Syrjälä
>
> >
> > drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> > "LTTPR common capabilities: %*ph\n",
> > (int)sizeof(intel_dp->lttpr_common_caps),
> > intel_dp->lttpr_common_caps);
> >
> > + /* The minimum value of
> > LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV is 1.4 */
> > + if (intel_dp->lttpr_common_caps[0] < 0x14)
> > + goto reset_caps;
> > +
> > return true;
> > +
> > +reset_caps:
> > + intel_dp_reset_lttpr_common_caps(intel_dp);
> > + return false;
> > }
> >
> > static bool
> > --
> > 2.25.1
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs
On Thu, Mar 18, 2021 at 07:49:13PM +0200, Imre Deak wrote:
> On Thu, Mar 18, 2021 at 07:33:20PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 17, 2021 at 08:48:59PM +0200, Imre Deak wrote:
> > > The spec requires to use at least 3.2ms for the AUX timeout period if
> > > there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming
> > > spec update makes this more specific, by requiring a 3.2ms minimum
> > > timeout period for the LTTPR detection reading the 0xF-0xF0007
> > > range (3.6.5.1).
> >
> > I'm pondering if we could reduce the timeout after having determined
> > wherther LTTPRs are present or not? But maybe that wouldn't really speed
> > up anything since we can't reduce the timeout until after detecting
> > *something*. And once there is something there we shouldn't really get
> > any more timeouts I guess. So probably a totally stupid idea.
>
> Right, if something is connected it would take anyway as much time as it
> takes for the sink to reply whether or not we decreased the timeout.
>
> However if nothing is connected, we have the excessive timeout Khaled
> already noticed (160 * 4ms = 6.4 sec on ICL+). I think to improve that
> we could scale the total number of retries by making it
> total_timeout/platform_specific_timeout (letting total_timeout=2sec for
> instance) or just changing the drm retry logic to be time based instead
> of the number of retries we use atm.
Doh, reducing simply the HW timeouts would be enough to fix this.
> > Anyways, this seems about the only thing we can do given the limited
> > hw capabilities.
> > Reviewed-by: Ville Syrjälä
> >
> > > Accordingly disable LTTPR detection until GLK, where the maximum timeout
> > > we can set is only 1.6ms.
> > >
> > > Link training in the non-transparent mode is known to fail at least on
> > > some SKL systems with a WD19 dock on the link, which exposes an LTTPR
> > > (see the References below). While this could have different reasons
> > > besides the too short AUX timeout used, not detecting LTTPRs (and so not
> > > using the non-transparent LT mode) fixes link training on these systems.
> > >
> > > While at it add a code comment about the platform specific maximum
> > > timeout values.
> > >
> > > v2: Add a comment about the g4x maximum timeout as well. (Ville)
> > >
> > > Reported-by: Takashi Iwai
> > > Reported-and-tested-by: Santiago Zarate
> > > Reported-and-tested-by: Bodo Graumann
> > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
> > > Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
> > > training")
> > > Cc: # v5.11
> > > Cc: Takashi Iwai
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++
> > > .../gpu/drm/i915/display/intel_dp_link_training.c | 15 ---
> > > 2 files changed, 19 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > index eaebf123310a..10fe17b7280d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > > @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp
> > > *intel_dp,
> > > else
> > > precharge = 5;
> > >
> > > + /* Max timeout value on G4x-BDW: 1.6ms */
> > > if (IS_BROADWELL(dev_priv))
> > > timeout = DP_AUX_CH_CTL_TIME_OUT_600us;
> > > else
> > > @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp
> > > *intel_dp,
> > > enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> > > u32 ret;
> > >
> > > + /*
> > > + * Max timeout values:
> > > + * SKL-GLK: 1.6ms
> > > + * CNL: 3.2ms
> > > + * ICL+: 4ms
> > > + */
> > > ret = DP_AUX_CH_CTL_SEND_BUSY |
> > > DP_AUX_CH_CTL_DONE |
> > > DP_AUX_CH_CTL_INTERRUPT |
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > index 19ba7c7cbaab..c0e25c75c105 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > > @@ -82,6 +82,18 @@ static void intel_dp_read_lttpr_phy_caps(struct
> > > intel_dp *intel_dp,
> > >
> > > static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
> > > {
> > > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > +
> > > + if (intel_dp_is_edp(intel_dp))
> > > + return false;
> > > +
> > > + /*
> > > + * Detecting LTTPRs must be avoided on platforms with an AUX timeout
> > > + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> > > + */
> > > + if (INTEL_GEN(i915) < 10)
> > > + return false;
> > > +
> > > if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> > > intel_dp->lttpr_common_caps) < 0) {
> > > memset(intel_dp->lttpr_common
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Disable LTTPR support when the DPCD rev < 1.4
On Thu, Mar 18, 2021 at 07:57:22PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 17, 2021 at 09:01:49PM +0200, Imre Deak wrote:
> > By the specification the 0xF-0xF02FF range is only valid when the
> > DPCD revision is 1.4 or higher. Disable LTTPR support if this isn't so.
> >
> > Trying to detect LTTPRs returned corrupted values for the above DPCD
> > range at least on a Skylake host with an LG 43UD79-B monitor with a DPCD
> > revision 1.2 connected.
> >
> > v2: Add the actual version check.
> >
> > Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link
> > training")
> > Cc: # v5.11
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> > .../drm/i915/display/intel_dp_link_training.c | 48 ++-
> > .../drm/i915/display/intel_dp_link_training.h | 2 +-
> > 3 files changed, 39 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index b6b5776f5a66..873684da0cd4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -3711,9 +3711,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > {
> > int ret;
> >
> > - intel_dp_lttpr_init(intel_dp);
> > -
> > - if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd))
> > + if (intel_dp_init_lttpr_and_dprx_caps(intel_dp) < 0)
> > return false;
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index c0e25c75c105..5a821d644e9c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -35,6 +35,11 @@ intel_dp_dump_link_status(struct drm_device *drm,
> > link_status[3], link_status[4], link_status[5]);
> > }
> >
> > +static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
> > +{
> > + memset(&intel_dp->lttpr_common_caps, 0,
> > sizeof(intel_dp->lttpr_common_caps));
> > +}
> > +
> > static void intel_dp_reset_lttpr_count(struct intel_dp *intel_dp)
> > {
> > intel_dp->lttpr_common_caps[DP_PHY_REPEATER_CNT -
> > @@ -96,8 +101,7 @@ static bool intel_dp_read_lttpr_common_caps(struct
> > intel_dp *intel_dp)
> >
> > if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> > intel_dp->lttpr_common_caps) < 0) {
> > - memset(intel_dp->lttpr_common_caps, 0,
> > - sizeof(intel_dp->lttpr_common_caps));
> > + intel_dp_reset_lttpr_common_caps(intel_dp);
> > return false;
> > }
> >
> > @@ -119,30 +123,49 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp
> > *intel_dp, bool enable)
> > }
> >
> > /**
> > - * intel_dp_lttpr_init - detect LTTPRs and init the LTTPR link training
> > mode
> > + * intel_dp_init_lttpr_and_dprx_caps - detect LTTPR and DPRX caps, init
> > the LTTPR link training mode
> > * @intel_dp: Intel DP struct
> > *
> > - * Read the LTTPR common capabilities, switch to non-transparent link
> > training
> > - * mode if any is detected and read the PHY capabilities for all detected
> > - * LTTPRs. In case of an LTTPR detection error or if the number of
> > + * Read the LTTPR common and DPRX capabilities and switch to
> > non-transparent
> > + * link training mode if any is detected and read the PHY capabilities for
> > all
> > + * detected LTTPRs. In case of an LTTPR detection error or if the number of
> > * LTTPRs is more than is supported (8), fall back to the no-LTTPR,
> > * transparent mode link training mode.
> > *
> > * Returns:
> > - * >0 if LTTPRs were detected and the non-transparent LT mode was set
> > + * >0 if LTTPRs were detected and the non-transparent LT mode was set.
> > The
> > + * DPRX capabilities are read out.
> > *0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
> > - * detection failure and the transparent LT mode was set
> > + * detection failure and the transparent LT mode was set. The DPRX
> > + * capabilities are read out.
> > + * <0 Reading out the DPRX capabilities failed.
> > */
> > -int intel_dp_lttpr_init(struct intel_dp *intel_dp)
> > +int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> > {
> > int lttpr_count;
> > bool ret;
> > int i;
> >
> > ret = intel_dp_read_lttpr_common_caps(intel_dp);
> > +
> > + /* The DPTX shall read the DRPX caps after LTTPR detection. */
> > + if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd)) {
> > + intel_dp_reset_lttpr_common_caps(intel_dp);
> > + return -EIO;
> > + }
> > +
> > if (!ret)
> > return 0;
> >
> > + /*
> > +* The 0xF-0xF02FF range is only valid if the DPCD revision is
> > +* at least 1.4.
> > +*/
> > + if (intel_dp->dpc
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Shuffle DP code around (rev2)
== Series Details == Series: drm/i915: Shuffle DP code around (rev2) URL : https://patchwork.freedesktop.org/series/85878/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Shuffle DP code around (rev2)
== Series Details ==
Series: drm/i915: Shuffle DP code around (rev2)
URL : https://patchwork.freedesktop.org/series/85878/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d6b23f62e26b drm/i915: Remove dead TPS3->TPS2 fallback code
0990a9e29ec5 drm/i915: Remove dead signal level debugs
8e555cecf0d9 drm/i915: Relocate intel_dp_program_link_training_pattern()
9b0d464b0d6a drm/i915: Split intel_ddi_encoder_reset() from
intel_dp_encoder_reset()
0e432233fba9 drm/i915: Introduce g4x_dp.c
-:33: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#33:
new file mode 100644
-:231: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#231: FILE: drivers/gpu/drm/i915/display/g4x_dp.c:194:
+}
+#define assert_dp_port_disabled(d) assert_dp_port((d), false)
-:241: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#241: FILE: drivers/gpu/drm/i915/display/g4x_dp.c:204:
+}
+#define assert_edp_pll_enabled(d) assert_edp_pll((d), true)
-:266: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#266: FILE: drivers/gpu/drm/i915/display/g4x_dp.c:229:
+ udelay(500);
-:281: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#281: FILE: drivers/gpu/drm/i915/display/g4x_dp.c:244:
+ udelay(200);
-:300: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#300: FILE: drivers/gpu/drm/i915/display/g4x_dp.c:263:
+ udelay(200);
-:2896: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#2896: FILE: drivers/gpu/drm/i915/display/intel_dp.c:2318:
+
DP_DS_HDMI_BT2020_RGB_YCBCR_CONV);
-:2928: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#2928: FILE: drivers/gpu/drm/i915/display/intel_dp.c:2340:
+ drm_dbg_kms(&i915->drm,
+ "Failed to set protocol converter RGB->YCbCr
conversion mode to %s\n",
-:2932: CHECK:LINE_SPACING: Please don't use multiple blank lines
#2932: FILE: drivers/gpu/drm/i915/display/intel_dp.c:2344:
+
total: 0 errors, 2 warnings, 7 checks, 3238 lines checked
b38592cfbe51 drm/i915: Introduce g4x_hdmi.c
-:33: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#33:
new file mode 100644
-:299: WARNING:LONG_LINE: line length of 115 exceeds 100 columns
#299: FILE: drivers/gpu/drm/i915/display/g4x_hdmi.c:262:
+ intel_de_read(dev_priv, TRANS_CHICKEN1(pipe)) |
TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
-:316: WARNING:LONG_LINE: line length of 116 exceeds 100 columns
#316: FILE: drivers/gpu/drm/i915/display/g4x_hdmi.c:279:
+ intel_de_read(dev_priv, TRANS_CHICKEN1(pipe)) &
~TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
total: 0 errors, 3 warnings, 0 checks, 1341 lines checked
d486c1851a6e drm/i915: Give g4x_{dp, hdmi}.c g4x_ namespace
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Disable LTTPR support when the LTTPR rev < 1.4
On Wed, Mar 17, 2021 at 08:49:01PM +0200, Imre Deak wrote:
> By the specification the 0xF - 0xF02FF range is only valid if the
> LTTPR revision at 0xF is at least 1.4. Disable the LTTPR support
> otherwise.
>
> Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link
> training")
> Cc: # v5.11
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> .../gpu/drm/i915/display/intel_dp_link_training.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index d8d90903226f..d92eb192c89d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -100,17 +100,23 @@ static bool intel_dp_read_lttpr_common_caps(struct
> intel_dp *intel_dp)
> return false;
>
> if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> - intel_dp->lttpr_common_caps) < 0) {
> - intel_dp_reset_lttpr_common_caps(intel_dp);
> - return false;
> - }
> + intel_dp->lttpr_common_caps) < 0)
> + goto reset_caps;
BTW just noticed this oddball thing in the spec:
"DPTX shall read specific registers within the LTTPR field (DPCD
Addresses Fh through F0004h; see Table 2-198) to determine
whether any LTTPR(s) are present and if so, how many. This read
shall be in the form of a 5-byte native AUX Read transaction."
Why exactly 5 bytes? I have no idea. Doesn't really make sense.
Just wondering if we really need to respect that and some LTTPRs
would fsck things up if we read more...
Anyways
Reviewed-by: Ville Syrjälä
>
> drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
> "LTTPR common capabilities: %*ph\n",
> (int)sizeof(intel_dp->lttpr_common_caps),
> intel_dp->lttpr_common_caps);
>
> + /* The minimum value of
> LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV is 1.4 */
> + if (intel_dp->lttpr_common_caps[0] < 0x14)
> + goto reset_caps;
> +
> return true;
> +
> +reset_caps:
> + intel_dp_reset_lttpr_common_caps(intel_dp);
> + return false;
> }
>
> static bool
> --
> 2.25.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Disable LTTPR support when the DPCD rev < 1.4
On Wed, Mar 17, 2021 at 09:01:49PM +0200, Imre Deak wrote:
> By the specification the 0xF-0xF02FF range is only valid when the
> DPCD revision is 1.4 or higher. Disable LTTPR support if this isn't so.
>
> Trying to detect LTTPRs returned corrupted values for the above DPCD
> range at least on a Skylake host with an LG 43UD79-B monitor with a DPCD
> revision 1.2 connected.
>
> v2: Add the actual version check.
>
> Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link
> training")
> Cc: # v5.11
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
> .../drm/i915/display/intel_dp_link_training.c | 48 ++-
> .../drm/i915/display/intel_dp_link_training.h | 2 +-
> 3 files changed, 39 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index b6b5776f5a66..873684da0cd4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3711,9 +3711,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> {
> int ret;
>
> - intel_dp_lttpr_init(intel_dp);
> -
> - if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd))
> + if (intel_dp_init_lttpr_and_dprx_caps(intel_dp) < 0)
> return false;
>
> /*
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index c0e25c75c105..5a821d644e9c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -35,6 +35,11 @@ intel_dp_dump_link_status(struct drm_device *drm,
> link_status[3], link_status[4], link_status[5]);
> }
>
> +static void intel_dp_reset_lttpr_common_caps(struct intel_dp *intel_dp)
> +{
> + memset(&intel_dp->lttpr_common_caps, 0,
> sizeof(intel_dp->lttpr_common_caps));
> +}
> +
> static void intel_dp_reset_lttpr_count(struct intel_dp *intel_dp)
> {
> intel_dp->lttpr_common_caps[DP_PHY_REPEATER_CNT -
> @@ -96,8 +101,7 @@ static bool intel_dp_read_lttpr_common_caps(struct
> intel_dp *intel_dp)
>
> if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> intel_dp->lttpr_common_caps) < 0) {
> - memset(intel_dp->lttpr_common_caps, 0,
> -sizeof(intel_dp->lttpr_common_caps));
> + intel_dp_reset_lttpr_common_caps(intel_dp);
> return false;
> }
>
> @@ -119,30 +123,49 @@ intel_dp_set_lttpr_transparent_mode(struct intel_dp
> *intel_dp, bool enable)
> }
>
> /**
> - * intel_dp_lttpr_init - detect LTTPRs and init the LTTPR link training mode
> + * intel_dp_init_lttpr_and_dprx_caps - detect LTTPR and DPRX caps, init the
> LTTPR link training mode
> * @intel_dp: Intel DP struct
> *
> - * Read the LTTPR common capabilities, switch to non-transparent link
> training
> - * mode if any is detected and read the PHY capabilities for all detected
> - * LTTPRs. In case of an LTTPR detection error or if the number of
> + * Read the LTTPR common and DPRX capabilities and switch to non-transparent
> + * link training mode if any is detected and read the PHY capabilities for
> all
> + * detected LTTPRs. In case of an LTTPR detection error or if the number of
> * LTTPRs is more than is supported (8), fall back to the no-LTTPR,
> * transparent mode link training mode.
> *
> * Returns:
> - * >0 if LTTPRs were detected and the non-transparent LT mode was set
> + * >0 if LTTPRs were detected and the non-transparent LT mode was set. The
> + * DPRX capabilities are read out.
> *0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
> - * detection failure and the transparent LT mode was set
> + * detection failure and the transparent LT mode was set. The DPRX
> + * capabilities are read out.
> + * <0 Reading out the DPRX capabilities failed.
> */
> -int intel_dp_lttpr_init(struct intel_dp *intel_dp)
> +int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> {
> int lttpr_count;
> bool ret;
> int i;
>
> ret = intel_dp_read_lttpr_common_caps(intel_dp);
> +
> + /* The DPTX shall read the DRPX caps after LTTPR detection. */
> + if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd)) {
> + intel_dp_reset_lttpr_common_caps(intel_dp);
> + return -EIO;
> + }
> +
> if (!ret)
> return 0;
>
> + /*
> + * The 0xF-0xF02FF range is only valid if the DPCD revision is
> + * at least 1.4.
> + */
> + if (intel_dp->dpcd[DP_DPCD_REV] < 0x14) {
> + intel_dp_reset_lttpr_common_caps(intel_dp);
> + return 0;
> + }
Slight chicken vs. egg I guess. Seems ok
Reviewed-by: Ville Syrjälä
> +
> lttpr_count = drm_dp_lttpr_count(intel_dp->lttpr_
Re: [Intel-gfx] [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Actually-NAK this. I just realized I've been misreading the bug and that this
doesn't actually seem to be fixed. Will resend once I figure out what's going on
On Thu, 2021-03-18 at 13:02 -0400, Lyude Paul wrote:
> Looks like that there actually are another subset of laptops on the market
> that don't support the Intel HDR backlight interface, but do advertise
> support for the VESA DPCD backlight interface despite the fact it doesn't
> seem to work.
>
> Note though I'm not entirely clear on this - on one of the machines where
> this issue was observed, I also noticed that we appeared to be rejecting
> the VBT defined backlight frequency in
> intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
>
> /* Use highest possible value of Pn for more granularity of brightness
> * adjustment while satifying the conditions below.
> * ...
> * - FxP is within 25% of desired value.
> * Note: 25% is arbitrary value and may need some tweak.
> */
>
> So it's possible that this value might just need to be tweaked, but for now
> let's just disable the VESA backlight interface unless it's specified in
> the VBT just to be safe. We might be able to try enabling this again by
> default in the future.
>
> Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
> enable_dpcd_backlight")
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 651884390137..4f8337c7fd2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *connector)
> break;
> case INTEL_BACKLIGHT_DISPLAY_DDI:
> try_intel_interface = true;
> - try_vesa_interface = true;
> break;
> default:
> return -ENODEV;
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs
On Thu, Mar 18, 2021 at 07:33:20PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 17, 2021 at 08:48:59PM +0200, Imre Deak wrote:
> > The spec requires to use at least 3.2ms for the AUX timeout period if
> > there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming
> > spec update makes this more specific, by requiring a 3.2ms minimum
> > timeout period for the LTTPR detection reading the 0xF-0xF0007
> > range (3.6.5.1).
>
> I'm pondering if we could reduce the timeout after having determined
> wherther LTTPRs are present or not? But maybe that wouldn't really speed
> up anything since we can't reduce the timeout until after detecting
> *something*. And once there is something there we shouldn't really get
> any more timeouts I guess. So probably a totally stupid idea.
Right, if something is connected it would take anyway as much time as it
takes for the sink to reply whether or not we decreased the timeout.
However if nothing is connected, we have the excessive timeout Khaled
already noticed (160 * 4ms = 6.4 sec on ICL+). I think to improve that
we could scale the total number of retries by making it
total_timeout/platform_specific_timeout (letting total_timeout=2sec for
instance) or just changing the drm retry logic to be time based instead
of the number of retries we use atm.
> Anyways, this seems about the only thing we can do given the limited
> hw capabilities.
> Reviewed-by: Ville Syrjälä
>
> > Accordingly disable LTTPR detection until GLK, where the maximum timeout
> > we can set is only 1.6ms.
> >
> > Link training in the non-transparent mode is known to fail at least on
> > some SKL systems with a WD19 dock on the link, which exposes an LTTPR
> > (see the References below). While this could have different reasons
> > besides the too short AUX timeout used, not detecting LTTPRs (and so not
> > using the non-transparent LT mode) fixes link training on these systems.
> >
> > While at it add a code comment about the platform specific maximum
> > timeout values.
> >
> > v2: Add a comment about the g4x maximum timeout as well. (Ville)
> >
> > Reported-by: Takashi Iwai
> > Reported-and-tested-by: Santiago Zarate
> > Reported-and-tested-by: Bodo Graumann
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
> > Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
> > training")
> > Cc: # v5.11
> > Cc: Takashi Iwai
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++
> > .../gpu/drm/i915/display/intel_dp_link_training.c | 15 ---
> > 2 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > index eaebf123310a..10fe17b7280d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> > @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp
> > *intel_dp,
> > else
> > precharge = 5;
> >
> > + /* Max timeout value on G4x-BDW: 1.6ms */
> > if (IS_BROADWELL(dev_priv))
> > timeout = DP_AUX_CH_CTL_TIME_OUT_600us;
> > else
> > @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp
> > *intel_dp,
> > enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> > u32 ret;
> >
> > + /*
> > +* Max timeout values:
> > +* SKL-GLK: 1.6ms
> > +* CNL: 3.2ms
> > +* ICL+: 4ms
> > +*/
> > ret = DP_AUX_CH_CTL_SEND_BUSY |
> > DP_AUX_CH_CTL_DONE |
> > DP_AUX_CH_CTL_INTERRUPT |
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 19ba7c7cbaab..c0e25c75c105 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -82,6 +82,18 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp
> > *intel_dp,
> >
> > static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
> > {
> > + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > +
> > + if (intel_dp_is_edp(intel_dp))
> > + return false;
> > +
> > + /*
> > +* Detecting LTTPRs must be avoided on platforms with an AUX timeout
> > +* period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> > +*/
> > + if (INTEL_GEN(i915) < 10)
> > + return false;
> > +
> > if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> > intel_dp->lttpr_common_caps) < 0) {
> > memset(intel_dp->lttpr_common_caps, 0,
> > @@ -127,9 +139,6 @@ int intel_dp_lttpr_init(struct intel_dp *intel_dp)
> > bool ret;
> > int i;
> >
> > - if (intel_dp_is_edp(intel_dp))
> > - return 0;
> > -
> > ret = intel_dp_read_lttpr_common_caps(intel_dp);
> > if (!ret)
> >
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/ilk-glk: Fix link training on links with LTTPRs
On Wed, Mar 17, 2021 at 08:48:59PM +0200, Imre Deak wrote:
> The spec requires to use at least 3.2ms for the AUX timeout period if
> there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming
> spec update makes this more specific, by requiring a 3.2ms minimum
> timeout period for the LTTPR detection reading the 0xF-0xF0007
> range (3.6.5.1).
I'm pondering if we could reduce the timeout after having determined
wherther LTTPRs are present or not? But maybe that wouldn't really speed
up anything since we can't reduce the timeout until after detecting
*something*. And once there is something there we shouldn't really get
any more timeouts I guess. So probably a totally stupid idea.
Anyways, this seems about the only thing we can do given the limited
hw capabilities.
Reviewed-by: Ville Syrjälä
>
> Accordingly disable LTTPR detection until GLK, where the maximum timeout
> we can set is only 1.6ms.
>
> Link training in the non-transparent mode is known to fail at least on
> some SKL systems with a WD19 dock on the link, which exposes an LTTPR
> (see the References below). While this could have different reasons
> besides the too short AUX timeout used, not detecting LTTPRs (and so not
> using the non-transparent LT mode) fixes link training on these systems.
>
> While at it add a code comment about the platform specific maximum
> timeout values.
>
> v2: Add a comment about the g4x maximum timeout as well. (Ville)
>
> Reported-by: Takashi Iwai
> Reported-and-tested-by: Santiago Zarate
> Reported-and-tested-by: Bodo Graumann
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
> Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link
> training")
> Cc: # v5.11
> Cc: Takashi Iwai
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux.c | 7 +++
> .../gpu/drm/i915/display/intel_dp_link_training.c | 15 ---
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index eaebf123310a..10fe17b7280d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -133,6 +133,7 @@ static u32 g4x_get_aux_send_ctl(struct intel_dp *intel_dp,
> else
> precharge = 5;
>
> + /* Max timeout value on G4x-BDW: 1.6ms */
> if (IS_BROADWELL(dev_priv))
> timeout = DP_AUX_CH_CTL_TIME_OUT_600us;
> else
> @@ -159,6 +160,12 @@ static u32 skl_get_aux_send_ctl(struct intel_dp
> *intel_dp,
> enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> u32 ret;
>
> + /*
> + * Max timeout values:
> + * SKL-GLK: 1.6ms
> + * CNL: 3.2ms
> + * ICL+: 4ms
> + */
> ret = DP_AUX_CH_CTL_SEND_BUSY |
> DP_AUX_CH_CTL_DONE |
> DP_AUX_CH_CTL_INTERRUPT |
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 19ba7c7cbaab..c0e25c75c105 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -82,6 +82,18 @@ static void intel_dp_read_lttpr_phy_caps(struct intel_dp
> *intel_dp,
>
> static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> +
> + if (intel_dp_is_edp(intel_dp))
> + return false;
> +
> + /*
> + * Detecting LTTPRs must be avoided on platforms with an AUX timeout
> + * period < 3.2ms. (see DP Standard v2.0, 2.11.2, 3.6.6.1).
> + */
> + if (INTEL_GEN(i915) < 10)
> + return false;
> +
> if (drm_dp_read_lttpr_common_caps(&intel_dp->aux,
> intel_dp->lttpr_common_caps) < 0) {
> memset(intel_dp->lttpr_common_caps, 0,
> @@ -127,9 +139,6 @@ int intel_dp_lttpr_init(struct intel_dp *intel_dp)
> bool ret;
> int i;
>
> - if (intel_dp_is_edp(intel_dp))
> - return 0;
> -
> ret = intel_dp_read_lttpr_common_caps(intel_dp);
> if (!ret)
> return 0;
> --
> 2.25.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915: Individual request cancellation
From: Chris Wilson
Currently, we cancel outstanding requests within a context when the
context is closed. We may also want to cancel individual requests using
the same graceful preemption mechanism.
v2 (Tvrtko):
* Cancel waiters carefully considering no timeline lock and RCU.
* Fixed selftests.
v3 (Tvrtko):
* Remove error propagation to waiters for now.
Signed-off-by: Chris Wilson
Signed-off-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 1 +
.../drm/i915/gt/intel_execlists_submission.c | 9 +-
drivers/gpu/drm/i915/i915_request.c | 52 -
drivers/gpu/drm/i915/i915_request.h | 4 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 201 ++
5 files changed, 261 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 0b062fad1837..e2fb3ae2aaf3 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -314,6 +314,7 @@ int intel_engine_pulse(struct intel_engine_cs *engine)
mutex_unlock(&ce->timeline->mutex);
}
+ intel_engine_flush_scheduler(engine);
intel_engine_pm_put(engine);
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 85ff5fe861b4..4c2acb5a6c0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -421,6 +421,11 @@ static void reset_active(struct i915_request *rq,
ce->lrc.lrca = lrc_update_regs(ce, engine, head);
}
+static bool bad_request(const struct i915_request *rq)
+{
+ return rq->fence.error && i915_request_started(rq);
+}
+
static struct intel_engine_cs *
__execlists_schedule_in(struct i915_request *rq)
{
@@ -433,7 +438,7 @@ __execlists_schedule_in(struct i915_request *rq)
!intel_engine_has_heartbeat(engine)))
intel_context_set_banned(ce);
- if (unlikely(intel_context_is_banned(ce)))
+ if (unlikely(intel_context_is_banned(ce) || bad_request(rq)))
reset_active(rq, engine);
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -1112,7 +1117,7 @@ static unsigned long active_preempt_timeout(struct
intel_engine_cs *engine,
return 0;
/* Force a fast reset for terminated contexts (ignoring sysfs!) */
- if (unlikely(intel_context_is_banned(rq->context)))
+ if (unlikely(intel_context_is_banned(rq->context) || bad_request(rq)))
return 1;
return READ_ONCE(engine->props.preempt_timeout_ms);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a6..b4511ac05e9a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -33,7 +33,10 @@
#include "gem/i915_gem_context.h"
#include "gt/intel_breadcrumbs.h"
#include "gt/intel_context.h"
+#include "gt/intel_engine.h"
+#include "gt/intel_engine_heartbeat.h"
#include "gt/intel_gpu_commands.h"
+#include "gt/intel_reset.h"
#include "gt/intel_ring.h"
#include "gt/intel_rps.h"
@@ -429,20 +432,22 @@ void __i915_request_skip(struct i915_request *rq)
rq->infix = rq->postfix;
}
-void i915_request_set_error_once(struct i915_request *rq, int error)
+bool i915_request_set_error_once(struct i915_request *rq, int error)
{
int old;
GEM_BUG_ON(!IS_ERR_VALUE((long)error));
if (i915_request_signaled(rq))
- return;
+ return false;
old = READ_ONCE(rq->fence.error);
do {
if (fatal_error(old))
- return;
+ return false;
} while (!try_cmpxchg(&rq->fence.error, &old, error));
+
+ return true;
}
struct i915_request *i915_request_mark_eio(struct i915_request *rq)
@@ -609,6 +614,47 @@ void i915_request_unsubmit(struct i915_request *request)
spin_unlock_irqrestore(&se->lock, flags);
}
+static struct intel_engine_cs *active_engine(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine, *locked;
+
+ locked = READ_ONCE(rq->engine);
+ spin_lock_irq(&locked->sched.lock);
+ while (unlikely(locked != (engine = READ_ONCE(rq->engine {
+ spin_unlock(&locked->sched.lock);
+ locked = engine;
+ spin_lock(&locked->sched.lock);
+ }
+
+ engine = NULL;
+ if (i915_request_is_active(rq) && !__i915_request_is_complete(rq))
+ engine = locked;
+
+ spin_unlock_irq(&locked->sched.lock);
+
+ return engine;
+}
+
+static void __cancel_request(struct i915_request *rq)
+{
+ struct intel_engine_cs *engine = active_engine(rq);
+
+ if (engine && intel_engine_pulse(engine))
+ intel_gt_handle_error(engine->gt, engine->mask, 0,
[Intel-gfx] [PATCH 6/6] drm/i915: Allow configuring default request expiry via modparam
From: Tvrtko Ursulin Module parameter is added (request_timeout_ms) to allow configuring the default request/fence expiry. Default value is inherited from CONFIG_DRM_I915_REQUEST_TIMEOUT. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Acked-by: Daniel Vetter --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++-- drivers/gpu/drm/i915/i915_params.c | 5 + drivers/gpu/drm/i915/i915_params.h | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index be71be21800b..cf5b706a39b8 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -877,11 +877,12 @@ static void __set_default_fence_expiry(struct i915_gem_context *ctx) struct drm_i915_private *i915 = ctx->i915; int ret; - if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT)) + if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) || + !i915->params.request_timeout_ms) return; /* Default expiry for user fences. */ - ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000); + ret = __set_watchdog(ctx, i915->params.request_timeout_ms * 1000); if (ret) drm_notice(&i915->drm, "Failed to configure default fence expiry! (%d)", diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 6939634e56ed..0320878d96b0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -197,6 +197,11 @@ i915_param_named_unsafe(fake_lmem_start, ulong, 0400, "Fake LMEM start offset (default: 0)"); #endif +#if CONFIG_DRM_I915_REQUEST_TIMEOUT +i915_param_named_unsafe(request_timeout_ms, uint, 0600, + "Default request/fence/batch buffer expiration timeout."); +#endif + static __always_inline void _print_param(struct drm_printer *p, const char *name, const char *type, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 48f47e44e848..34ebb0662547 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -72,6 +72,7 @@ struct drm_printer; param(int, enable_dpcd_backlight, -1, 0600) \ param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \ param(unsigned long, fake_lmem_start, 0, 0400) \ + param(unsigned int, request_timeout_ms, CONFIG_DRM_I915_REQUEST_TIMEOUT, 0600) \ /* leave bools at the end to not create holes */ \ param(bool, enable_hangcheck, true, 0600) \ param(bool, load_detect_test, false, 0600) \ -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Request watchdog infrastructure
From: Tvrtko Ursulin
Prepares the plumbing for setting request/fence expiration time. All code
is put in place but is never activeted due yet missing ability to actually
configure the timer.
Outline of the basic operation:
A timer is started when request is ready for execution. If the request
completes (retires) before the timer fires, timer is cancelled and nothing
further happens.
If the timer fires request is added to a lockless list and worker queued.
Purpose of this is twofold: a) It allows request cancellation from a more
friendly context and b) coalesces multiple expirations into a single event
of consuming the list.
Worker locklessly consumes the list of expired requests and cancels them
all using previous added i915_request_cancel().
Associated timeout value is stored in rq->context.watchdog.timeout_us.
v2:
* Log expiration.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 ++
.../drm/i915/gt/intel_execlists_submission.h | 2 +
drivers/gpu/drm/i915/gt/intel_gt.c| 3 +
drivers/gpu/drm/i915/gt/intel_gt.h| 2 +
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 26 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 +++
drivers/gpu/drm/i915/i915_request.c | 56 +++
drivers/gpu/drm/i915/i915_request.h | 8 +++
8 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0ea18c9e2aca..65a5730a4f5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -99,6 +99,10 @@ struct intel_context {
#define CONTEXT_FORCE_SINGLE_SUBMISSION7
#define CONTEXT_NOPREEMPT 8
+ struct {
+ u64 timeout_us;
+ } watchdog;
+
u32 *lrc_reg_state;
union {
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
index f7bd3fccfee8..4ca9b475e252 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.h
@@ -6,6 +6,7 @@
#ifndef __INTEL_EXECLISTS_SUBMISSION_H__
#define __INTEL_EXECLISTS_SUBMISSION_H__
+#include
#include
struct drm_printer;
@@ -13,6 +14,7 @@ struct drm_printer;
struct i915_request;
struct intel_context;
struct intel_engine_cs;
+struct intel_gt;
enum {
INTEL_CONTEXT_SCHEDULE_IN = 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca76f93bc03d..8d77dcbad059 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -31,6 +31,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
INIT_LIST_HEAD(>->closed_vma);
spin_lock_init(>->closed_lock);
+ init_llist_head(>->watchdog.list);
+ INIT_WORK(>->watchdog.work, intel_gt_watchdog_work);
+
intel_gt_init_buffer_pool(gt);
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index a17bd8b3195f..7ec395cace69 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -78,4 +78,6 @@ static inline bool intel_gt_is_wedged(const struct intel_gt
*gt)
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p);
+void intel_gt_watchdog_work(struct work_struct *work);
+
#endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index 36ec97f79174..a7f7bd662fb7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -8,6 +8,7 @@
#include "i915_drv.h" /* for_each_engine() */
#include "i915_request.h"
#include "intel_engine_heartbeat.h"
+#include "intel_execlists_submission.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_gt_requests.h"
@@ -242,4 +243,29 @@ void intel_gt_fini_requests(struct intel_gt *gt)
{
/* Wait until the work is marked as finished before unloading! */
cancel_delayed_work_sync(>->requests.retire_work);
+
+ flush_work(>->watchdog.work);
+}
+
+void intel_gt_watchdog_work(struct work_struct *work)
+{
+ struct intel_gt *gt =
+ container_of(work, typeof(*gt), watchdog.work);
+ struct i915_request *rq, *rn;
+ struct llist_node *first;
+
+ first = llist_del_all(>->watchdog.list);
+ if (!first)
+ return;
+
+ llist_for_each_entry_safe(rq, rn, first, watchdog.link) {
+ if (!i915_request_completed(rq)) {
+ drm_notice(>->i915->drm,
+ "Fence expiration time out %llx:%llu!\n",
+ rq->fence.context,
+
[Intel-gfx] [PATCH 5/6] drm/i915: Fail too long user submissions by default
From: Tvrtko Ursulin
A new Kconfig option CONFIG_DRM_I915_REQUEST_TIMEOUT is added, defaulting
to 20s, and this timeout is applied to all users contexts using the
previously added watchdog facility.
Result of this is that any user submission will simply fail after this
timeout, either causing a reset (for non-preemptable), or incomplete
results.
This can have an effect that workloads which used to work fine will
suddenly start failing. Even workloads comprised of short batches but in
long dependency chains can be terminated.
And becuase of lack of agreement on usefulness and safety of fence error
propagation this partial execution can be invisible to userspace even if
it is "listening" to returned fence status.
Another interaction is with hangcheck where care needs to be taken timeout
is not set lower or close to three times the heartbeat interval. Otherwise
a hang in any application can cause complete termination of all
submissions from unrelated clients. Any users modifying the per engine
heartbeat intervals therefore need to be aware of this potential denial of
service to avoid inadvertently enabling it.
Given all this I am personally not convinced the scheme is a good idea.
Intuitively it feels object importers would be better positioned to
enforce the time they are willing to wait for something to complete.
v2:
* Improved commit message and Kconfig text.
* Pull in some helper code from patch which got dropped.
v3:
* Bump timeout to 20s to see if it helps Tigerlake.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/Kconfig.profile | 14 +++
drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 4 ++
drivers/gpu/drm/i915/gt/intel_context_param.h | 11 +-
4 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 35bbe2b80596..39328567c200 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -1,3 +1,17 @@
+config DRM_I915_REQUEST_TIMEOUT
+ int "Default timeout for requests (ms)"
+ default 2 # milliseconds
+ help
+ Configures the default timeout after which any user submissions will
+ be forcefully terminated.
+
+ Beware setting this value lower, or close to heartbeat interval
+ rounded to whole seconds times three, in order to avoid allowing
+ misbehaving applications causing total rendering failure in unrelated
+ clients.
+
+ May be 0 to disable the timeout.
+
config DRM_I915_FENCE_TIMEOUT
int "Timeout for unsignaled foreign fences (ms, jiffy granularity)"
default 1 # milliseconds
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ca37d93ef5e7..be71be21800b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -233,6 +233,8 @@ static void intel_context_set_gem(struct intel_context *ce,
if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
intel_engine_has_timeslices(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
+
+ intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
}
static void __free_engines(struct i915_gem_engines *e, unsigned int count)
@@ -852,6 +854,40 @@ static void __assign_timeline(struct i915_gem_context *ctx,
context_apply_all(ctx, __apply_timeline, timeline);
}
+static int __apply_watchdog(struct intel_context *ce, void *timeout_us)
+{
+ return intel_context_set_watchdog_us(ce, (uintptr_t)timeout_us);
+}
+
+static int
+__set_watchdog(struct i915_gem_context *ctx, unsigned long timeout_us)
+{
+ int ret;
+
+ ret = context_apply_all(ctx, __apply_watchdog,
+ (void *)(uintptr_t)timeout_us);
+ if (!ret)
+ ctx->watchdog.timeout_us = timeout_us;
+
+ return ret;
+}
+
+static void __set_default_fence_expiry(struct i915_gem_context *ctx)
+{
+ struct drm_i915_private *i915 = ctx->i915;
+ int ret;
+
+ if (!IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT))
+ return;
+
+ /* Default expiry for user fences. */
+ ret = __set_watchdog(ctx, CONFIG_DRM_I915_REQUEST_TIMEOUT * 1000);
+ if (ret)
+ drm_notice(&i915->drm,
+ "Failed to configure default fence expiry! (%d)",
+ ret);
+}
+
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
{
@@ -896,6 +932,8 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
intel_timeline_put(timeline);
}
+ __set_default_fence_expiry(ctx);
+
trace_i915_context_create(ctx);
return ctx;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context
[Intel-gfx] [PATCH v3 0/6] Default request/fence expiry + watchdog
From: Tvrtko Ursulin "Watchdog" aka "restoring hangcheck" aka default request/fence expiry - second post of a somewhat controversial feature, now upgraded to patch status. I quote the "watchdog" becuase in classical sense watchdog would allow userspace to ping it and so remain alive. I quote "restoring hangcheck" because this series, contrary to the old hangcheck, is not looking at whether the workload is making any progress from the kernel side either. (Although disclaimer my memory may be leaky - Daniel suspects old hangcheck had some stricter, more indiscriminatory, angles to it. But apart from being prone to both false negatives and false positives I can't remember that myself.) Short version - ask is to fail any user submissions after a set time period. In this RFC that time is twelve seconds. Time counts from the moment user submission is "runnable" (implicit and explicit dependencies have been cleared) and keeps counting regardless of the GPU contetion caused by other users of the system. So semantics are really a bit weak, but again, I understand this is really really wanted by the DRM core even if I am not convinced it is a good idea. There are some dangers with doing this - text borrowed from a patch in the series: This can have an effect that workloads which used to work fine will suddenly start failing. Even workloads comprised of short batches but in long dependency chains can be terminated. And becuase of lack of agreement on usefulness and safety of fence error propagation this partial execution can be invisible to userspace even if it is "listening" to returned fence status. Another interaction is with hangcheck where care needs to be taken timeout is not set lower or close to three times the heartbeat interval. Otherwise a hang in any application can cause complete termination of all submissions from unrelated clients. Any users modifying the per engine heartbeat intervals therefore need to be aware of this potential denial of service to avoid inadvertently enabling it. Given all this I am personally not convinced the scheme is a good idea. Intuitively it feels object importers would be better positioned to enforce the time they are willing to wait for something to complete. v2: * Dropped context param. * Improved commit messages and Kconfig text. v3: * Log timeouts. * Bump timeout to 20s to see if it helps Tigerlake. * Fix sentinel assert. Test-with: 20210318162400.2065097-1-tvrtko.ursu...@linux.intel.com Cc: Daniel Vetter https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: Handle async cancellation in sentinel assert
From: Tvrtko Ursulin With the watchdog cancelling requests asynchronously to preempt-to-busy we need to relax one assert making it apply only to requests not in error. v2: * Check against the correct request! Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 4b870eca9693..bf557290173a 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -815,6 +815,13 @@ assert_pending_valid(const struct intel_engine_execlists *execlists, spin_unlock_irqrestore(&rq->lock, flags); if (!ok) return false; + + /* +* Due async nature of preempt-to-busy and request cancellation +* we need to skip further asserts for cancelled requests. +*/ + if (READ_ONCE(rq->fence.error)) + break; } return ce; -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: Restrict sentinel requests further
From: Tvrtko Ursulin Disallow sentinel requests follow previous sentinels to make request cancellation work better when faced with a chain of requests which have all been marked as in error. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c index 4c2acb5a6c0a..4b870eca9693 100644 --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c @@ -896,7 +896,7 @@ static bool can_merge_rq(const struct i915_request *prev, if (__i915_request_is_complete(next)) return true; - if (unlikely((i915_request_flags(prev) ^ i915_request_flags(next)) & + if (unlikely((i915_request_flags(prev) | i915_request_flags(next)) & (BIT(I915_FENCE_FLAG_NOPREEMPT) | BIT(I915_FENCE_FLAG_SENTINEL return false; -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT
Looks like that there actually are another subset of laptops on the market
that don't support the Intel HDR backlight interface, but do advertise
support for the VESA DPCD backlight interface despite the fact it doesn't
seem to work.
Note though I'm not entirely clear on this - on one of the machines where
this issue was observed, I also noticed that we appeared to be rejecting
the VBT defined backlight frequency in
intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that:
/* Use highest possible value of Pn for more granularity of brightness
* adjustment while satifying the conditions below.
* ...
* - FxP is within 25% of desired value.
* Note: 25% is arbitrary value and may need some tweak.
*/
So it's possible that this value might just need to be tweaked, but for now
let's just disable the VESA backlight interface unless it's specified in
the VBT just to be safe. We might be able to try enabling this again by
default in the future.
Fixes: 2227816e647a ("drm/i915/dp: Allow forcing specific interfaces through
enable_dpcd_backlight")
Cc: Jani Nikula
Cc: Rodrigo Vivi
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 651884390137..4f8337c7fd2e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -646,7 +646,6 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
break;
case INTEL_BACKLIGHT_DISPLAY_DDI:
try_intel_interface = true;
- try_vesa_interface = true;
break;
default:
return -ENODEV;
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/3] tests/i915/gem_watchdog: Exercise long rendering chains
From: Tvrtko Ursulin
Test to demonstrate a problem with the proposed default fence expiry
semantics where long rendering chain get silently broken.
If we had fence error propagation (no clear agreement whether to do it or
not) maybe userspace would see if, assuming fence status is looked at, but
overall potential rendering corruption is the story in any case.
Note that this is not a single long batch but just a long queue of work
which. Could be viewed as heavy system load as well (like virtualisation
or other types of resource sharing).
Signed-off-by: Tvrtko Ursulin
---
tests/i915/gem_watchdog.c | 310 ++
1 file changed, 310 insertions(+)
diff --git a/tests/i915/gem_watchdog.c b/tests/i915/gem_watchdog.c
index f86d3d4c7437..8f9fb17750fb 100644
--- a/tests/i915/gem_watchdog.c
+++ b/tests/i915/gem_watchdog.c
@@ -23,6 +23,8 @@
#include "config.h"
+#include
+#include
#include
#include
#include
@@ -321,8 +323,309 @@ static void virtual(int i915)
igt_assert_eq(count, expect);
}
+#define MI_INSTR(opcode, flags) (((opcode) << 23) | (flags))
+
+#define MI_MATH(x) MI_INSTR(0x1a, (x) - 1)
+#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
+/* Opcodes for MI_MATH_INSTR */
+#define MI_MATH_NOOP MI_MATH_INSTR(0x000, 0x0, 0x0)
+#define MI_MATH_LOAD(op1, op2)MI_MATH_INSTR(0x080, op1, op2)
+#define MI_MATH_LOADINV(op1, op2) MI_MATH_INSTR(0x480, op1, op2)
+#define MI_MATH_LOAD0(op1)MI_MATH_INSTR(0x081, op1)
+#define MI_MATH_LOAD1(op1)MI_MATH_INSTR(0x481, op1)
+#define MI_MATH_ADD MI_MATH_INSTR(0x100, 0x0, 0x0)
+#define MI_MATH_SUB MI_MATH_INSTR(0x101, 0x0, 0x0)
+#define MI_MATH_AND MI_MATH_INSTR(0x102, 0x0, 0x0)
+#define MI_MATH_ORMI_MATH_INSTR(0x103, 0x0, 0x0)
+#define MI_MATH_XOR MI_MATH_INSTR(0x104, 0x0, 0x0)
+#define MI_MATH_STORE(op1, op2) MI_MATH_INSTR(0x180, op1, op2)
+#define MI_MATH_STOREINV(op1, op2)MI_MATH_INSTR(0x580, op1, op2)
+/* Registers used as operands in MI_MATH_INSTR */
+#define MI_MATH_REG(x)(x)
+#define MI_MATH_REG_SRCA 0x20
+#define MI_MATH_REG_SRCB 0x21
+#define MI_MATH_REG_ACCU 0x31
+#define MI_MATH_REG_ZF0x32
+#define MI_MATH_REG_CF0x33
+
+#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1)
+
+static unsigned int offset_in_page(void *addr)
+{
+ return (uintptr_t)addr & 4095;
+}
+
+static uint64_t div64_u64_round_up(uint64_t x, uint64_t y)
+{
+ return (x + y - 1) / y;
+}
+
+static int read_timestamp_frequency(int i915)
+{
+ int value = 0;
+ drm_i915_getparam_t gp = {
+ .value = &value,
+ .param = I915_PARAM_CS_TIMESTAMP_FREQUENCY,
+ };
+ ioctl(i915, DRM_IOCTL_I915_GETPARAM, &gp);
+ return value;
+}
+
+static uint64_t ns_to_ticks(int i915, uint64_t ns)
+{
+ return div64_u64_round_up(ns * read_timestamp_frequency(i915),
+ NSEC_PER_SEC);
+}
+
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(i915, ALIGN(offset + 4, 4096));
+ gem_write(i915, handle, offset, &bbe, sizeof(bbe));
+
+ return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+ return __batch_create(i915, 0);
+}
+
+static void delay(int i915,
+ const struct intel_execution_engine2 *e,
+ uint32_t handle,
+ uint64_t addr,
+ uint64_t ns)
+{
+ const int use_64b = intel_gen(intel_get_drm_devid(i915)) >= 8;
+ const uint32_t base = gem_engine_mmio_base(i915, e->name);
+#define CS_GPR(x) (base + 0x600 + 8 * (x))
+#define RUNTIME (base + 0x3a8)
+ enum { START_TS, NOW_TS };
+ uint32_t *map, *cs, *jmp;
+
+ igt_require(base);
+
+ /* Loop until CTX_TIMESTAMP - initial > @ns */
+
+ cs = map = gem_mmap__device_coherent(i915, handle, 0, 4096, PROT_WRITE);
+
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = CS_GPR(START_TS) + 4;
+ *cs++ = 0;
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = RUNTIME;
+ *cs++ = CS_GPR(START_TS);
+
+ while (offset_in_page(cs) & 63)
+ *cs++ = 0;
+ jmp = cs;
+
+ *cs++ = 0x5 << 23; /* MI_ARB_CHECK */
+
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = CS_GPR(NOW_TS) + 4;
+ *cs++ = 0;
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = RUNTIME;
+ *cs++ = CS_GPR(NOW_TS);
+
+ /* delta = now - start; inverted to match COND_BBE */
+ *cs++ = MI_MATH(4);
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(NOW_TS));
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(START_TS));
+ *cs++ = MI_MATH_SUB;
+
[Intel-gfx] [PATCH i-g-t 2/3] tests/i915: Default fence expiry test
From: Tvrtko Ursulin
Basic test to check that default fence expiry works as expected.
Relies on the modparam to run quicker.
Signed-off-by: Tvrtko Ursulin
---
tests/Makefile.sources| 3 +
tests/i915/gem_watchdog.c | 376 ++
tests/meson.build | 1 +
3 files changed, 380 insertions(+)
create mode 100644 tests/i915/gem_watchdog.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 4f24fb3a15a5..e992285fedc5 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -463,6 +463,9 @@ gem_userptr_blits_SOURCES = i915/gem_userptr_blits.c
TESTS_progs += gem_wait
gem_wait_SOURCES = i915/gem_wait.c
+TESTS_progs += gem_watchdog
+gem_exec_watchdog_SOURCES = i915/gem_watchdog.c
+
TESTS_progs += gem_workarounds
gem_workarounds_SOURCES = i915/gem_workarounds.c
diff --git a/tests/i915/gem_watchdog.c b/tests/i915/gem_watchdog.c
new file mode 100644
index ..f86d3d4c7437
--- /dev/null
+++ b/tests/i915/gem_watchdog.c
@@ -0,0 +1,376 @@
+/*
+ * Copyright © 2021 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "config.h"
+
+#include
+#include
+#include
+
+#include "i915/gem.h"
+#include "igt.h"
+#include "igt_params.h"
+#include "sw_sync.h"
+
+#define EWATCHDOG EINTR
+
+static struct drm_i915_query_engine_info *__engines__;
+
+static int __i915_query(int fd, struct drm_i915_query *q)
+{
+ if (igt_ioctl(fd, DRM_IOCTL_I915_QUERY, q))
+ return -errno;
+ return 0;
+}
+
+static int
+__i915_query_items(int fd, struct drm_i915_query_item *items, uint32_t n_items)
+{
+ struct drm_i915_query q = {
+ .num_items = n_items,
+ .items_ptr = to_user_pointer(items),
+ };
+ return __i915_query(fd, &q);
+}
+
+#define i915_query_items(fd, items, n_items) do { \
+ igt_assert_eq(__i915_query_items(fd, items, n_items), 0); \
+ errno = 0; \
+ } while (0)
+
+static unsigned int default_timeout_wait_s;
+static const unsigned int watchdog_us = 500 * 1000;
+
+static unsigned int
+wait_timeout(int i915, igt_spin_t **spin, unsigned int num_engines,
+unsigned int wait_us, unsigned int expect)
+{
+ unsigned int count_idle = 0, count_fence = 0, count_started = 0, i;
+ bool started[num_engines];
+
+ memset(started, 0, sizeof(started));
+
+ while (count_started < num_engines) {
+ for (i = 0; i < num_engines; i++) {
+ if (started[i])
+ continue;
+
+ if (igt_spin_has_started(spin[i])) {
+ started[i] = true;
+ count_started++;
+ }
+ }
+ }
+
+ igt_until_timeout(DIV_ROUND_UP(wait_us, USEC_PER_SEC)) {
+ usleep(watchdog_us / 2);
+
+ for (i = 0, count_idle = 0; i < num_engines; i++) {
+ if (!gem_bo_busy(i915, spin[i]->handle))
+ count_idle++;
+ }
+
+ for (i = 0, count_fence = 0; i < num_engines; i++) {
+ if (sync_fence_status(spin[i]->out_fence))
+ count_fence++;
+ }
+
+ if (count_idle == num_engines)
+ break;
+ }
+
+ if (count_idle < expect) {
+ for (i = 0; i < num_engines; i++) {
+ if (gem_bo_busy(i915, spin[i]->handle))
+ igt_warn("Request %u/%u not cancelled!\n",
+i + 1, num_engines);
+ }
+ }
+
+ if (count_fence < expect) {
+ for (i = 0; i < num_engines; i++) {
+ if (!sync_fence_status(spin[i]->out_fence))
+ igt_warn("Fence
[Intel-gfx] [PATCH i-g-t 1/3] lib: Add helper for reading modparam values
From: Tvrtko Ursulin
Add __igt_params_get for simple reading of modparams.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_params.c | 26 ++
lib/igt_params.h | 2 ++
2 files changed, 28 insertions(+)
diff --git a/lib/igt_params.c b/lib/igt_params.c
index c06416988baa..1dc6de77b2e0 100644
--- a/lib/igt_params.c
+++ b/lib/igt_params.c
@@ -156,6 +156,32 @@ int igt_params_open(int device)
return params;
}
+/**
+ * __igt_params_get:
+ * @device: fd of the device
+ * @parameter: the name of the parameter to set
+ *
+ * This reads the value of the modparam.
+ *
+ * Returns:
+ * A nul-terminated string, must be freed by caller after use, or NULL
+ * on failure.
+ */
+char *__igt_params_get(int device, const char *parameter)
+{
+ char *str;
+ int dir;
+
+ dir = igt_params_open(device);
+ if (dir < 0)
+ return NULL;
+
+ str = igt_sysfs_get(dir, parameter);
+ close(dir);
+
+ return str;
+}
+
__attribute__((format(printf, 3, 0)))
static bool __igt_params_set(int device, const char *parameter,
const char *fmt, va_list ap, bool save)
diff --git a/lib/igt_params.h b/lib/igt_params.h
index bbd6f3ee6582..6494786f0696 100644
--- a/lib/igt_params.h
+++ b/lib/igt_params.h
@@ -28,6 +28,8 @@
int igt_params_open(int device);
+char *__igt_params_get(int device, const char *parameter);
+
__attribute__((format(printf, 3, 4)))
bool igt_params_set(int device, const char *parameter, const char *fmt, ...);
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 0/3] Default fence expiration test
From: Tvrtko Ursulin See patch 2. Tvrtko Ursulin (3): lib: Add helper for reading modparam values tests/i915: Default fence expiry test tests/i915/gem_watchdog: Exercise long rendering chains lib/igt_params.c | 26 ++ lib/igt_params.h | 2 + tests/Makefile.sources| 3 + tests/i915/gem_watchdog.c | 686 ++ tests/meson.build | 1 + 5 files changed, 718 insertions(+) create mode 100644 tests/i915/gem_watchdog.c -- 2.27.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/7] drm/i915: Remove dead TPS3->TPS2 fallback code
From: Ville Syrjälä If we ever get here with TPS3 then intel_dp_training_pattern() is just broken. Replace the creful fallback with just MISSING_CASE(). Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index d46cd205241c..d1945bff6980 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2503,11 +2503,9 @@ cpt_set_link_train(struct intel_dp *intel_dp, case DP_TRAINING_PATTERN_2: *DP |= DP_LINK_TRAIN_PAT_2_CPT; break; - case DP_TRAINING_PATTERN_3: - drm_dbg_kms(&dev_priv->drm, - "TPS3 not supported, using TPS2 instead\n"); - *DP |= DP_LINK_TRAIN_PAT_2_CPT; - break; + default: + MISSING_CASE(intel_dp_training_pattern_symbol(dp_train_pat)); + return; } intel_de_write(dev_priv, intel_dp->output_reg, intel_dp->DP); @@ -2808,11 +2806,9 @@ g4x_set_link_train(struct intel_dp *intel_dp, case DP_TRAINING_PATTERN_2: *DP |= DP_LINK_TRAIN_PAT_2; break; - case DP_TRAINING_PATTERN_3: - drm_dbg_kms(&dev_priv->drm, - "TPS3 not supported, using TPS2 instead\n"); - *DP |= DP_LINK_TRAIN_PAT_2; - break; + default: + MISSING_CASE(intel_dp_training_pattern_symbol(dp_train_pat)); + return; } intel_de_write(dev_priv, intel_dp->output_reg, intel_dp->DP); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/7] drm/i915: Give g4x_{dp, hdmi}.c g4x_ namespace
From: Ville Syrjälä
s/intel_/g4x_/ for the externally visible g4x_{dp,hdmi}.c
functions.
Acked-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c| 23 +-
drivers/gpu/drm/i915/display/g4x_dp.h| 15 ---
drivers/gpu/drm/i915/display/g4x_hdmi.c | 4 +-
drivers/gpu/drm/i915/display/g4x_hdmi.h | 4 +-
drivers/gpu/drm/i915/display/intel_display.c | 44 ++--
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
6 files changed, 45 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index a35f1886f25b..16a95bab78ad 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -66,8 +66,8 @@ const struct dpll *vlv_get_dpll(struct drm_i915_private *i915)
return IS_CHERRYVIEW(i915) ? &chv_dpll[0].dpll : &vlv_dpll[0].dpll;
}
-void intel_dp_set_clock(struct intel_encoder *encoder,
- struct intel_crtc_state *pipe_config)
+void g4x_dp_set_clock(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
const struct dp_link_dpll *divisor = NULL;
@@ -286,9 +286,9 @@ static bool cpt_dp_port_selected(struct drm_i915_private
*dev_priv,
return false;
}
-bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
- i915_reg_t dp_reg, enum port port,
- enum pipe *pipe)
+bool g4x_dp_port_enabled(struct drm_i915_private *dev_priv,
+i915_reg_t dp_reg, enum port port,
+enum pipe *pipe)
{
bool ret;
u32 val;
@@ -323,8 +323,8 @@ static bool intel_dp_get_hw_state(struct intel_encoder
*encoder,
if (!wakeref)
return false;
- ret = intel_dp_port_enabled(dev_priv, intel_dp->output_reg,
- encoder->port, pipe);
+ ret = g4x_dp_port_enabled(dev_priv, intel_dp->output_reg,
+ encoder->port, pipe);
intel_display_power_put(dev_priv, encoder->power_domain, wakeref);
@@ -1270,8 +1270,8 @@ enum pipe vlv_active_pipe(struct intel_dp *intel_dp)
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
enum pipe pipe;
- if (intel_dp_port_enabled(dev_priv, intel_dp->output_reg,
- encoder->port, &pipe))
+ if (g4x_dp_port_enabled(dev_priv, intel_dp->output_reg,
+ encoder->port, &pipe))
return pipe;
return INVALID_PIPE;
@@ -1301,9 +1301,8 @@ static const struct drm_encoder_funcs intel_dp_enc_funcs
= {
.destroy = intel_dp_encoder_destroy,
};
-bool intel_dp_init(struct drm_i915_private *dev_priv,
- i915_reg_t output_reg,
- enum port port)
+bool g4x_dp_init(struct drm_i915_private *dev_priv,
+i915_reg_t output_reg, enum port port)
{
struct intel_digital_port *dig_port;
struct intel_encoder *intel_encoder;
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.h
b/drivers/gpu/drm/i915/display/g4x_dp.h
index 530760f0d8a2..e1f50263a725 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.h
+++ b/drivers/gpu/drm/i915/display/g4x_dp.h
@@ -19,13 +19,12 @@ struct intel_encoder;
const struct dpll *vlv_get_dpll(struct drm_i915_private *i915);
enum pipe vlv_active_pipe(struct intel_dp *intel_dp);
-void intel_dp_set_clock(struct intel_encoder *encoder,
- struct intel_crtc_state *pipe_config);
-bool intel_dp_port_enabled(struct drm_i915_private *dev_priv,
- i915_reg_t dp_reg, enum port port,
- enum pipe *pipe);
-bool intel_dp_init(struct drm_i915_private *dev_priv,
- i915_reg_t output_reg,
- enum port port);
+void g4x_dp_set_clock(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config);
+bool g4x_dp_port_enabled(struct drm_i915_private *dev_priv,
+i915_reg_t dp_reg, enum port port,
+enum pipe *pipe);
+bool g4x_dp_init(struct drm_i915_private *dev_priv,
+i915_reg_t output_reg, enum port port);
#endif
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 8fa3b8a5a572..78f93506ffaf 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -528,8 +528,8 @@ intel_hdmi_hotplug(struct intel_encoder *encoder,
return state;
}
-void intel_hdmi_init(struct drm_i915_private *dev_priv,
-i915_reg_t hdmi_reg, enum port port)
+void g4x_hdmi_init(struct drm_i915_private *dev_priv,
+ i915_reg_t hdmi_reg, enum port port)
{
struct intel_digital_port *dig_port
[Intel-gfx] [PATCH v2 6/7] drm/i915: Introduce g4x_hdmi.c
From: Ville Syrjälä
Extract the g4x+ HDMI low level code to its own file,
leaving intel_hdmi.c to deal with higher level issues.
The inforframe support I decided to leave in intel_hdmi.c
since I think we need to move that as a whole to its own file.
It is after all used also for DP SDPs, so no longer HDMI
specific.
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/g4x_hdmi.c | 616 +
drivers/gpu/drm/i915/display/g4x_hdmi.h | 19 +
drivers/gpu/drm/i915/display/intel_display.c | 1 +
.../drm/i915/display/intel_display_types.h| 12 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 618 --
drivers/gpu/drm/i915/display/intel_hdmi.h | 3 -
7 files changed, 649 insertions(+), 621 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/g4x_hdmi.c
create mode 100644 drivers/gpu/drm/i915/display/g4x_hdmi.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index dc993aa2bd16..33c2100414a0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -242,6 +242,7 @@ i915-y += \
display/dvo_sil164.o \
display/dvo_tfp410.o \
display/g4x_dp.o \
+ display/g4x_hdmi.o \
display/icl_dsi.o \
display/intel_crt.o \
display/intel_ddi.o \
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
new file mode 100644
index ..8fa3b8a5a572
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -0,0 +1,616 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ *
+ * HDMI support for G4x,ILK,SNB,IVB,VLV,CHV (HSW+ handled by the DDI code).
+ */
+
+#include "g4x_hdmi.h"
+#include "intel_audio.h"
+#include "intel_connector.h"
+#include "intel_display_types.h"
+#include "intel_dpio_phy.h"
+#include "intel_fifo_underrun.h"
+#include "intel_hdmi.h"
+#include "intel_hotplug.h"
+#include "intel_sideband.h"
+#include "intel_sdvo.h"
+
+static void intel_hdmi_prepare(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+ const struct drm_display_mode *adjusted_mode =
&crtc_state->hw.adjusted_mode;
+ u32 hdmi_val;
+
+ intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
+
+ hdmi_val = SDVO_ENCODING_HDMI;
+ if (!HAS_PCH_SPLIT(dev_priv) && crtc_state->limited_color_range)
+ hdmi_val |= HDMI_COLOR_RANGE_16_235;
+ if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
+ hdmi_val |= SDVO_VSYNC_ACTIVE_HIGH;
+ if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
+ hdmi_val |= SDVO_HSYNC_ACTIVE_HIGH;
+
+ if (crtc_state->pipe_bpp > 24)
+ hdmi_val |= HDMI_COLOR_FORMAT_12bpc;
+ else
+ hdmi_val |= SDVO_COLOR_FORMAT_8bpc;
+
+ if (crtc_state->has_hdmi_sink)
+ hdmi_val |= HDMI_MODE_SELECT_HDMI;
+
+ if (HAS_PCH_CPT(dev_priv))
+ hdmi_val |= SDVO_PIPE_SEL_CPT(crtc->pipe);
+ else if (IS_CHERRYVIEW(dev_priv))
+ hdmi_val |= SDVO_PIPE_SEL_CHV(crtc->pipe);
+ else
+ hdmi_val |= SDVO_PIPE_SEL(crtc->pipe);
+
+ intel_de_write(dev_priv, intel_hdmi->hdmi_reg, hdmi_val);
+ intel_de_posting_read(dev_priv, intel_hdmi->hdmi_reg);
+}
+
+static bool intel_hdmi_get_hw_state(struct intel_encoder *encoder,
+ enum pipe *pipe)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+ intel_wakeref_t wakeref;
+ bool ret;
+
+ wakeref = intel_display_power_get_if_enabled(dev_priv,
+encoder->power_domain);
+ if (!wakeref)
+ return false;
+
+ ret = intel_sdvo_port_enabled(dev_priv, intel_hdmi->hdmi_reg, pipe);
+
+ intel_display_power_put(dev_priv, encoder->power_domain, wakeref);
+
+ return ret;
+}
+
+static void intel_hdmi_get_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
+{
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ u32 tmp, flags = 0;
+ int dotclock;
+
+ pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
+
+ tmp = intel_de_read(dev_priv, intel_hdmi->hdmi_reg);
+
+ if (tmp & SDVO_HSYNC_ACTIVE_HIGH)
+ flags |= DRM_MODE_FLAG_PHSYNC;
+ else
+ flags |= DRM_MODE_FLAG_
[Intel-gfx] [PATCH v2 5/7] drm/i915: Introduce g4x_dp.c
From: Ville Syrjälä
Move the g4x+ DP code into a new file. This will leave mostly
platform agnostic code in intel_dp.c. Well, the misplaced phy
test stuff pretty much ruins that, but let's squint real hard
for now.
v2: Add comment exlaining which platforms are covered (Daniel)
Leave intel_dp_unused_lane_mask() be since it is pretty generic
Acked-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/display/g4x_dp.c| 1433 ++
drivers/gpu/drm/i915/display/g4x_dp.h| 31 +
drivers/gpu/drm/i915/display/intel_display.c |1 +
drivers/gpu/drm/i915/display/intel_dp.c | 1415 +
drivers/gpu/drm/i915/display/intel_dp.h |6 -
drivers/gpu/drm/i915/display/intel_pps.c |1 +
7 files changed, 1468 insertions(+), 1420 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/g4x_dp.c
create mode 100644 drivers/gpu/drm/i915/display/g4x_dp.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index bc6138880c67..dc993aa2bd16 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -241,6 +241,7 @@ i915-y += \
display/dvo_ns2501.o \
display/dvo_sil164.o \
display/dvo_tfp410.o \
+ display/g4x_dp.o \
display/icl_dsi.o \
display/intel_crt.o \
display/intel_ddi.o \
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
new file mode 100644
index ..a35f1886f25b
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -0,0 +1,1433 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ *
+ * DisplayPort support for G4x,ILK,SNB,IVB,VLV,CHV (HSW+ handled by the DDI
code).
+ */
+
+#include "g4x_dp.h"
+#include "intel_audio.h"
+#include "intel_connector.h"
+#include "intel_display_types.h"
+#include "intel_dp.h"
+#include "intel_dp_link_training.h"
+#include "intel_dpio_phy.h"
+#include "intel_fifo_underrun.h"
+#include "intel_hdmi.h"
+#include "intel_hotplug.h"
+#include "intel_panel.h"
+#include "intel_pps.h"
+#include "intel_sideband.h"
+
+struct dp_link_dpll {
+ int clock;
+ struct dpll dpll;
+};
+
+static const struct dp_link_dpll g4x_dpll[] = {
+ { 162000,
+ { .p1 = 2, .p2 = 10, .n = 2, .m1 = 23, .m2 = 8 } },
+ { 27,
+ { .p1 = 1, .p2 = 10, .n = 1, .m1 = 14, .m2 = 2 } }
+};
+
+static const struct dp_link_dpll pch_dpll[] = {
+ { 162000,
+ { .p1 = 2, .p2 = 10, .n = 1, .m1 = 12, .m2 = 9 } },
+ { 27,
+ { .p1 = 1, .p2 = 10, .n = 2, .m1 = 14, .m2 = 8 } }
+};
+
+static const struct dp_link_dpll vlv_dpll[] = {
+ { 162000,
+ { .p1 = 3, .p2 = 2, .n = 5, .m1 = 3, .m2 = 81 } },
+ { 27,
+ { .p1 = 2, .p2 = 2, .n = 1, .m1 = 2, .m2 = 27 } }
+};
+
+/*
+ * CHV supports eDP 1.4 that have more link rates.
+ * Below only provides the fixed rate but exclude variable rate.
+ */
+static const struct dp_link_dpll chv_dpll[] = {
+ /*
+* CHV requires to program fractional division for m2.
+* m2 is stored in fixed point format using formula below
+* (m2_int << 22) | m2_fraction
+*/
+ { 162000, /* m2_int = 32, m2_fraction = 1677722 */
+ { .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } },
+ { 27, /* m2_int = 27, m2_fraction = 0 */
+ { .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } },
+};
+
+const struct dpll *vlv_get_dpll(struct drm_i915_private *i915)
+{
+ return IS_CHERRYVIEW(i915) ? &chv_dpll[0].dpll : &vlv_dpll[0].dpll;
+}
+
+void intel_dp_set_clock(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ const struct dp_link_dpll *divisor = NULL;
+ int i, count = 0;
+
+ if (IS_G4X(dev_priv)) {
+ divisor = g4x_dpll;
+ count = ARRAY_SIZE(g4x_dpll);
+ } else if (HAS_PCH_SPLIT(dev_priv)) {
+ divisor = pch_dpll;
+ count = ARRAY_SIZE(pch_dpll);
+ } else if (IS_CHERRYVIEW(dev_priv)) {
+ divisor = chv_dpll;
+ count = ARRAY_SIZE(chv_dpll);
+ } else if (IS_VALLEYVIEW(dev_priv)) {
+ divisor = vlv_dpll;
+ count = ARRAY_SIZE(vlv_dpll);
+ }
+
+ if (divisor && count) {
+ for (i = 0; i < count; i++) {
+ if (pipe_config->port_clock == divisor[i].clock) {
+ pipe_config->dpll = divisor[i].dpll;
+ pipe_config->clock_set = true;
+ break;
+ }
+ }
+ }
+}
+
+static void intel_dp_prepare(struct intel_encoder *encoder,
+const str
[Intel-gfx] [PATCH v2 2/7] drm/i915: Remove dead signal level debugs
From: Ville Syrjälä
If we ever get here with bogus signal levels we've messed
up somewhere earlier. Just use MISSIN_CASE().
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index d1945bff6980..0ce96bd87a49 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3310,8 +3310,7 @@ static u32 snb_cpu_edp_signal_levels(u8 train_set)
case DP_TRAIN_VOLTAGE_SWING_LEVEL_3 | DP_TRAIN_PRE_EMPH_LEVEL_0:
return EDP_LINK_TRAIN_800_1200MV_0DB_SNB_B;
default:
- DRM_DEBUG_KMS("Unsupported voltage swing/pre-emphasis level:"
- "0x%x\n", signal_levels);
+ MISSING_CASE(signal_levels);
return EDP_LINK_TRAIN_400_600MV_0DB_SNB_B;
}
}
@@ -3362,8 +3361,7 @@ static u32 ivb_cpu_edp_signal_levels(u8 train_set)
return EDP_LINK_TRAIN_800MV_3_5DB_IVB;
default:
- DRM_DEBUG_KMS("Unsupported voltage swing/pre-emphasis level:"
- "0x%x\n", signal_levels);
+ MISSING_CASE(signal_levels);
return EDP_LINK_TRAIN_500MV_0DB_IVB;
}
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/7] drm/i915: Split intel_ddi_encoder_reset() from intel_dp_encoder_reset()
From: Ville Syrjälä
Most of intel_dp_encoder_reset() is for pre-ddi platforms.
Make a clean split.
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 11 ++-
drivers/gpu/drm/i915/display/intel_dp.c | 5 ++---
drivers/gpu/drm/i915/display/intel_dp.h | 1 -
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 75655f47f26c..6438e102ad1e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4017,8 +4017,17 @@ static void intel_ddi_encoder_destroy(struct drm_encoder
*encoder)
kfree(dig_port);
}
+static void intel_ddi_encoder_reset(struct drm_encoder *encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
+
+ intel_dp->reset_link_params = true;
+
+ intel_pps_encoder_reset(intel_dp);
+}
+
static const struct drm_encoder_funcs intel_ddi_funcs = {
- .reset = intel_dp_encoder_reset,
+ .reset = intel_ddi_encoder_reset,
.destroy = intel_ddi_encoder_destroy,
};
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 415732b80108..249ffd2c7c54 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5738,13 +5738,12 @@ static enum pipe vlv_active_pipe(struct intel_dp
*intel_dp)
return INVALID_PIPE;
}
-void intel_dp_encoder_reset(struct drm_encoder *encoder)
+static void intel_dp_encoder_reset(struct drm_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
- if (!HAS_DDI(dev_priv))
- intel_dp->DP = intel_de_read(dev_priv, intel_dp->output_reg);
+ intel_dp->DP = intel_de_read(dev_priv, intel_dp->output_reg);
intel_dp->reset_link_params = true;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index d673cba16835..e4a71c19bd51 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -56,7 +56,6 @@ void intel_dp_configure_protocol_converter(struct intel_dp
*intel_dp,
void intel_dp_sink_set_decompression_state(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state,
bool enable);
-void intel_dp_encoder_reset(struct drm_encoder *encoder);
void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder);
void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder);
void intel_dp_encoder_flush_work(struct drm_encoder *encoder);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/7] drm/i915: Relocate intel_dp_program_link_training_pattern()
From: Ville Syrjälä
intel_dp_program_link_training_pattern() clearly belongs in
intel_dp_link_training.c. Make it so.
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 33 ---
drivers/gpu/drm/i915/display/intel_dp.h | 4 ---
.../drm/i915/display/intel_dp_link_training.c | 33 +++
.../drm/i915/display/intel_dp_link_training.h | 3 ++
4 files changed, 36 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0ce96bd87a49..415732b80108 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3386,39 +3386,6 @@ ivb_cpu_edp_set_signal_levels(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
-static char dp_training_pattern_name(u8 train_pat)
-{
- switch (train_pat) {
- case DP_TRAINING_PATTERN_1:
- case DP_TRAINING_PATTERN_2:
- case DP_TRAINING_PATTERN_3:
- return '0' + train_pat;
- case DP_TRAINING_PATTERN_4:
- return '4';
- default:
- MISSING_CASE(train_pat);
- return '?';
- }
-}
-
-void
-intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
- const struct intel_crtc_state
*crtc_state,
- u8 dp_train_pat)
-{
- struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
- struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- u8 train_pat = intel_dp_training_pattern_symbol(dp_train_pat);
-
- if (train_pat != DP_TRAINING_PATTERN_DISABLE)
- drm_dbg_kms(&dev_priv->drm,
- "[ENCODER:%d:%s] Using DP training pattern TPS%c\n",
- encoder->base.base.id, encoder->base.name,
- dp_training_pattern_name(train_pat));
-
- intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
-}
-
static void
intel_dp_link_down(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index d80839139bfb..d673cba16835 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -87,10 +87,6 @@ void intel_edp_drrs_invalidate(struct drm_i915_private
*dev_priv,
void intel_edp_drrs_flush(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits);
-void
-intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
- const struct intel_crtc_state
*crtc_state,
- u8 dp_train_pat);
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
u8 *link_bw, u8 *rate_select);
bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 19ba7c7cbaab..5a37b9da7652 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -329,6 +329,39 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
return drm_dp_dpcd_write(&intel_dp->aux, reg, buf, len) == len;
}
+static char dp_training_pattern_name(u8 train_pat)
+{
+ switch (train_pat) {
+ case DP_TRAINING_PATTERN_1:
+ case DP_TRAINING_PATTERN_2:
+ case DP_TRAINING_PATTERN_3:
+ return '0' + train_pat;
+ case DP_TRAINING_PATTERN_4:
+ return '4';
+ default:
+ MISSING_CASE(train_pat);
+ return '?';
+ }
+}
+
+void
+intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
+ const struct intel_crtc_state
*crtc_state,
+ u8 dp_train_pat)
+{
+ struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ u8 train_pat = intel_dp_training_pattern_symbol(dp_train_pat);
+
+ if (train_pat != DP_TRAINING_PATTERN_DISABLE)
+ drm_dbg_kms(&dev_priv->drm,
+ "[ENCODER:%d:%s] Using DP training pattern TPS%c\n",
+ encoder->base.base.id, encoder->base.name,
+ dp_training_pattern_name(train_pat));
+
+ intel_dp->set_link_train(intel_dp, crtc_state, dp_train_pat);
+}
+
void intel_dp_set_signal_levels(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
enum drm_dp_phy dp_phy)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915
[Intel-gfx] [PATCH v2 0/7] drm/i915: Shuffle DP code around
From: Ville Syrjälä
New iteration of the g4x+ DP code shuffle. Dealt with
Daniel's review comments, and in the end I decided to do
the same operation to the g4x HDMI code to make intel_hdmi.c
a bit less confusing as well.
Cc: Daniel Vetter
Ville Syrjälä (7):
drm/i915: Remove dead TPS3->TPS2 fallback code
drm/i915: Remove dead signal level debugs
drm/i915: Relocate intel_dp_program_link_training_pattern()
drm/i915: Split intel_ddi_encoder_reset() from
intel_dp_encoder_reset()
drm/i915: Introduce g4x_dp.c
drm/i915: Introduce g4x_hdmi.c
drm/i915: Give g4x_{dp,hdmi}.c g4x_ namespace
drivers/gpu/drm/i915/Makefile |2 +
drivers/gpu/drm/i915/display/g4x_dp.c | 1432
drivers/gpu/drm/i915/display/g4x_dp.h | 30 +
drivers/gpu/drm/i915/display/g4x_hdmi.c | 616 +++
drivers/gpu/drm/i915/display/g4x_hdmi.h | 19 +
drivers/gpu/drm/i915/display/intel_ddi.c | 11 +-
drivers/gpu/drm/i915/display/intel_display.c | 46 +-
.../drm/i915/display/intel_display_types.h| 12 +
drivers/gpu/drm/i915/display/intel_dp.c | 1457 +
drivers/gpu/drm/i915/display/intel_dp.h | 11 -
.../drm/i915/display/intel_dp_link_training.c | 33 +
.../drm/i915/display/intel_dp_link_training.h |3 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 618 ---
drivers/gpu/drm/i915/display/intel_hdmi.h |3 -
drivers/gpu/drm/i915/display/intel_pps.c |1 +
15 files changed, 2184 insertions(+), 2110 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/g4x_dp.c
create mode 100644 drivers/gpu/drm/i915/display/g4x_dp.h
create mode 100644 drivers/gpu/drm/i915/display/g4x_hdmi.c
create mode 100644 drivers/gpu/drm/i915/display/g4x_hdmi.h
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-fixes
Op 18-03-2021 om 13:31 schreef Daniel Vetter: > On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst > wrote: >> drm-misc-fixes-2021-03-18: >> drm-misc-fixes for v5.12-rc4: >> - Make ttm_bo_unpin() not wraparound on too many unpins. >> - Fix coccicheck warning in omap. > Still missing the 2 patches from drm-misc-next-fixes, and those being > left out also means drm-misc-next isn't pushed to for-linux-next > branch, which is causing a ton of confusion itself. > -Daniel We had a discussion on irc, those patches were part of the previous pull. I've reset drm-misc-next-fixes to v5.12-rc1-dontuse, to unplug drm-misc-next. >> The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: >> >> drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 >> >> for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: >> >> drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 >> 13:59:23 +0200) >> >> >> drm-misc-fixes for v5.12-rc4: >> - Make ttm_bo_unpin() not wraparound on too many unpins. >> - Fix coccicheck warning in omap. >> >> >> Christian König (1): >> drm/ttm: make ttm_bo_unpin more defensive >> >> Junlin Yang (1): >> drm/omap: dsi: fix unsigned expression compared with zero >> >> drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- >> include/drm/ttm/ttm_bo_api.h | 6 -- >> 2 files changed, 8 insertions(+), 5 deletions(-) > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Disable pread/pwrite ioctl's for future platforms (v3)
On Wed, Mar 17, 2021 at 06:40:12PM -0500, Jason Ekstrand wrote:
> From: Ashutosh Dixit
>
> The rationale for this change is roughly as follows:
>
> 1. The functionality can be done entirely in userspace with a
> combination of mmap + memcpy
>
> 2. The only reason anyone in userspace is still using it is because
> someone implemented bo_subdata that way in libdrm ages ago and
> they're all too lazy to write the 5 lines of code to do a map.
>
> 3. This falls cleanly into the category of things which will only get
> more painful with local memory support.
>
> These ioctls aren't used much anymore by "real" userspace drivers.
> Vulkan has never used them and neither has the iris GL driver. The old
> i965 GL driver does use PWRITE for glBufferSubData but it only supports
> up through Gen11; Gen12 was never enabled in i965. The compute driver
> has never used PREAD/PWRITE. The only remaining user is the media
> driver which uses it exactly twice and they're easily removed [1] so
> expecting them to drop it going forward is reasonable.
>
> IGT changes which handle this kernel change have also been submitted [2].
>
> [1] https://github.com/intel/media-driver/pull/1160
> [2] https://patchwork.freedesktop.org/series/81384/
>
> v2 (Jason Ekstrand):
> - Improved commit message with the status of all usermode drivers
> - A more future-proof platform check
>
> v3 (Jason Ekstrand):
> - Drop the HAS_LMEM checks as they're already covered by the version
>checks
>
> Signed-off-by: Ashutosh Dixit
> Signed-off-by: Jason Ekstrand
> Reviewed-by: Jason Ekstrand
Merged the first three here. For the scheduler/context stuff I think we
should go back to normal due process with kernel patch + igt patches
tested together, then land igt first, then kernel, just to avoid hiccups
in CI.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_gem.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b2e3b5cfccb4a..80915467e0d84 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -374,10 +374,17 @@ int
> i915_gem_pread_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_pread *args = data;
> struct drm_i915_gem_object *obj;
> int ret;
>
> + /* PREAD is disallowed for all platforms after TGL-LP. This also
> + * covers all platforms with local memory.
> + */
> + if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
> + return -EOPNOTSUPP;
> +
> if (args->size == 0)
> return 0;
>
> @@ -675,10 +682,17 @@ int
> i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_pwrite *args = data;
> struct drm_i915_gem_object *obj;
> int ret;
>
> + /* PWRITE is disallowed for all platforms after TGL-LP. This also
> + * covers all platforms with local memory.
> + */
> + if (INTEL_GEN(i915) >= 12 && !IS_TIGERLAKE(i915))
> + return -EOPNOTSUPP;
> +
> if (args->size == 0)
> return 0;
>
> --
> 2.29.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/14] drm/i915/bios: add helper functions to check output support
On Wed, 17 Mar 2021, Lucas De Marchi wrote:
> On Wed, Mar 17, 2021 at 06:36:49PM +0200, Jani Nikula wrote:
>>These will be exposed to the rest of the driver and replace other
>>functions. Everything will operate on the child devices.
>>
>>v2:
>>- Rebased, removed stray blank line
>>- Also abstracted intel_bios_encoder_supports_crt (Lucas)
>>
>>Cc: Lucas De Marchi
>>Cc: Ville Syrjälä
>>Signed-off-by: Jani Nikula
>>---
>> drivers/gpu/drm/i915/display/intel_bios.c | 71 +++
>> 1 file changed, 59 insertions(+), 12 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>>b/drivers/gpu/drm/i915/display/intel_bios.c
>>index 40fd60acd548..43cb5048ab9a 100644
>>--- a/drivers/gpu/drm/i915/display/intel_bios.c
>>+++ b/drivers/gpu/drm/i915/display/intel_bios.c
>>@@ -1795,6 +1795,59 @@ static int parse_bdb_216_dp_max_link_rate(const int
>>vbt_max_link_rate)
>> }
>> }
>>
>>+static void sanitize_device_type(struct intel_bios_encoder_data *devdata,
>>+ enum port port)
>>+{
>>+ struct drm_i915_private *i915 = devdata->i915;
>>+ bool is_hdmi;
>>+
>>+ if (port != PORT_A || INTEL_GEN(i915) >= 12)
>>+ return;
>>+
>>+ if (!(devdata->child.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING))
>>+ return;
>>+
>>+ is_hdmi = !(devdata->child.device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT);
>>+
>>+ drm_dbg_kms(&i915->drm, "VBT claims port A supports DVI%s, ignoring\n",
>>+ is_hdmi ? "/HDMI" : "");
>
> nit: a little more readable if this function uses the helpers you just
> defined:
>
>
> if (!intel_bios_encoder_supports_dvi(devdata))
> return;
>
> drm_dbg_kms(&i915->drm, "VBT claims port A supports DVI%s, ignoring\n",
> intel_bios_encoder_supports_hdmi(devdata) ? "/HDMI" : "");
>
>
> although the lines below are manipulating the device_type and may be
> good to let the constants here, too. Up to you.
I don't disagree, but saved this for future cleanup.
BR,
Jani.
>
> Reviewed-by: Lucas De Marchi
>
> Lucas De Marchi
>
>
>>+
>>+ devdata->child.device_type &= ~DEVICE_TYPE_TMDS_DVI_SIGNALING;
>>+ devdata->child.device_type |= DEVICE_TYPE_NOT_HDMI_OUTPUT;
>>+}
>>+
>>+static bool
>>+intel_bios_encoder_supports_crt(const struct intel_bios_encoder_data
>>*devdata)
>>+{
>>+ return devdata->child.device_type & DEVICE_TYPE_ANALOG_OUTPUT;
>>+}
>>+
>>+static bool
>>+intel_bios_encoder_supports_dvi(const struct intel_bios_encoder_data
>>*devdata)
>>+{
>>+ return devdata->child.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
>>+}
>>+
>>+static bool
>>+intel_bios_encoder_supports_hdmi(const struct intel_bios_encoder_data
>>*devdata)
>>+{
>>+ return intel_bios_encoder_supports_dvi(devdata) &&
>>+ (devdata->child.device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT) == 0;
>>+}
>>+
>>+static bool
>>+intel_bios_encoder_supports_dp(const struct intel_bios_encoder_data *devdata)
>>+{
>>+ return devdata->child.device_type & DEVICE_TYPE_DISPLAYPORT_OUTPUT;
>>+}
>>+
>>+static bool
>>+intel_bios_encoder_supports_edp(const struct intel_bios_encoder_data
>>*devdata)
>>+{
>>+ return intel_bios_encoder_supports_dp(devdata) &&
>>+ devdata->child.device_type & DEVICE_TYPE_INTERNAL_CONNECTOR;
>>+}
>>+
>> static void parse_ddi_port(struct drm_i915_private *i915,
>> struct intel_bios_encoder_data *devdata)
>> {
>>@@ -1816,19 +1869,13 @@ static void parse_ddi_port(struct drm_i915_private
>>*i915,
>> return;
>> }
>>
>>- is_dvi = child->device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
>>- is_dp = child->device_type & DEVICE_TYPE_DISPLAYPORT_OUTPUT;
>>- is_crt = child->device_type & DEVICE_TYPE_ANALOG_OUTPUT;
>>- is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT)
>>== 0;
>>- is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
>>+ sanitize_device_type(devdata, port);
>>
>>- if (port == PORT_A && is_dvi && INTEL_GEN(i915) < 12) {
>>- drm_dbg_kms(&i915->drm,
>>- "VBT claims port A supports DVI%s, ignoring\n",
>>- is_hdmi ? "/HDMI" : "");
>>- is_dvi = false;
>>- is_hdmi = false;
>>- }
>>+ is_dvi = intel_bios_encoder_supports_dvi(devdata);
>>+ is_dp = intel_bios_encoder_supports_dp(devdata);
>>+ is_crt = intel_bios_encoder_supports_crt(devdata);
>>+ is_hdmi = intel_bios_encoder_supports_hdmi(devdata);
>>+ is_edp = intel_bios_encoder_supports_edp(devdata);
>>
>> info->supports_dvi = is_dvi;
>> info->supports_hdmi = is_hdmi;
>>--
>>2.20.1
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx
Re: [Intel-gfx] [PATCH v2 03/14] drm/i915/bios: reduce indent in sanitize_ddc_pin and sanitize_aux_ch
On Wed, 17 Mar 2021, Lucas De Marchi wrote:
> On Wed, Mar 17, 2021 at 06:36:42PM +0200, Jani Nikula wrote:
>>Reduce indent with an early return. No functional changes.
>>
>>Signed-off-by: Jani Nikula
>>---
>> drivers/gpu/drm/i915/display/intel_bios.c | 86 +++
>> 1 file changed, 41 insertions(+), 45 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>>b/drivers/gpu/drm/i915/display/intel_bios.c
>>index 824148063451..5e7dc0899ab1 100644
>>--- a/drivers/gpu/drm/i915/display/intel_bios.c
>>+++ b/drivers/gpu/drm/i915/display/intel_bios.c
>>@@ -1525,31 +1525,29 @@ static void sanitize_ddc_pin(struct drm_i915_private
>>*i915,
>> return;
>>
>> p = get_port_by_ddc_pin(i915, info->alternate_ddc_pin);
>>- if (p != PORT_NONE) {
>>- drm_dbg_kms(&i915->drm,
>>- "port %c trying to use the same DDC pin (0x%x) as
>>port %c, "
>>- "disabling port %c DVI/HDMI support\n",
>>- port_name(port), info->alternate_ddc_pin,
>>- port_name(p), port_name(p));
>>+ if (p == PORT_NONE)
>>+ return;
>>
>>- /*
>>- * If we have multiple ports supposedly sharing the
>>- * pin, then dvi/hdmi couldn't exist on the shared
>>- * port. Otherwise they share the same ddc bin and
>>- * system couldn't communicate with them separately.
>>- *
>>- * Give inverse child device order the priority,
>>- * last one wins. Yes, there are real machines
>>- * (eg. Asrock B250M-HDV) where VBT has both
>>- * port A and port E with the same AUX ch and
>>- * we must pick port E :(
>>- */
>>- info = &i915->vbt.ddi_port_info[p];
>>+ drm_dbg_kms(&i915->drm,
>>+ "port %c trying to use the same DDC pin (0x%x) as port %c, "
>>+ "disabling port %c DVI/HDMI support\n",
>>+ port_name(port), info->alternate_ddc_pin,
>>+ port_name(p), port_name(p));
>>
>>- info->supports_dvi = false;
>>- info->supports_hdmi = false;
>>- info->alternate_ddc_pin = 0;
>>- }
>>+ /*
>>+ * If we have multiple ports supposedly sharing the pin, then dvi/hdmi
>>+ * couldn't exist on the shared port. Otherwise they share the same ddc
>>+ * bin and system couldn't communicate with them separately.
>>+ *
>>+ * Give inverse child device order the priority, last one wins. Yes,
>>+ * there are real machines (eg. Asrock B250M-HDV) where VBT has both
>>+ * port A and port E with the same AUX ch and we must pick port E :(
>>+ */
>>+ info = &i915->vbt.ddi_port_info[p];
>>+
>>+ info->supports_dvi = false;
>>+ info->supports_hdmi = false;
>>+ info->alternate_ddc_pin = 0;
>> }
>>
>> static enum port get_port_by_aux_ch(struct drm_i915_private *i915, u8 aux_ch)
>>@@ -1577,30 +1575,28 @@ static void sanitize_aux_ch(struct drm_i915_private
>>*i915,
>> return;
>>
>> p = get_port_by_aux_ch(i915, info->alternate_aux_channel);
>>- if (p != PORT_NONE) {
>>- drm_dbg_kms(&i915->drm,
>>- "port %c trying to use the same AUX CH (0x%x) as
>>port %c, "
>>- "disabling port %c DP support\n",
>>- port_name(port), info->alternate_aux_channel,
>>- port_name(p), port_name(p));
>>+ if (p == PORT_NONE)
>>+ return;
>>
>>- /*
>>- * If we have multiple ports supposedlt sharing the
>>- * aux channel, then DP couldn't exist on the shared
>>- * port. Otherwise they share the same aux channel
>>- * and system couldn't communicate with them separately.
>>- *
>>- * Give inverse child device order the priority,
>>- * last one wins. Yes, there are real machines
>>- * (eg. Asrock B250M-HDV) where VBT has both
>>- * port A and port E with the same AUX ch and
>>- * we must pick port E :(
>>- */
>>- info = &i915->vbt.ddi_port_info[p];
>>+ drm_dbg_kms(&i915->drm,
>>+ "port %c trying to use the same AUX CH (0x%x) as port %c, "
>>+ "disabling port %c DP support\n",
>>+ port_name(port), info->alternate_aux_channel,
>>+ port_name(p), port_name(p));
>>
>>- info->supports_dp = false;
>>- info->alternate_aux_channel = 0;
>>- }
>>+ /*
>>+ * If we have multiple ports supposedlt sharing the aux channel, then DP
>
> and another typo: supposedly. Might as well be a patch on top fixing
> these, up to you.
As they're just comments, I took the liberty of fixing while pushing.
Pushed the entire series, thanks for the review.
BR,
Jani.
>
Re: [Intel-gfx] [PULL] drm-misc-fixes
On Thu, Mar 18, 2021 at 12:33 PM Maarten Lankhorst wrote: > > drm-misc-fixes-2021-03-18: > drm-misc-fixes for v5.12-rc4: > - Make ttm_bo_unpin() not wraparound on too many unpins. > - Fix coccicheck warning in omap. Still missing the 2 patches from drm-misc-next-fixes, and those being left out also means drm-misc-next isn't pushed to for-linux-next branch, which is causing a ton of confusion itself. -Daniel > The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: > > drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 > > for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: > > drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 > 13:59:23 +0200) > > > drm-misc-fixes for v5.12-rc4: > - Make ttm_bo_unpin() not wraparound on too many unpins. > - Fix coccicheck warning in omap. > > > Christian König (1): > drm/ttm: make ttm_bo_unpin more defensive > > Junlin Yang (1): > drm/omap: dsi: fix unsigned expression compared with zero > > drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- > include/drm/ttm/ttm_bo_api.h | 6 -- > 2 files changed, 8 insertions(+), 5 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel - Covering for Rodrigo during his absence this week. drm-intel-fixes-2021-03-18: drm/i915 fixes for v5.12-rc4: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ BR, Jani. The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0: Linux 5.12-rc3 (2021-03-14 14:41:02 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2021-03-18 for you to fetch changes up to 6a77c6bb7260bd5000f95df454d9f8cdb1af7132: i915/perf: Start hrtimer only if sampling the OA buffer (2021-03-17 12:51:37 +0200) drm/i915 fixes for v5.12-rc4: - Workaround async flip + VT-d frame corruption on HSW/BDW - Fix NMI watchdog crash due to uninitialized OA buffer use on gen12+ Umesh Nerlige Ramappa (1): i915/perf: Start hrtimer only if sampling the OA buffer Ville Syrjälä (1): drm/i915: Workaround async flip + VT-d corruption on HSW/BDW drivers/gpu/drm/i915/i915_perf.c | 13 + drivers/gpu/drm/i915/i915_reg.h | 23 ++- drivers/gpu/drm/i915/intel_pm.c | 16 +++- 3 files changed, 42 insertions(+), 10 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
drm-misc-fixes-2021-03-18: drm-misc-fixes for v5.12-rc4: - Make ttm_bo_unpin() not wraparound on too many unpins. - Fix coccicheck warning in omap. The following changes since commit de066e116306baf3a6a62691ac63cfc0b1dabddb: drm/compat: Clear bounce structures (2021-03-11 11:11:33 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2021-03-18 for you to fetch changes up to 6909115442759efef3d4bc5d9c54d7943f1afc14: drm/omap: dsi: fix unsigned expression compared with zero (2021-03-17 13:59:23 +0200) drm-misc-fixes for v5.12-rc4: - Make ttm_bo_unpin() not wraparound on too many unpins. - Fix coccicheck warning in omap. Christian König (1): drm/ttm: make ttm_bo_unpin more defensive Junlin Yang (1): drm/omap: dsi: fix unsigned expression compared with zero drivers/gpu/drm/omapdrm/dss/dsi.c | 7 --- include/drm/ttm/ttm_bo_api.h | 6 -- 2 files changed, 8 insertions(+), 5 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Drop the CONTEXT_CLONE API
On 17/03/2021 23:40, Jason Ekstrand wrote:
It's never been used by any real userspace. It's used by IGT as a
short-cut for sharing VMs and other stuff between contexts.
I haven't checked if userspace uses this so assuming that is fine, the
only thing that remains is preparing the IGTs for the transition which
cannot be avoided.
Regards,
Tvrtko
Signed-off-by: Jason Ekstrand
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 217 +---
include/uapi/drm/i915_drm.h | 16 +-
2 files changed, 6 insertions(+), 227 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ca37d93ef5e78..92256f4e50764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -2103,225 +2103,14 @@ static int create_setparam(struct i915_user_extension
__user *ext, void *data)
return ctx_setparam(arg->fpriv, arg->ctx, &local.param);
}
-static int copy_ring_size(struct intel_context *dst,
- struct intel_context *src)
+static int invalid_ext(struct i915_user_extension __user *ext, void *data)
{
- long sz;
-
- sz = intel_context_get_ring_size(src);
- if (sz < 0)
- return sz;
-
- return intel_context_set_ring_size(dst, sz);
-}
-
-static int clone_engines(struct i915_gem_context *dst,
-struct i915_gem_context *src)
-{
- struct i915_gem_engines *clone, *e;
- bool user_engines;
- unsigned long n;
-
- e = __context_engines_await(src, &user_engines);
- if (!e)
- return -ENOENT;
-
- clone = alloc_engines(e->num_engines);
- if (!clone)
- goto err_unlock;
-
- for (n = 0; n < e->num_engines; n++) {
- struct intel_engine_cs *engine;
-
- if (!e->engines[n]) {
- clone->engines[n] = NULL;
- continue;
- }
- engine = e->engines[n]->engine;
-
- /*
-* Virtual engines are singletons; they can only exist
-* inside a single context, because they embed their
-* HW context... As each virtual context implies a single
-* timeline (each engine can only dequeue a single request
-* at any time), it would be surprising for two contexts
-* to use the same engine. So let's create a copy of
-* the virtual engine instead.
-*/
- if (intel_engine_is_virtual(engine))
- clone->engines[n] =
- intel_execlists_clone_virtual(engine);
- else
- clone->engines[n] = intel_context_create(engine);
- if (IS_ERR_OR_NULL(clone->engines[n])) {
- __free_engines(clone, n);
- goto err_unlock;
- }
-
- intel_context_set_gem(clone->engines[n], dst);
-
- /* Copy across the preferred ringsize */
- if (copy_ring_size(clone->engines[n], e->engines[n])) {
- __free_engines(clone, n + 1);
- goto err_unlock;
- }
- }
- clone->num_engines = n;
- i915_sw_fence_complete(&e->fence);
-
- /* Serialised by constructor */
- engines_idle_release(dst, rcu_replace_pointer(dst->engines, clone, 1));
- if (user_engines)
- i915_gem_context_set_user_engines(dst);
- else
- i915_gem_context_clear_user_engines(dst);
- return 0;
-
-err_unlock:
- i915_sw_fence_complete(&e->fence);
- return -ENOMEM;
-}
-
-static int clone_flags(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- dst->user_flags = src->user_flags;
- return 0;
-}
-
-static int clone_schedattr(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- dst->sched = src->sched;
- return 0;
-}
-
-static int clone_sseu(struct i915_gem_context *dst,
- struct i915_gem_context *src)
-{
- struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
- struct i915_gem_engines *clone;
- unsigned long n;
- int err;
-
- /* no locking required; sole access under constructor*/
- clone = __context_engines_static(dst);
- if (e->num_engines != clone->num_engines) {
- err = -EINVAL;
- goto unlock;
- }
-
- for (n = 0; n < e->num_engines; n++) {
- struct intel_context *ce = e->engines[n];
-
- if (clone->engines[n]->engine->class != ce->engine->class) {
- /* Must have compatible engine maps! */
- err = -EINVAL;
- goto unlock;
-
Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote: > > > On 2/11/2021 7:34 AM, Daniel Vetter wrote: > > On Wed, Feb 10, 2021 at 02:00:57PM -0800, Brian Welty wrote: > >> > >> On 2/9/2021 2:54 AM, Daniel Vetter wrote: > >>> On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote: > This patch adds tracking of which cgroup to make charges against for a > given GEM object. We associate the current task's cgroup with GEM > objects > as they are created. First user of this is for charging DRM cgroup for > device memory allocations. The intended behavior is for device drivers > to > make the cgroup charging calls at the time that backing store is > allocated > or deallocated for the object. > > Exported functions are provided for charging memory allocations for a > GEM object to DRM cgroup. To aid in debugging, we store how many bytes > have been charged inside the GEM object. Add helpers for setting and > clearing the object's associated cgroup which will check that charges are > not being leaked. > > For shared objects, this may make the charge against a cgroup that is > potentially not the same cgroup as the process using the memory. Based > on the memory cgroup's discussion of "memory ownership", this seems > acceptable [1]. > > [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory > Ownership" > > Signed-off-by: Brian Welty > >>> > >>> Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that > >>> counts everything, why don't we also charge in these gem functions? > >> > >> I'm not sure what you mean exactly. You want to merge/move the charging > >> logic > >> proposed in patch #5 (drm_cgroup_try_charge in kernel/cgroup/drm.c) into > >> drm_gem_object_charge_mem() ? > >> > >> Or reading below, I think you are okay keeping the logic separated as is, > >> but > >> you want much of the code in kernel/cgroup/drm.c moved to > >> drivers/gpu/cgroup ? > >> Yes, I see that should allow to reduce number of exported functions. > > > > Both. I mean we'd need to look at the code again when it's shuffled, but > > I'd say: > > > > - cgroup code and the charging for general gpu memory moves to > > drivers/gpu/cgroup, so dma-buf heaps can use it too. > > > > - the charging for gem buffers moves into core gem code, so it happens for > > all gpu drivers and all gem buffer allocations. > > Daniel, I'm not sure we're in sync on what 'charging for general gpu memory' > means. Thus far, I have been proposing to charge/uncharge when backing store > is > allocated/freed. And thus, this would be done in DRM driver (so then also in > the dma-buf exporter). > I can't see how we'd hoist this part into drm gem code. > The memory limit in this series is for VRAM usage/limit not GEM buffers... Yes this would be at gem buffer creation time. And just to get cgroups for drm up&running. > Unless you are talking about charging for GEM buffer creation? But this is > more of a 'soft resource' more along lines of Kenny's earlier GEM buffer limit > control. > I raised issue with this then, and at the time, Tejun agreed we should keep to > 'hard resource' controls, see [1] and [2]. > > [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/218071.html > [2] https://lists.freedesktop.org/archives/dri-devel/2020-April/262141.html > > > > > - this might or might not mean a bunch less exported stuff from the > > cgroups files (since you don't need separate steps for linking a gem > > object to a cgroup from the actual charging), and probably no exports > > anymore for drivers (since they charge nothing). That will change > > when we add charging for specific memory pools I guess, but we add that > > when we add tha functionality. > > ... so considering VRAM charging, then yes, we very much need to have exported > functions for drivers to do the charging. > But these can be exported from drm.ko (or new .ko?) instead of kernel. Is > that still preference? Also, if number of exported functions is concern, we > can replace some of it with use of function pointers. So the reason I suggested we drop all this is because we won't charge in drivers, we'll charge in ttm buffer management code. Which we'll adopt for dg1 in upstream. But it will take some time. > So then returning to this comment of yours: > > > - cgroup code and the charging for general gpu memory moves to > > drivers/gpu/cgroup, so dma-buf heaps can use it too. > > If you agree that we are charging just at backing-store level, then I think > logic belongs in drivers/gpu/drm/cgroup ?? As charging is done in DRM driver > (also dma-buf exporter). In other words, part of drm. > If I understand, dma-buf heaps is exporter of system memory and doesn't > need to charge against gpu controller?? > Will need some help to understand the dma-buf heap use case a bit more. Well we also need to track s
