[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
== Series Details == Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER URL : https://patchwork.freedesktop.org/series/95982/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21376_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21376_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-apl2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#2481] / [i915#3070]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-iclb1/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb8/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-glk8/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fence@nb-await@vecs0: - shard-skl: [PASS][12] -> [DMESG-WARN][13] ([i915#1982]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-skl3/igt@gem_exec_fence@nb-aw...@vecs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-skl7/igt@gem_exec_fence@nb-aw...@vecs0.html * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109283]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@gem_exec_par...@no-blt.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#112283]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb5/igt@gem_exec_par...@secure-non-master.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][16] -> [SKIP][17] ([i915#2190]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb2/igt@gem_huc_c...@huc-copy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb6/igt@gem_huc_c...@huc-copy.html - shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-kbl7/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@coherency: - shard-tglb: NOTRUN -> [SKIP][19] ([fdo#111656]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@gem_mmap_...@coherency.html * igt@gem_pread@exhaustion: - shard-tglb: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@gem_pr...@exhaustion.html * igt@gem_pxp@reject-modify-context-protection-on: - shard-tglb: NOTRUN -> [SKIP][21] ([i915#4270]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-tglb8/igt@gem_...@reject-modify-context-protection-on.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][22] ([i915#768]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/shard-iclb6/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-yf-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#3323]) [23]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move PCH modeset code into its own file (rev2)
== Series Details == Series: drm/i915: Move PCH modeset code into its own file (rev2) URL : https://patchwork.freedesktop.org/series/95863/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21375_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21375_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-apl2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-hostile: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-hostile.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html - shard-kbl: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-kbl3/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109283]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-iclb2/igt@gem_exec_par...@no-blt.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][10] ([fdo#112283]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-iclb2/igt@gem_exec_par...@secure-non-master.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-kbl4/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@coherency: - shard-tglb: NOTRUN -> [SKIP][12] ([fdo#111656]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@gem_mmap_...@coherency.html * igt@gem_pread@exhaustion: - shard-tglb: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@gem_pr...@exhaustion.html * igt@gem_pxp@reject-modify-context-protection-on: - shard-tglb: NOTRUN -> [SKIP][14] ([i915#4270]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@gem_...@reject-modify-context-protection-on.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][15] ([i915#768]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-iclb2/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-yf-tiled.html * igt@gem_userptr_blits@invalid-mmap-offset-unsync: - shard-iclb: NOTRUN -> [SKIP][16] ([i915#3297]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-iclb2/igt@gem_userptr_bl...@invalid-mmap-offset-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-tglb: NOTRUN -> [FAIL][17] ([i915#3318]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@gem_userptr_bl...@vma-merge.html * igt@gen7_exec_parse@oacontrol-tracking: - shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109289]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@gen7_exec_pa...@oacontrol-tracking.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-tglb: NOTRUN -> [WARN][19] ([i915#2681]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@kms_atomic_transition@plane-all-modeset-transition: - shard-tglb: NOTRUN -> [SKIP][20] ([i915#1769]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/shard-tglb6/igt@kms_atomic_transit...@plane-all-modeset-transition.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3777]) [21]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2)
== Series Details == Series: drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2) URL : https://patchwork.freedesktop.org/series/95948/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21374_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21374_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21374_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_21374_full: ### IGT changes ### Possible regressions * igt@kms_bw@linear-tiling-4-displays-1920x1080p: - shard-apl: NOTRUN -> [FAIL][1] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-apl3/igt@kms...@linear-tiling-4-displays-1920x1080p.html Warnings * igt@kms_bw@linear-tiling-3-displays-2560x1440p: - shard-apl: [DMESG-FAIL][2] ([i915#4298]) -> [FAIL][3] +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-apl7/igt@kms...@linear-tiling-3-displays-2560x1440p.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-apl7/igt@kms...@linear-tiling-3-displays-2560x1440p.html Known issues Here are the changes found in Patchwork_21374_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][4] ([i915#3002]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-apl3/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#1373]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb1/igt@gem_ctx_isolation@preservation...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-tglb7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_param@set-priority-not-supported: - shard-iclb: NOTRUN -> [SKIP][7] ([fdo#109314]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@legacy-engines-hostile: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-hostile.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: NOTRUN -> [FAIL][9] ([i915#2410]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][10] -> [TIMEOUT][11] ([i915#2369] / [i915#3063] / [i915#3648]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb2/igt@gem_...@unwedge-stress.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-glk9/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109283]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-iclb4/igt@gem_exec_par...@no-blt.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#112283]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-iclb4/igt@gem_exec_par...@secure-non-master.html * igt@gem_exec_schedule@u-semaphore-user: - shard-snb: NOTRUN -> [SKIP][19] ([fdo#109271]) +195 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/shard-snb7/igt@gem_exec_sched...@u-semaphore-user.html * igt@gem_huc_copy@huc-copy: - shard-kbl:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Remove unused assignment
== Series Details == Series: drm/i915/display: Remove unused assignment URL : https://patchwork.freedesktop.org/series/95967/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21373_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21373_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: NOTRUN -> [FAIL][2] ([i915#2410]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][3] ([i915#3354]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][4] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-kbl4/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-tglb8/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109283]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-iclb4/igt@gem_exec_par...@no-blt.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][10] ([fdo#112283]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-iclb4/igt@gem_exec_par...@secure-non-master.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-kbl4/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][12] ([i915#768]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-iclb4/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-yf-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3323]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-apl2/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@invalid-mmap-offset-unsync: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#3297]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-iclb4/igt@gem_userptr_bl...@invalid-mmap-offset-unsync.html * igt@gen7_exec_parse@basic-rejected: - shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-tglb1/igt@gen7_exec_pa...@basic-rejected.html * igt@kms_atomic_transition@plane-all-transition-nonblocking-fencing@edp-1-pipe-a: - shard-skl: [PASS][16] -> [DMESG-WARN][17] ([i915#1982]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-skl7/igt@kms_atomic_transition@plane-all-transition-nonblocking-fenc...@edp-1-pipe-a.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-skl7/igt@kms_atomic_transition@plane-all-transition-nonblocking-fenc...@edp-1-pipe-a.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-hflip: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3777]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-apl6/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-hflip.html * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#110723]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/shard-iclb4/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180.html * igt@kms_bw@linear-tiling-1-displays-3840x2160p: - shard-snb: NOTRUN -> [FAIL][20] ([i915#4299]) [20]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Remove unused variable and its assignment.
== Series Details == Series: drm/i915/display: Remove unused variable and its assignment. URL : https://patchwork.freedesktop.org/series/95966/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21372_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21372_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21372_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_21372_full: ### IGT changes ### Possible regressions * igt@kms_atomic_interruptible@universal-setplane-cursor@edp-1-pipe-a: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb7/igt@kms_atomic_interruptible@universal-setplane-cur...@edp-1-pipe-a.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-tglb8/igt@kms_atomic_interruptible@universal-setplane-cur...@edp-1-pipe-a.html Known issues Here are the changes found in Patchwork_21372_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#1373]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb1/igt@gem_ctx_isolation@preservation...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-tglb7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_ctx_shared@q-smoketest-all: - shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#118]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-glk6/igt@gem_ctx_sha...@q-smoketest-all.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-glk4/igt@gem_ctx_sha...@q-smoketest-all.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][8] ([i915#3354]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-glk1/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-kbl6/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-apl1/igt@gem_exec_fair@basic-n...@vcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][17] -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109283]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-iclb1/igt@gem_exec_par...@no-blt.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][20] ([fdo#112283]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/shard-iclb1/igt@gem_exec_par...@secure-non-master.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][21] ->
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Remove unused variable and corresponding assignment
== Series Details == Series: drm/i915/display: Remove unused variable and corresponding assignment URL : https://patchwork.freedesktop.org/series/95965/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21371_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21371_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-apl8/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#3063] / [i915#3648]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb2/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-tglb3/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-snb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs0.html - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#109283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-iclb4/igt@gem_exec_par...@no-blt.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#112283]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-iclb4/igt@gem_exec_par...@secure-non-master.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-kbl1/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@coherency: - shard-tglb: NOTRUN -> [SKIP][16] ([fdo#111656]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-tglb6/igt@gem_mmap_...@coherency.html * igt@gem_pread@exhaustion: - shard-tglb: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-tglb6/igt@gem_pr...@exhaustion.html * igt@gem_pxp@reject-modify-context-protection-on: - shard-tglb: NOTRUN -> [SKIP][18] ([i915#4270]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-tglb6/igt@gem_...@reject-modify-context-protection-on.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#768]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-iclb4/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-yf-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-apl8/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@invalid-mmap-offset-unsync: - shard-iclb: NOTRUN -> [SKIP][21] ([i915#3297]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/shard-iclb4/igt@gem_userptr_bl...@invalid-mmap-offset-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-tglb: NOTRUN -> [FAIL][22] ([i915#3318]) [22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove redundant assignments
== Series Details == Series: drm/i915: Remove redundant assignments URL : https://patchwork.freedesktop.org/series/95964/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753_full -> Patchwork_21370_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21370_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-apl7/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-hostile: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-hostile.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#3063] / [i915#3648]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb2/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-tglb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-glk4/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html - shard-apl: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/shard-apl1/igt@gem_exec_fair@basic-n...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_params@no-blt: - shard-iclb: NOTRUN -> [SKIP][13] ([fdo#109283]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-iclb8/igt@gem_exec_par...@no-blt.html * igt@gem_exec_params@secure-non-master: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#112283]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-iclb8/igt@gem_exec_par...@secure-non-master.html * igt@gem_exec_schedule@u-semaphore-user: - shard-snb: NOTRUN -> [SKIP][15] ([fdo#109271]) +294 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-snb5/igt@gem_exec_sched...@u-semaphore-user.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-kbl4/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@coherency: - shard-tglb: NOTRUN -> [SKIP][17] ([fdo#111656]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-tglb2/igt@gem_mmap_...@coherency.html * igt@gem_pread@exhaustion: - shard-tglb: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-tglb2/igt@gem_pr...@exhaustion.html * igt@gem_pxp@reject-modify-context-protection-on: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#4270]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-tglb2/igt@gem_...@reject-modify-context-protection-on.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-yf-tiled: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#768]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-iclb8/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-yf-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3323]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/shard-apl7/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@invalid-mmap-offset-unsync: - shard-iclb: NOTRUN -> [SKIP][22] ([i915#3297]) [22]:
Re: [Intel-gfx] [PATCH 2/3] drm/amdgpu:move vram manager defines into a header file
Am 13.10.21 um 15:38 schrieb Arunpravin:
Move vram related defines and inline functions into
a separate header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 72
1 file changed, 72 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
new file mode 100644
index ..fcab6475ccbb
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: MIT
+ * Copyright 2021 Advanced Micro Devices, Inc.
+ *
+ * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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.
+ *
+ */
+
+#ifndef __AMDGPU_VRAM_MGR_H__
+#define __AMDGPU_VRAM_MGR_H__
+
+#include
+
+struct amdgpu_vram_mgr_node {
+ struct ttm_resource base;
+ struct list_head blocks;
+ unsigned long flags;
+};
+
+struct amdgpu_vram_reservation {
+ uint64_t start;
+ uint64_t size;
+ uint64_t min_size;
+ unsigned long flags;
+ struct list_head block;
+ struct list_head node;
+};
+
+static inline uint64_t node_start(struct drm_buddy_block *block)
In general please prefix all symbols with amdgpu_...
Then why are you moving the inline functions and structures here? Are
they going to be shared with code outside of the vram_mgr?
If not then please keep them inside the C file instead.
Christian.
+{
+ return drm_buddy_block_offset(block);
+}
+
+static inline uint64_t node_size(struct drm_buddy_block *block)
+{
+ return PAGE_SIZE << drm_buddy_block_order(block);
+}
+
+static inline struct amdgpu_vram_mgr_node *
+to_amdgpu_vram_mgr_node(struct ttm_resource *res)
+{
+ return container_of(res, struct amdgpu_vram_mgr_node, base);
+}
+
+static inline struct amdgpu_vram_mgr *
+to_vram_mgr(struct ttm_resource_manager *man)
+{
+ return container_of(man, struct amdgpu_vram_mgr, manager);
+}
+
+static inline struct amdgpu_device *
+to_amdgpu_device(struct amdgpu_vram_mgr *mgr)
+{
+ return container_of(mgr, struct amdgpu_device, mman.vram_mgr);
+}
+
+#endif
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Connect engine busyness stats from GuC to pmu
On Mon, Oct 18, 2021 at 11:35:44AM -0700, Umesh Nerlige Ramappa wrote: On Mon, Oct 18, 2021 at 08:58:01AM +0100, Tvrtko Ursulin wrote: On 16/10/2021 00:47, Umesh Nerlige Ramappa wrote: With GuC handling scheduling, i915 is not aware of the time that a context is scheduled in and out of the engine. Since i915 pmu relies on this info to provide engine busyness to the user, GuC shares this info with i915 for all engines using shared memory. For each engine, this info contains: - total busyness: total time that the context was running (total) - id: id of the running context (id) - start timestamp: timestamp when the context started running (start) At the time (now) of sampling the engine busyness, if the id is valid (!= ~0), and start is non-zero, then the context is considered to be active and the engine busyness is calculated using the below equation engine busyness = total + (now - start) All times are obtained from the gt clock base. For inactive contexts, engine busyness is just equal to the total. The start and total values provided by GuC are 32 bits and wrap around in a few minutes. Since perf pmu provides busyness as 64 bit monotonically increasing values, there is a need for this implementation to account for overflows and extend the time to 64 bits before returning busyness to the user. In order to do that, a worker runs periodically at frequency = 1/8th the time it takes for the timestamp to wrap. As an example, that would be once in 27 seconds for a gt clock frequency of 19.2 MHz. Note: There might be an overaccounting of busyness due to the fact that GuC may be updating the total and start values while kmd is reading them. (i.e kmd may read the updated total and the stale start). In such a case, user may see higher busyness value followed by smaller ones which would eventually catch up to the higher value. v2: (Tvrtko) - Include details in commit message - Move intel engine busyness function into execlist code - Use union inside engine->stats - Use natural type for ping delay jiffies - Drop active_work condition checks - Use for_each_engine if iterating all engines - Drop seq locking, use spinlock at guc level to update engine stats - Document worker specific details v3: (Tvrtko/Umesh) - Demarcate guc and execlist stat objects with comments - Document known over-accounting issue in commit - Provide a consistent view of guc state - Add hooks to gt park/unpark for guc busyness - Stop/start worker in gt park/unpark path - Drop inline - Move spinlock and worker inits to guc initialization - Drop helpers that are called only once v4: (Tvrtko/Matt/Umesh) - Drop addressed opens from commit message - Get runtime pm in ping, remove from the park path - Use cancel_delayed_work_sync in disable_submission path - Update stats during reset prepare - Skip ping if reset in progress - Explicitly name execlists and guc stats objects - Since disable_submission is called from many places, move resetting stats to intel_guc_submission_reset_prepare v5: (Tvrtko) - Add a trylock helper that does not sleep and synchronize PMU event callbacks and worker with gt reset v6: (CI BAT failures) - DUTs using execlist submission failed to boot since __gt_unpark is called during i915 load. This ends up calling the guc busyness unpark hook and results in kiskstarting an uninitialized worker. Let park/unpark hooks check if guc submission has been initialized. - drop cant_sleep() from trylock hepler since rcu_read_lock takes care of that. v7: (CI) Fix igt@i915_selftest@live@gt_engines - For guc mode of submission the engine busyness is derived from gt time domain. Use gt time elapsed as reference in the selftest. - Increase busyness calculation to 10ms duration to ensure batch runs longer and falls within the busyness tolerances in selftest. [snip] diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c index 75569666105d..24358bef6691 100644 --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c @@ -234,6 +234,7 @@ static int live_engine_busy_stats(void *arg) struct i915_request *rq; ktime_t de, dt; ktime_t t[2]; + u32 gt_stamp; if (!intel_engine_supports_stats(engine)) continue; @@ -251,10 +252,16 @@ static int live_engine_busy_stats(void *arg) ENGINE_TRACE(engine, "measuring idle time\n"); preempt_disable(); de = intel_engine_get_busy_time(engine, [0]); - udelay(100); + gt_stamp = intel_uncore_read(gt->uncore, GUCPMTIMESTAMP); + udelay(1); de = ktime_sub(intel_engine_get_busy_time(engine, [1]), de); + gt_stamp = intel_uncore_read(gt->uncore, GUCPMTIMESTAMP) - gt_stamp; preempt_enable(); - dt = ktime_sub(t[1], t[0]); + + dt =
Re: [Intel-gfx] [PATCH v2 4/9] drm/i915: Move LPT PCH readout code
On Tue, Oct 19, 2021 at 1:35 AM Ville Syrjala wrote: > > From: Ville Syrjälä > > Nuke the hsw_get_ddi_port_state() eyesore by putting the > readout code into intel_pch_display.c, and calling it directly > from hsw_crt_get_config(). > > Note that the nuked TRANS_DDI_FUNC_CTL readout from > hsw_get_ddi_port_state() is now etirely redundant since we > get called from the encoder->get_config() so we already know > we're dealing with the correct DDI port. Previously the > code was called from a place where that wasn't known so > it had to checked manually. > > v2: Clarify the TRANS_DDI_FUNC_CTL change (Dave) > Nuke the now unused *TRANS_DDI_FUNC_CTL_VAL_TO_PORT() (Dave) > > Cc: Dave Airlie > Cc: Jani Nikula > Signed-off-by: Ville Syrjälä Reviewed-by: Dave Airlie
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
== Series Details == Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER URL : https://patchwork.freedesktop.org/series/95982/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21376 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/index.html Known issues Here are the changes found in Patchwork_21376 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html * igt@i915_module_load@reload: - fi-kbl-soraka: [PASS][2] -> [DMESG-WARN][3] ([i915#1982]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-kbl-soraka/igt@i915_module_l...@reload.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-kbl-soraka/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-rte: - fi-skl-6600u: [PASS][4] -> [FAIL][5] ([i915#3049]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-skl-6600u/igt@i915_pm_...@basic-rte.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-skl-6600u/igt@i915_pm_...@basic-rte.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [INCOMPLETE][6] ([i915#2940]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][8] ([i915#4269]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#3049]: https://gitlab.freedesktop.org/drm/intel/issues/3049 [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269 Participating hosts (39 -> 37) -- Missing(2): fi-bsw-cyan bat-dg1-6 Build changes - * Linux: CI_DRM_10753 -> Patchwork_21376 CI-20190529: 20190529 CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21376: ae2c908cf31fc5df4d6767f448ef9d66321fe364 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ae2c908cf31f drm/i915/selftests: mark up hugepages object with start_cpu_write 49bf1fb0cbbe drm/i915: mark up internal objects with start_cpu_write db935401f057 drm/i915: expand on the kernel-doc for cache_dirty 3fd7ed641f99 drm/i915/shmem: ensure flush during swap-in on non-LLC e13b48097394 drm/i915/userptr: add paranoid flush-on-acquire 42a7064ef6ae drm/i915/dmabuf: add paranoid flush-on-acquire fc3555ba8818 drm/i915: extract bypass-llc check into helper 9dfe83b2167d drm/i915: mark userptr objects as ALLOC_USER 1ad5557daeac drm/i915: mark dmabuf objects as ALLOC_USER == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21376/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
== Series Details == Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER URL : https://patchwork.freedesktop.org/series/95982/ 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_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER
== Series Details == Series: series starting with [1/9] drm/i915: mark dmabuf objects as ALLOC_USER URL : https://patchwork.freedesktop.org/series/95982/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1ad5557daeac drm/i915: mark dmabuf objects as ALLOC_USER 9dfe83b2167d drm/i915: mark userptr objects as ALLOC_USER fc3555ba8818 drm/i915: extract bypass-llc check into helper 42a7064ef6ae drm/i915/dmabuf: add paranoid flush-on-acquire e13b48097394 drm/i915/userptr: add paranoid flush-on-acquire 3fd7ed641f99 drm/i915/shmem: ensure flush during swap-in on non-LLC db935401f057 drm/i915: expand on the kernel-doc for cache_dirty 49bf1fb0cbbe drm/i915: mark up internal objects with start_cpu_write -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: While the pages can't be swapped out, they can be discarded by the shrinker. total: 0 errors, 1 warnings, 0 checks, 8 lines checked ae2c908cf31f drm/i915/selftests: mark up hugepages object with start_cpu_write
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move PCH modeset code into its own file (rev2)
== Series Details ==
Series: drm/i915: Move PCH modeset code into its own file (rev2)
URL : https://patchwork.freedesktop.org/series/95863/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21375
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/index.html
Known issues
Here are the changes found in Patchwork_21375 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html
* igt@gem_exec_suspend@basic-s3:
- fi-bdw-samus: [PASS][3] -> [INCOMPLETE][4] ([i915#146])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bdw-samus/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/fi-bdw-samus/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [INCOMPLETE][5] ([i915#2940]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][7] ([i915#3921]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
Participating hosts (39 -> 37)
--
Missing(2): fi-bsw-cyan bat-dg1-6
Build changes
-
* Linux: CI_DRM_10753 -> Patchwork_21375
CI-20190529: 20190529
CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21375: 4f18cafd1f4a074b9c608ef3bb25077ef2f88bc5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4f18cafd1f4a drm/i915: Introduce lpt_pch_disable()
39b8f7cf41e2 drm/i915: Move intel_ddi_fdi_post_disable() to fdi code
4ef845baae54 drm/i915: Introduce ilk_pch_disable() and ilk_pch_post_disable()
43488950420d drm/i915: Move iCLKIP readout to the pch code
4bfd17869e11 drm/i915: Extract ilk_pch_get_config()
25072419a975 drm/i915: Move LPT PCH readout code
3f2c8e4d7c8e drm/i915: Clean up the {ilk, lpt}_pch_enable() calling convention
9346281c5925 drm/i915: Move PCH modeset code to its own file
fe78f7aa4624 drm/i915: Move PCH refclok stuff into its own file
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21375/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move PCH modeset code into its own file (rev2)
== Series Details == Series: drm/i915: Move PCH modeset code into its own file (rev2) URL : https://patchwork.freedesktop.org/series/95863/ 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/display/intel_pch_display.c:437:6: warning: symbol 'lpt_disable_pch_transcoder' was not declared. Should it be static? +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Move PCH modeset code into its own file (rev2)
== Series Details ==
Series: drm/i915: Move PCH modeset code into its own file (rev2)
URL : https://patchwork.freedesktop.org/series/95863/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fe78f7aa4624 drm/i915: Move PCH refclok stuff into its own file
-:803: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#803:
new file mode 100644
-:1003: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#1003: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:196:
+ udelay(24);
-:1070: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#1070: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:263:
+ udelay(24);
-:1106: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#1106: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:299:
+ udelay(32);
-:1118: ERROR:SPACING: space prohibited after that open parenthesis '('
#1118: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:311:
+ [BEND_IDX( 50)] = 0x3B23,
-:1119: ERROR:SPACING: space prohibited after that open parenthesis '('
#1119: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:312:
+ [BEND_IDX( 45)] = 0x3B23,
-:1120: ERROR:SPACING: space prohibited after that open parenthesis '('
#1120: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:313:
+ [BEND_IDX( 40)] = 0x3C23,
-:1121: ERROR:SPACING: space prohibited after that open parenthesis '('
#1121: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:314:
+ [BEND_IDX( 35)] = 0x3C23,
-:1122: ERROR:SPACING: space prohibited after that open parenthesis '('
#1122: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:315:
+ [BEND_IDX( 30)] = 0x3D23,
-:1123: ERROR:SPACING: space prohibited after that open parenthesis '('
#1123: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:316:
+ [BEND_IDX( 25)] = 0x3D23,
-:1124: ERROR:SPACING: space prohibited after that open parenthesis '('
#1124: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:317:
+ [BEND_IDX( 20)] = 0x3E23,
-:1125: ERROR:SPACING: space prohibited after that open parenthesis '('
#1125: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:318:
+ [BEND_IDX( 15)] = 0x3E23,
-:1126: ERROR:SPACING: space prohibited after that open parenthesis '('
#1126: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:319:
+ [BEND_IDX( 10)] = 0x3F23,
-:1127: ERROR:SPACING: space prohibited after that open parenthesis '('
#1127: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:320:
+ [BEND_IDX( 5)] = 0x3F23,
-:1128: ERROR:SPACING: space prohibited after that open parenthesis '('
#1128: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:321:
+ [BEND_IDX( 0)] = 0x0025,
-:1129: ERROR:SPACING: space prohibited after that open parenthesis '('
#1129: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:322:
+ [BEND_IDX( -5)] = 0x0025,
-:1395: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#1395: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:588:
+ udelay(200);
-:1414: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#1414: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:607:
+ udelay(200);
-:1425: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#1425: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:618:
+ udelay(200);
-:1439: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.rst
#1439: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:632:
+ udelay(200);
-:1443: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON &
recovery code rather than BUG() or BUG_ON()
#1443: FILE: drivers/gpu/drm/i915/display/intel_pch_refclk.c:636:
+ BUG_ON(val != final);
total: 12 errors, 2 warnings, 7 checks, 1411 lines checked
9346281c5925 drm/i915: Move PCH modeset code to its own file
-:454: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#454:
new file mode 100644
-:765: CHECK:SPACING: No space is necessary after a cast
#765: FILE: drivers/gpu/drm/i915/display/intel_pch_display.c:307:
+ assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
total: 0 errors, 1 warnings, 1 checks, 796 lines checked
3f2c8e4d7c8e drm/i915: Clean up the {ilk, lpt}_pch_enable() calling convention
25072419a975 drm/i915: Move LPT PCH readout code
4bfd17869e11 drm/i915: Extract ilk_pch_get_config()
-:193: CHECK:SPACING: No space is necessary after a cast
#193: FILE: drivers/gpu/drm/i915/display/intel_pch_display.c:346:
+ pll_id = (enum intel_dpll_id) pipe;
total: 0
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Connect engine busyness stats from GuC to pmu
On Mon, Oct 18, 2021 at 08:58:01AM +0100, Tvrtko Ursulin wrote: On 16/10/2021 00:47, Umesh Nerlige Ramappa wrote: With GuC handling scheduling, i915 is not aware of the time that a context is scheduled in and out of the engine. Since i915 pmu relies on this info to provide engine busyness to the user, GuC shares this info with i915 for all engines using shared memory. For each engine, this info contains: - total busyness: total time that the context was running (total) - id: id of the running context (id) - start timestamp: timestamp when the context started running (start) At the time (now) of sampling the engine busyness, if the id is valid (!= ~0), and start is non-zero, then the context is considered to be active and the engine busyness is calculated using the below equation engine busyness = total + (now - start) All times are obtained from the gt clock base. For inactive contexts, engine busyness is just equal to the total. The start and total values provided by GuC are 32 bits and wrap around in a few minutes. Since perf pmu provides busyness as 64 bit monotonically increasing values, there is a need for this implementation to account for overflows and extend the time to 64 bits before returning busyness to the user. In order to do that, a worker runs periodically at frequency = 1/8th the time it takes for the timestamp to wrap. As an example, that would be once in 27 seconds for a gt clock frequency of 19.2 MHz. Note: There might be an overaccounting of busyness due to the fact that GuC may be updating the total and start values while kmd is reading them. (i.e kmd may read the updated total and the stale start). In such a case, user may see higher busyness value followed by smaller ones which would eventually catch up to the higher value. v2: (Tvrtko) - Include details in commit message - Move intel engine busyness function into execlist code - Use union inside engine->stats - Use natural type for ping delay jiffies - Drop active_work condition checks - Use for_each_engine if iterating all engines - Drop seq locking, use spinlock at guc level to update engine stats - Document worker specific details v3: (Tvrtko/Umesh) - Demarcate guc and execlist stat objects with comments - Document known over-accounting issue in commit - Provide a consistent view of guc state - Add hooks to gt park/unpark for guc busyness - Stop/start worker in gt park/unpark path - Drop inline - Move spinlock and worker inits to guc initialization - Drop helpers that are called only once v4: (Tvrtko/Matt/Umesh) - Drop addressed opens from commit message - Get runtime pm in ping, remove from the park path - Use cancel_delayed_work_sync in disable_submission path - Update stats during reset prepare - Skip ping if reset in progress - Explicitly name execlists and guc stats objects - Since disable_submission is called from many places, move resetting stats to intel_guc_submission_reset_prepare v5: (Tvrtko) - Add a trylock helper that does not sleep and synchronize PMU event callbacks and worker with gt reset v6: (CI BAT failures) - DUTs using execlist submission failed to boot since __gt_unpark is called during i915 load. This ends up calling the guc busyness unpark hook and results in kiskstarting an uninitialized worker. Let park/unpark hooks check if guc submission has been initialized. - drop cant_sleep() from trylock hepler since rcu_read_lock takes care of that. v7: (CI) Fix igt@i915_selftest@live@gt_engines - For guc mode of submission the engine busyness is derived from gt time domain. Use gt time elapsed as reference in the selftest. - Increase busyness calculation to 10ms duration to ensure batch runs longer and falls within the busyness tolerances in selftest. [snip] diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c index 75569666105d..24358bef6691 100644 --- a/drivers/gpu/drm/i915/gt/selftest_engine_pm.c +++ b/drivers/gpu/drm/i915/gt/selftest_engine_pm.c @@ -234,6 +234,7 @@ static int live_engine_busy_stats(void *arg) struct i915_request *rq; ktime_t de, dt; ktime_t t[2]; + u32 gt_stamp; if (!intel_engine_supports_stats(engine)) continue; @@ -251,10 +252,16 @@ static int live_engine_busy_stats(void *arg) ENGINE_TRACE(engine, "measuring idle time\n"); preempt_disable(); de = intel_engine_get_busy_time(engine, [0]); - udelay(100); + gt_stamp = intel_uncore_read(gt->uncore, GUCPMTIMESTAMP); + udelay(1); de = ktime_sub(intel_engine_get_busy_time(engine, [1]), de); + gt_stamp = intel_uncore_read(gt->uncore, GUCPMTIMESTAMP) - gt_stamp; preempt_enable(); - dt = ktime_sub(t[1], t[0]); + + dt = intel_engine_uses_guc(engine) ? +
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2)
== Series Details == Series: drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2) URL : https://patchwork.freedesktop.org/series/95948/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21374 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/index.html Known issues Here are the changes found in Patchwork_21374 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_suspend@basic-s0: - fi-tgl-1115g4: [PASS][2] -> [FAIL][3] ([i915#1888]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][4] ([i915#3921]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 Participating hosts (39 -> 37) -- Missing(2): fi-bsw-cyan bat-dg1-6 Build changes - * Linux: CI_DRM_10753 -> Patchwork_21374 CI-20190529: 20190529 CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21374: d94f0647dd7812e0f536f8199860568c6a0d2cf9 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d94f0647dd78 drm/i915/dp: Sanitize link common rate array lookups f2bd5e3e941b drm/i915/dp: Sanitize sink rate DPCD register values 66b542816538 drm/i915/dp: Ensure sink/link max lane count values are always valid ef437e0c551b drm/i915/dp: Ensure max link params are always valid 4de2ca096081 drm/i915/dp: Ensure sink rate values are always valid 8f1a6421dfe5 drm/i915/dp: Skip the HW readout of DPCD on disabled encoders == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21374/index.html
[Intel-gfx] [PATCH 9/9] drm/i915/selftests: mark up hugepages object with start_cpu_write
Just like we do for internal objects. Also just use
i915_gem_object_set_cache_coherency() here. No need for over-flushing on
LLC platforms.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 41d0680f3bd7..b2003133deaf 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -136,6 +136,8 @@ static void put_huge_pages(struct drm_i915_gem_object *obj,
huge_pages_free_pages(pages);
obj->mm.dirty = false;
+
+ __start_cpu_write(obj);
}
static const struct drm_i915_gem_object_ops huge_page_ops = {
@@ -152,6 +154,7 @@ huge_pages_object(struct drm_i915_private *i915,
{
static struct lock_class_key lock_class;
struct drm_i915_gem_object *obj;
+ unsigned int cache_level;
GEM_BUG_ON(!size);
GEM_BUG_ON(!IS_ALIGNED(size, BIT(__ffs(page_mask;
@@ -173,7 +176,9 @@ huge_pages_object(struct drm_i915_private *i915,
obj->write_domain = I915_GEM_DOMAIN_CPU;
obj->read_domains = I915_GEM_DOMAIN_CPU;
- obj->cache_level = I915_CACHE_NONE;
+
+ cache_level = HAS_LLC(i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
+ i915_gem_object_set_cache_coherency(obj, cache_level);
obj->mm.page_mask = page_mask;
--
2.26.3
[Intel-gfx] [PATCH 7/9] drm/i915: expand on the kernel-doc for cache_dirty
Add some details around non-LLC platforms and cflushing, when dealing
with the flush-on-acquire, which is potentially security sensitive.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 11
.../gpu/drm/i915/gem/i915_gem_object_types.h | 27 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 1231224728e4..9c323666bd7c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1933,6 +1933,17 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb)
* !(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ)
* but gcc's optimiser doesn't handle that as well and emits
* two jumps instead of one. Maybe one day...
+*
+* FIXME: There is also sync flushing in set_pages(), which
+* serves a different purpose(some of the time at least).
+*
+* We should consider:
+*
+* 1. Rip out the async flush code.
+*
+* 2. Or make the sync flushing use the async clflush path
+* using mandatory fences underneath. Currently the below
+* async flush happens after we bind the object.
*/
if (unlikely(obj->cache_dirty & ~obj->cache_coherent)) {
if (i915_gem_clflush_object(obj, 0))
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7c3da4e3e737..da85169006d4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -427,6 +427,33 @@ struct drm_i915_gem_object {
* can freely bypass the CPU cache when touching the pages with the GPU,
* where the kernel is completely unaware. On such platform we need
* apply the sledgehammer-on-acquire regardless of the @cache_coherent.
+*
+* Special care is taken on non-LLC platforms, to prevent potential
+* information leak. The driver currently ensures:
+*
+* 1. All userspace objects, by default, have @cache_level set as
+* I915_CACHE_NONE. The only exception is userptr objects, where we
+* instead force I915_CACHE_LLC, but we also don't allow userspace to
+* ever change the @cache_level for such objects. Another special case
+* is dma-buf, which doesn't rely on @cache_dirty, but there we
+* always do a forced flush when acquiring the pages, if there is a
+* chance that the pages can be read directly from main memory with
+* the GPU.
+*
+* 2. All I915_CACHE_NONE objects have @cache_dirty initially true.
+*
+* 3. All swapped-out objects(i.e shmem) have @cache_dirty set to
+* true.
+*
+* 4. The @cache_dirty is never freely reset before the initial
+* flush, even if userspace adjusts the @cache_level through the
+* i915_gem_set_caching_ioctl.
+*
+* 5. All @cache_dirty objects(including swapped-in) are initially
+* flushed with a synchronous call to drm_clflush_sg in
+* __i915_gem_object_set_pages. The @cache_dirty can be freely reset
+* at this point. All further asynchronous clfushes are never security
+* critical, i.e userspace is free to race against itself.
*/
unsigned int cache_dirty:1;
--
2.26.3
[Intel-gfx] [PATCH 8/9] drm/i915: mark up internal objects with start_cpu_write
While the pages can't be swapped out, they can be discarded by the shrinker.
Normally such objects are marked with __I915_MADV_PURGED, which can't be
unset, and therefore requires a new object. For kernel internal objects
this is not true, since the madv hint is reset for our special volatile
objects, such that we can re-acquire new pages, if so desired, without
needing a new object. As a result we should probably be paranoid here
and put the object back into the CPU domain when discarding the pages,
and also correctly set cache_dirty, if required.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index e5ae9c06510c..a57a6b7013c2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -134,6 +134,8 @@ static void i915_gem_object_put_pages_internal(struct
drm_i915_gem_object *obj,
internal_free_pages(pages);
obj->mm.dirty = false;
+
+ __start_cpu_write(obj);
}
static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
--
2.26.3
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2)
== Series Details == Series: drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2) URL : https://patchwork.freedesktop.org/series/95948/ 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_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2)
== Series Details == Series: drm/i915/dp: Fix link parameter use in lack of a valid DPCD (rev2) URL : https://patchwork.freedesktop.org/series/95948/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8f1a6421dfe5 drm/i915/dp: Skip the HW readout of DPCD on disabled encoders 4de2ca096081 drm/i915/dp: Ensure sink rate values are always valid -:42: WARNING:TYPO_SPELLING: 'initialzing' may be misspelled - perhaps 'initializing'? #42: v2: Clear the default sink rates, before initialzing these for eDP. ^^^ total: 0 errors, 1 warnings, 0 checks, 29 lines checked ef437e0c551b drm/i915/dp: Ensure max link params are always valid 66b542816538 drm/i915/dp: Ensure sink/link max lane count values are always valid f2bd5e3e941b drm/i915/dp: Sanitize sink rate DPCD register values -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: buggy monitor). So fixup the invalid DPCD sink rate values already and print total: 0 errors, 1 warnings, 0 checks, 33 lines checked d94f0647dd78 drm/i915/dp: Sanitize link common rate array lookups -:45: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #45: FILE: drivers/gpu/drm/i915/display/intel_dp.c:622: + intel_dp_common_rate(intel_dp, index - 1), total: 0 errors, 1 warnings, 0 checks, 77 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Remove unused assignment
== Series Details == Series: drm/i915/display: Remove unused assignment URL : https://patchwork.freedesktop.org/series/95967/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21373 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/index.html Known issues Here are the changes found in Patchwork_21373 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-bsw-n3050: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html * igt@gem_exec_suspend@basic-s0: - fi-skl-6700k2: [PASS][3] -> [DMESG-WARN][4] ([i915#1602]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/fi-skl-6700k2/igt@gem_exec_susp...@basic-s0.html * igt@runner@aborted: - fi-skl-6700k2: NOTRUN -> [FAIL][5] ([i915#3363]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/fi-skl-6700k2/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [INCOMPLETE][6] ([i915#2940]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][8] ([i915#3921]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][10] ([i915#4269]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269 Participating hosts (39 -> 37) -- Missing(2): fi-bsw-cyan bat-dg1-6 Build changes - * Linux: CI_DRM_10753 -> Patchwork_21373 CI-20190529: 20190529 CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21373: 64ace63151cd1725233a2569231a08c3d5518bd2 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 64ace63151cd drm/i915/display: Remove unused assignment == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21373/index.html
[Intel-gfx] [PATCH 6/9] drm/i915/shmem: ensure flush during swap-in on non-LLC
On non-LLC platforms, force the flush-on-acquire if this is ever
swapped-in. Our async flush path is not trust worthy enough yet(and
happens in the wrong order), and with some tricks it's conceivable for
userspace to change the cache-level to I915_CACHE_NONE after the pages
are swapped-in, and since execbuf binds the object before doing the
async flush, there is a potential race window.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index cf11aa7e08a0..d77da59fae04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -286,6 +286,8 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object
*obj,
struct sg_table *pages,
bool needs_clflush)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
if (obj->mm.madv == I915_MADV_DONTNEED)
@@ -297,6 +299,16 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object
*obj,
drm_clflush_sg(pages);
__start_cpu_write(obj);
+ /*
+* On non-LLC platforms, force the flush-on-acquire if this is ever
+* swapped-in. Our async flush path is not trust worthy enough yet(and
+* happens in the wrong order), and with some tricks it's conceivable
+* for userspace to change the cache-level to I915_CACHE_NONE after the
+* pages are swapped-in, and since execbuf binds the object before doing
+* the async flush, we have a race window.
+*/
+ if (!HAS_LLC(i915))
+ obj->cache_dirty = true;
}
void i915_gem_object_put_pages_shmem(struct drm_i915_gem_object *obj, struct
sg_table *pages)
--
2.26.3
[Intel-gfx] [PATCH 5/9] drm/i915/userptr: add paranoid flush-on-acquire
Even though userptr objects are always coherent with the GPU, with no way for userspace to change this with the set_caching ioctl, even on non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which might permit reading the contents of main memory directly. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c index 887aca9e8dd2..3173c9f9a040 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -165,8 +165,11 @@ static int i915_gem_userptr_get_pages(struct drm_i915_gem_object *obj) goto err; } - sg_page_sizes = i915_sg_dma_sizes(st->sgl); + WARN_ON_ONCE(!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE)); + if (i915_gem_object_can_bypass_llc(obj)) + obj->cache_dirty = true; + sg_page_sizes = i915_sg_dma_sizes(st->sgl); __i915_gem_object_set_pages(obj, st, sg_page_sizes); return 0; -- 2.26.3
[Intel-gfx] [PATCH 4/9] drm/i915/dmabuf: add paranoid flush-on-acquire
As pointed out by Thomas, we likely need to flush the pages here if the
GPU can read the page contents directly from main memory. Underneath we
don't know what the sg_table is pointing to, so just add a
wbinvd_on_all_cpus() here, for now.
Reported-by: Thomas Hellström
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 5be505ebbb7b..1adcd8e02d29 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -232,6 +232,7 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object
*gem_obj, int flags)
static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct sg_table *pages;
unsigned int sg_page_sizes;
@@ -242,8 +243,11 @@ static int i915_gem_object_get_pages_dmabuf(struct
drm_i915_gem_object *obj)
if (IS_ERR(pages))
return PTR_ERR(pages);
- sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
+ /* XXX: consider doing a vmap flush or something */
+ if (!HAS_LLC(i915) || i915_gem_object_can_bypass_llc(obj))
+ wbinvd_on_all_cpus();
+ sg_page_sizes = i915_sg_dma_sizes(pages->sgl);
__i915_gem_object_set_pages(obj, pages, sg_page_sizes);
return 0;
--
2.26.3
[Intel-gfx] [PATCH 3/9] drm/i915: extract bypass-llc check into helper
It looks like we will need this in some more places, so extract as a
helper.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 17 +-
3 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 76ce6a1500bc..1e426a42a36c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -128,6 +128,32 @@ void i915_gem_object_set_cache_coherency(struct
drm_i915_gem_object *obj,
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_WRITE);
}
+bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+ /*
+* This is purely from a security perspective, so we simply don't care
+* about non-userspace objects being able to bypass the LLC.
+*/
+ if (!(obj->flags & I915_BO_ALLOC_USER))
+ return false;
+
+ /*
+* EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
+* possible for userspace to bypass the GTT caching bits set by the
+* kernel, as per the given object cache_level. This is troublesome
+* since the heavy flush we apply when first gathering the pages is
+* skipped if the kernel thinks the object is coherent with the GPU. As
+* a result it might be possible to bypass the cache and read the
+* contents of the page directly, which could be stale data. If it's
+* just a case of userspace shooting themselves in the foot then so be
+* it, but since i915 takes the stance of always zeroing memory before
+* handing it to userspace, we need to prevent this.
+*/
+ return IS_JSL_EHL(i915);
+}
+
static void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file
*file)
{
struct drm_i915_gem_object *obj = to_intel_bo(gem);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 9df3ee60604e..59201801cec5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -514,6 +514,7 @@ i915_gem_object_finish_access(struct drm_i915_gem_object
*obj)
void i915_gem_object_set_cache_coherency(struct drm_i915_gem_object *obj,
unsigned int cache_level);
+bool i915_gem_object_can_bypass_llc(struct drm_i915_gem_object *obj);
void i915_gem_object_flush_if_display(struct drm_i915_gem_object *obj);
void i915_gem_object_flush_if_display_locked(struct drm_i915_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 11f072193f3b..cf11aa7e08a0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -182,22 +182,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj, st);
- /*
-* EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
-* possible for userspace to bypass the GTT caching bits set by the
-* kernel, as per the given object cache_level. This is troublesome
-* since the heavy flush we apply when first gathering the pages is
-* skipped if the kernel thinks the object is coherent with the GPU. As
-* a result it might be possible to bypass the cache and read the
-* contents of the page directly, which could be stale data. If it's
-* just a case of userspace shooting themselves in the foot then so be
-* it, but since i915 takes the stance of always zeroing memory before
-* handing it to userspace, we need to prevent this.
-*
-* By setting cache_dirty here we make the clflush in set_pages
-* unconditional on such platforms.
-*/
- if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER)
+ if (i915_gem_object_can_bypass_llc(obj))
obj->cache_dirty = true;
__i915_gem_object_set_pages(obj, st, sg_page_sizes);
--
2.26.3
[Intel-gfx] [PATCH 2/9] drm/i915: mark userptr objects as ALLOC_USER
These are userspace objects, so mark them as such. In a later patch it's useful to determine how paranoid we need to be when managing cache flushes. In theory no functional changes. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c index 8ea0fa665e53..887aca9e8dd2 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c @@ -546,7 +546,8 @@ i915_gem_userptr_ioctl(struct drm_device *dev, return -ENOMEM; drm_gem_private_object_init(dev, >base, args->user_size); - i915_gem_object_init(obj, _gem_userptr_ops, _class, 0); + i915_gem_object_init(obj, _gem_userptr_ops, _class, +I915_BO_ALLOC_USER); obj->mem_flags = I915_BO_FLAG_STRUCT_PAGE; obj->read_domains = I915_GEM_DOMAIN_CPU; obj->write_domain = I915_GEM_DOMAIN_CPU; -- 2.26.3
[Intel-gfx] [PATCH 1/9] drm/i915: mark dmabuf objects as ALLOC_USER
These are userspace objects, so mark them as such. In a later patch it's useful to determine how paranoid we need to be when managing cache flushes. In theory no functional changes. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c index afa34111de02..5be505ebbb7b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c @@ -301,7 +301,8 @@ struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev, } drm_gem_private_object_init(dev, >base, dma_buf->size); - i915_gem_object_init(obj, _gem_object_dmabuf_ops, _class, 0); + i915_gem_object_init(obj, _gem_object_dmabuf_ops, _class, +I915_BO_ALLOC_USER); obj->base.import_attach = attach; obj->base.resv = dma_buf->resv; -- 2.26.3
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Remove unused assignment
== Series Details == Series: drm/i915/display: Remove unused assignment URL : https://patchwork.freedesktop.org/series/95967/ State : warning == Summary == $ dim checkpatch origin/drm-tip 64ace63151cd drm/i915/display: Remove unused assignment -:29: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: luo penghao ' != 'Signed-off-by: luo penghao ' total: 0 errors, 1 warnings, 0 checks, 7 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Remove unused variable and its assignment.
== Series Details == Series: drm/i915/display: Remove unused variable and its assignment. URL : https://patchwork.freedesktop.org/series/95966/ State : success == Summary == CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21372 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/index.html Known issues Here are the changes found in Patchwork_21372 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-gfx0: - fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html * igt@gem_exec_suspend@basic-s0: - fi-kbl-soraka: [PASS][2] -> [INCOMPLETE][3] ([i915#4221]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [PASS][4] -> [FAIL][5] ([i915#4165]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [PASS][6] -> [DMESG-WARN][7] ([i915#295]) +18 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [INCOMPLETE][8] ([i915#2940]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#4165]: https://gitlab.freedesktop.org/drm/intel/issues/4165 [i915#4221]: https://gitlab.freedesktop.org/drm/intel/issues/4221 Participating hosts (39 -> 37) -- Missing(2): fi-bsw-cyan bat-dg1-6 Build changes - * Linux: CI_DRM_10753 -> Patchwork_21372 CI-20190529: 20190529 CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21372: 96c9d1f9af61cc2a106983090ab92059f55a5c99 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 96c9d1f9af61 drm/i915/display: Remove unused variable and its assignment. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21372/index.html
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Split skl+ plane update into noarm+arm pair
On Mon, Oct 18, 2021 at 08:14:04PM +0300, Ville Syrjälä wrote: > On Mon, Oct 18, 2021 at 03:06:34PM +0300, Lisovskiy, Stanislav wrote: > > On Mon, Oct 18, 2021 at 02:50:26PM +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Chop skl_program_plane() into two halves. Fist half becomes > > > the _noarm() variant, second part the _arm() variant. > > > > > > Fortunately I have already previously grouped the register > > > writes into roughtly the correct order, so the split looks > > > surprisingly clean. > > > > > > A few notable oddities I did not realize were self arming > > > are AUX_DIST and COLOR_CTL. > > > > > > i915_update_info doesn't look too terrible on my cfl running > > > kms_atomic_transition --r plane-all-transition --extended: > > > w/o patch w/ patch > > > Updates: 2178 Updates: 2018 > > >| | > > >1us | 1us | > > >| | > > >4us | 4us |* > > >|* |** > > > 16us |**16us |*** > > >|***| > > > 66us | 66us | > > >| | > > > 262us | 262us | > > >| | > > >1ms | 1ms | > > >| | > > >4ms | 4ms | > > >| | > > > 17ms | 17ms | > > >| | > > > Min update: 8332ns Min update: 6164ns > > > Max update: 48758ns Max update: 31808ns > > > Average update: 19959ns Average update: 13159ns > > > Overruns > 100us: 0 Overruns > 100us: 0 > > > > > > And with lockdep enabled: > > > w/o patch w/ patch > > > Updates: 2177 Updates: 2172 > > >| | > > >1us | 1us | > > >| | > > >4us | 4us | > > >|*** |* > > > 16us |** 16us |** > > >|*** |* > > > 66us |66us | > > >| | > > > 262us | 262us | > > >| | > > >1ms | 1ms | > > >| | > > >4ms | 4ms | > > >| | > > > 17ms |17ms | > > >| | > > > Min update: 12645ns Min update: 9980ns > > > Max update: 50153ns Max update: 33533ns > > > Average update: 25337ns Average update: 18245ns > > > Overruns > 250us: 0 Overruns > 250us: 0 > > > > > > TODO: On icl+ everything seems to be armed by PLANE_SURF, so we > > > can optimize this even further on modern platforms. But I > > > think there's a bit of refactoring to be done first to > > > figure out the best way to go about it (eg. just reusing > > > the current skl+ functions, or doing a lower level split). > > > > > > TODO: Split scaler programming as well, but IIRC the scaler > > > has some oddball double buffering behaviour on some > > > platforms, so needs proper reverse engineering > > > > > > Cc: Stanislav Lisovskiy > > > Signed-off-by: Ville Syrjälä > > > > Should I use that one as a base for further splitting, i.e for DG2? > > Which refactoring has to be done first, as I understand should be > > pretty safe to leave only PLANE_SURF update in arm section, and > > of course scaler is a different thing. > > I'm not really sure which way we should do the skl+ vs. icl+ split. > > Various ideas I've had: > - Definitly pull all the icl+ specific things out from the skl+ > functions and stuff them into icl_plane_update_noarm() > - After that just call the remaining skl_plane_update_noarm()+arm() > back to back from icl_update_noarm() maybe? I don't like this > idea much actually. > - Maybe instead pull some sequences of register writes into small > helpers (eg. colorkey registers could be one). But dunno if there > are other clear groups to make this super useful. > - Or perhaps just pull most fiddly register value calculations > (aux_dist,ckey+alpha things,maybe others) into small helpers > to avoid duplicating themm but otherwise fully duplicate all > the actual register writes? I guess that last thing is what I already did with skl_plane_surf()
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Split skl+ plane update into noarm+arm pair
On Mon, Oct 18, 2021 at 03:06:34PM +0300, Lisovskiy, Stanislav wrote: > On Mon, Oct 18, 2021 at 02:50:26PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Chop skl_program_plane() into two halves. Fist half becomes > > the _noarm() variant, second part the _arm() variant. > > > > Fortunately I have already previously grouped the register > > writes into roughtly the correct order, so the split looks > > surprisingly clean. > > > > A few notable oddities I did not realize were self arming > > are AUX_DIST and COLOR_CTL. > > > > i915_update_info doesn't look too terrible on my cfl running > > kms_atomic_transition --r plane-all-transition --extended: > > w/o patch w/ patch > > Updates: 2178 Updates: 2018 > >| | > >1us | 1us | > >| | > >4us | 4us |* > >|* |** > > 16us |**16us |*** > >|***| > > 66us | 66us | > >| | > > 262us | 262us | > >| | > >1ms | 1ms | > >| | > >4ms | 4ms | > >| | > > 17ms | 17ms | > >| | > > Min update: 8332ns Min update: 6164ns > > Max update: 48758ns Max update: 31808ns > > Average update: 19959ns Average update: 13159ns > > Overruns > 100us: 0 Overruns > 100us: 0 > > > > And with lockdep enabled: > > w/o patch w/ patch > > Updates: 2177 Updates: 2172 > >| | > >1us | 1us | > >| | > >4us | 4us | > >|***|* > > 16us |**16us |** > >|***|* > > 66us | 66us | > >| | > > 262us | 262us | > >| | > >1ms | 1ms | > >| | > >4ms | 4ms | > >| | > > 17ms | 17ms | > >| | > > Min update: 12645ns Min update: 9980ns > > Max update: 50153ns Max update: 33533ns > > Average update: 25337ns Average update: 18245ns > > Overruns > 250us: 0 Overruns > 250us: 0 > > > > TODO: On icl+ everything seems to be armed by PLANE_SURF, so we > > can optimize this even further on modern platforms. But I > > think there's a bit of refactoring to be done first to > > figure out the best way to go about it (eg. just reusing > > the current skl+ functions, or doing a lower level split). > > > > TODO: Split scaler programming as well, but IIRC the scaler > > has some oddball double buffering behaviour on some > > platforms, so needs proper reverse engineering > > > > Cc: Stanislav Lisovskiy > > Signed-off-by: Ville Syrjälä > > Should I use that one as a base for further splitting, i.e for DG2? > Which refactoring has to be done first, as I understand should be > pretty safe to leave only PLANE_SURF update in arm section, and > of course scaler is a different thing. I'm not really sure which way we should do the skl+ vs. icl+ split. Various ideas I've had: - Definitly pull all the icl+ specific things out from the skl+ functions and stuff them into icl_plane_update_noarm() - After that just call the remaining skl_plane_update_noarm()+arm() back to back from icl_update_noarm() maybe? I don't like this idea much actually. - Maybe instead pull some sequences of register writes into small helpers (eg. colorkey registers could be one). But dunno if there are other clear groups to make this super useful. - Or perhaps just pull most fiddly register value calculations (aux_dist,ckey+alpha things,maybe others) into small helpers to avoid duplicating themm but otherwise fully duplicate all the actual register writes? The sweet spot is probably some combination of those. I was also thinking of doing an overhaul of the register defines to use REG_BI() & co. That might help with approaches that involves any amount of duplication. -- Ville Syrjälä Intel
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Remove unused variable and its assignment.
== Series Details == Series: drm/i915/display: Remove unused variable and its assignment. URL : https://patchwork.freedesktop.org/series/95966/ State : warning == Summary == $ dim checkpatch origin/drm-tip 96c9d1f9af61 drm/i915/display: Remove unused variable and its assignment. -:38: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: luo penghao ' != 'Signed-off-by: luo penghao ' total: 0 errors, 1 warnings, 0 checks, 14 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Remove unused variable and corresponding assignment
== Series Details ==
Series: drm/i915/display: Remove unused variable and corresponding assignment
URL : https://patchwork.freedesktop.org/series/95965/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21371
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/index.html
Known issues
Here are the changes found in Patchwork_21371 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [INCOMPLETE][2] ([i915#2940]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
Participating hosts (39 -> 37)
--
Missing(2): fi-bsw-cyan bat-dg1-6
Build changes
-
* Linux: CI_DRM_10753 -> Patchwork_21371
CI-20190529: 20190529
CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21371: 608df21051577dc13d68c59935d9cf3f5c72430e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
608df2105157 drm/i915/display: Remove unused variable and corresponding
assignment
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21371/index.html
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Split plane updates to noarm+arm phases
== Series Details == Series: drm/i915: Split plane updates to noarm+arm phases URL : https://patchwork.freedesktop.org/series/95962/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10752_full -> Patchwork_21368_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21368_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21368_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_21368_full: ### IGT changes ### Possible regressions * igt@kms_bw@linear-tiling-1-displays-2560x1440p: - shard-snb: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-snb5/igt@kms...@linear-tiling-1-displays-2560x1440p.html Known issues Here are the changes found in Patchwork_21368_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_ctx_sseu@invalid-sseu: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#280]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-tglb5/igt@gem_ctx_s...@invalid-sseu.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#2369] / [i915#3063] / [i915#3648]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-tglb7/igt@gem_...@unwedge-stress.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-tglb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk1/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-kbl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-glk6/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][12] -> [DMESG-WARN][13] ([i915#118]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk3/igt@gem_exec_whis...@basic-fds-all.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-glk7/igt@gem_exec_whis...@basic-fds-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-tglb1/igt@gem_huc_c...@huc-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_media_vme: - shard-tglb: NOTRUN -> [SKIP][16] ([i915#284]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-tglb8/igt@gem_media_vme.html * igt@gem_pxp@regular-baseline-src-copy-readible: - shard-tglb: NOTRUN -> [SKIP][17] ([i915#4270]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-tglb5/igt@gem_...@regular-baseline-src-copy-readible.html * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: - shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271]) +63 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-kbl3/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html * igt@gem_userptr_blits@readonly-pwrite-unsync: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#3297]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-tglb8/igt@gem_userptr_bl...@readonly-pwrite-unsync.html * igt@gen7_exec_parse@bitmasks: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/shard-tglb5/igt@gen7_exec_pa...@bitmasks.html * igt@gen9_exec_parse@basic-rejected: - shard-tglb:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Remove unused variable and corresponding assignment
== Series Details == Series: drm/i915/display: Remove unused variable and corresponding assignment URL : https://patchwork.freedesktop.org/series/95965/ State : warning == Summary == $ dim checkpatch origin/drm-tip 608df2105157 drm/i915/display: Remove unused variable and corresponding assignment -:39: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: luo penghao ' != 'Signed-off-by: luo penghao ' total: 0 errors, 1 warnings, 0 checks, 15 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove redundant assignments
== Series Details ==
Series: drm/i915: Remove redundant assignments
URL : https://patchwork.freedesktop.org/series/95964/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10753 -> Patchwork_21370
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/index.html
Known issues
Here are the changes found in Patchwork_21370 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/fi-bsw-n3050/igt@amdgpu/amd_cs_...@sync-gfx0.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][2] -> [INCOMPLETE][3] ([i915#2940])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][4] ([fdo#109271] / [i915#1436] /
[i915#3428])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/fi-bsw-kefka/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [INCOMPLETE][5] ([i915#2940]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][7] ([i915#4269]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10753/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
Participating hosts (39 -> 35)
--
Missing(4): fi-kbl-soraka fi-bsw-cyan fi-icl-y bat-dg1-6
Build changes
-
* Linux: CI_DRM_10753 -> Patchwork_21370
CI-20190529: 20190529
CI_DRM_10753: 57c1bcf63565db8d65783364c632a04a44bbd616 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6254: 51792e987da03ba2a6faf5857c12f1d173c87def @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_21370: 44903acf09f66102432ab439599516724bb9cffa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
44903acf09f6 drm/i915: Remove redundant assignments
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21370/index.html
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Simplify handling of modifiers (rev10)
On Mon, Oct 18, 2021 at 06:42:38PM +0300, Petri Latvala wrote:
> On Mon, Oct 18, 2021 at 03:10:54PM +0300, Imre Deak wrote:
> > Hi Petri, Tomi,
> >
> > could you check the failure below?
> >
> > On Fri, Oct 15, 2021 at 11:19:13AM +, Patchwork wrote:
> > > == Series Details ==
> > >
> > > Series: drm/i915: Simplify handling of modifiers (rev10)
> > > URL : https://patchwork.freedesktop.org/series/95579/
> > > State : failure
> > >
> > > == Summary ==
> > >
> > > CI Bug Log - changes from CI_DRM_10741_full -> Patchwork_21343_full
> > >
> > >
> > > Summary
> > > ---
> > >
> > > **FAILURE**
> > >
> > > Serious unknown changes coming with Patchwork_21343_full absolutely
> > > need to be
> > > verified manually.
> > >
> > > If you think the reported changes have nothing to do with the changes
> > > introduced in Patchwork_21343_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_21343_full:
> > >
> > > ### IGT changes ###
> > >
> > > Possible regressions
> > >
> > > * igt@kms_vblank@pipe-a-wait-busy:
> > > - shard-skl: [PASS][1] -> [INCOMPLETE][2]
> > >[1]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-skl1/igt@kms_vbl...@pipe-a-wait-busy.html
> > >[2]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-skl1/igt@kms_vbl...@pipe-a-wait-busy.html
> >
> > This is from Patchwork_21343/shard-skl1/19/dmesg.log , where the above
> > test passes and is followed by more passing tests, until
> > kms_busy/extended-modeset-hang-oldfb
> >
> > also passes at least according to igt_runner.log, though I can't see it in
> > dmesg.log. After that:
> >
> > [1091.672412] Overall timeout time exceeded, stopping.
> >
> > Is it just an overall timeout problem, or some test after
> > kms_busy/extended-modeset-hand-oldfb?
>
> The test passed but igt_runner's journal.txt for it was left
> empty. Reason for that is unknown (fs corruption, or something like
> that). Because overall timeout got triggered, igt_results was invoked
> against that shard execution in jenkins master host, overwriting the
> DUT-written one, and because the journal didn't state the subtest
> started, it was parsed as being incomplete.
Ok. Maybe igt_runner could sync/stat the file if the write happened as
expected? I can see the same truncation at least on the following
shard-skl test runs:
CI_DRM_10743/shard-skl7/16/118/journal.txt
Patchwork_21337/shard-skl9/15/45/journal.txt
Patchwork_21343/shard-skl1/19/72/journal.txt
Patchwork_21302/shard-skl7/23/45/journal.txt
Patchwork_21362/shard-skl8/21/12/journal.txt
Patchwork_21317/shard-skl3/11/0/journal.txt
I can't see anything obvious in dmesg, so I think the issue is unrelated
to changes in the patchset. Would it make sense to open a ticket for the
above particular file-truncated issue?
> The logs unfortunately were not able to give any indication as to why
> the journal file was left empty. igt_runner syncs it when writing to
> it, and the test execution continued normally after that particular
> test.
> --
> Petri Latvala
>
>
> >
> > > Suppressed
> > >
> > > The following results come from untrusted machines, tests, or statuses.
> > > They do not affect the overall result.
> > >
> > > * {igt@kms_bw@linear-tiling-3-displays-3840x2160p}:
> > > - shard-snb: NOTRUN -> [FAIL][3]
> > >[3]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-snb6/igt@kms...@linear-tiling-3-displays-3840x2160p.html
> > >
> > > * {igt@kms_bw@linear-tiling-4-displays-1920x1080p}:
> > > - shard-apl: NOTRUN -> [DMESG-FAIL][4]
> > >[4]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-apl3/igt@kms...@linear-tiling-4-displays-1920x1080p.html
> > >
> > >
> > > Known issues
> > >
> > >
> > > Here are the changes found in Patchwork_21343_full that come from known
> > > issues:
> > >
> > > ### IGT changes ###
> > >
> > > Issues hit
> > >
> > > * igt@feature_discovery@chamelium:
> > > - shard-tglb: NOTRUN -> [SKIP][5] ([fdo#111827])
> > >[5]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-tglb3/igt@feature_discov...@chamelium.html
> > >
> > > * igt@gem_ctx_persistence@hostile:
> > > - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410])
> > >[6]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-tglb2/igt@gem_ctx_persiste...@hostile.html
> > >[7]:
> > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-tglb5/igt@gem_ctx_persiste...@hostile.html
> > >
> > > * igt@gem_ctx_persistence@legacy-engines-mixed:
> > > -
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95942/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10752_full -> Patchwork_21366_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21366_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21366_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_21366_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@pi-ringfull@bcs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-skl1/igt@gem_exec_schedule@pi-ringf...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-skl5/igt@gem_exec_schedule@pi-ringf...@bcs0.html * igt@kms_busy@extended-modeset-hang-oldfb-with-reset@pipe-d: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-tglb1/igt@kms_busy@extended-modeset-hang-oldfb-with-re...@pipe-d.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-tglb8/igt@kms_busy@extended-modeset-hang-oldfb-with-re...@pipe-d.html * igt@kms_bw@linear-tiling-1-displays-2560x1440p: - shard-snb: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-snb2/igt@kms...@linear-tiling-1-displays-2560x1440p.html Known issues Here are the changes found in Patchwork_21366_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_caching@writes: - shard-skl: [PASS][6] -> [DMESG-WARN][7] ([i915#1982]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-skl3/igt@gem_cach...@writes.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-skl3/igt@gem_cach...@writes.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_ctx_sseu@invalid-sseu: - shard-tglb: NOTRUN -> [SKIP][9] ([i915#280]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-tglb6/igt@gem_ctx_s...@invalid-sseu.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][10] -> [TIMEOUT][11] ([i915#2369] / [i915#3063] / [i915#3648]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-tglb7/igt@gem_...@unwedge-stress.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-tglb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk1/igt@gem_exec_f...@basic-deadline.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-glk1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-kbl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_whisper@basic-contexts-all: - shard-glk: [PASS][18] -> [DMESG-WARN][19] ([i915#118]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk6/igt@gem_exec_whis...@basic-contexts-all.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-glk6/igt@gem_exec_whis...@basic-contexts-all.html * igt@gem_media_vme: - shard-tglb: NOTRUN -> [SKIP][20] ([i915#284]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-tglb2/igt@gem_media_vme.html * igt@gem_pxp@regular-baseline-src-copy-readible: - shard-tglb: NOTRUN -> [SKIP][21] ([i915#4270]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/shard-tglb6/igt@gem_...@regular-baseline-src-copy-readible.html *
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display: Remove unused variable in the for loop.
== Series Details == Series: drm/i915/display: Remove unused variable in the for loop. URL : https://patchwork.freedesktop.org/series/95963/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/display/intel_fb.o drivers/gpu/drm/i915/display/intel_fb.c: In function ‘intel_fill_fb_info’: drivers/gpu/drm/i915/display/intel_fb.c:1018:23: error: statement with no effect [-Werror=unused-value] fb->base.format->cpp[i]; ^~~ cc1: all warnings being treated as errors scripts/Makefile.build:277: recipe for target 'drivers/gpu/drm/i915/display/intel_fb.o' failed make[4]: *** [drivers/gpu/drm/i915/display/intel_fb.o] Error 1 scripts/Makefile.build:540: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:540: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:540: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1868: recipe for target 'drivers' failed make: *** [drivers] Error 2
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Simplify handling of modifiers (rev10)
On Mon, Oct 18, 2021 at 03:10:54PM +0300, Imre Deak wrote:
> Hi Petri, Tomi,
>
> could you check the failure below?
>
> On Fri, Oct 15, 2021 at 11:19:13AM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Simplify handling of modifiers (rev10)
> > URL : https://patchwork.freedesktop.org/series/95579/
> > State : failure
> >
> > == Summary ==
> >
> > CI Bug Log - changes from CI_DRM_10741_full -> Patchwork_21343_full
> >
> >
> > Summary
> > ---
> >
> > **FAILURE**
> >
> > Serious unknown changes coming with Patchwork_21343_full absolutely need
> > to be
> > verified manually.
> >
> > If you think the reported changes have nothing to do with the changes
> > introduced in Patchwork_21343_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_21343_full:
> >
> > ### IGT changes ###
> >
> > Possible regressions
> >
> > * igt@kms_vblank@pipe-a-wait-busy:
> > - shard-skl: [PASS][1] -> [INCOMPLETE][2]
> >[1]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-skl1/igt@kms_vbl...@pipe-a-wait-busy.html
> >[2]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-skl1/igt@kms_vbl...@pipe-a-wait-busy.html
>
> This is from Patchwork_21343/shard-skl1/19/dmesg.log , where the above
> test passes and is followed by more passing tests, until
> kms_busy/extended-modeset-hang-oldfb
>
> also passes at least according to igt_runner.log, though I can't see it in
> dmesg.log. After that:
>
> [1091.672412] Overall timeout time exceeded, stopping.
>
> Is it just an overall timeout problem, or some test after
> kms_busy/extended-modeset-hand-oldfb?
The test passed but igt_runner's journal.txt for it was left
empty. Reason for that is unknown (fs corruption, or something like
that). Because overall timeout got triggered, igt_results was invoked
against that shard execution in jenkins master host, overwriting the
DUT-written one, and because the journal didn't state the subtest
started, it was parsed as being incomplete.
The logs unfortunately were not able to give any indication as to why
the journal file was left empty. igt_runner syncs it when writing to
it, and the test execution continued normally after that particular
test.
--
Petri Latvala
>
> > Suppressed
> >
> > The following results come from untrusted machines, tests, or statuses.
> > They do not affect the overall result.
> >
> > * {igt@kms_bw@linear-tiling-3-displays-3840x2160p}:
> > - shard-snb: NOTRUN -> [FAIL][3]
> >[3]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-snb6/igt@kms...@linear-tiling-3-displays-3840x2160p.html
> >
> > * {igt@kms_bw@linear-tiling-4-displays-1920x1080p}:
> > - shard-apl: NOTRUN -> [DMESG-FAIL][4]
> >[4]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-apl3/igt@kms...@linear-tiling-4-displays-1920x1080p.html
> >
> >
> > Known issues
> >
> >
> > Here are the changes found in Patchwork_21343_full that come from known
> > issues:
> >
> > ### IGT changes ###
> >
> > Issues hit
> >
> > * igt@feature_discovery@chamelium:
> > - shard-tglb: NOTRUN -> [SKIP][5] ([fdo#111827])
> >[5]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-tglb3/igt@feature_discov...@chamelium.html
> >
> > * igt@gem_ctx_persistence@hostile:
> > - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410])
> >[6]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-tglb2/igt@gem_ctx_persiste...@hostile.html
> >[7]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-tglb5/igt@gem_ctx_persiste...@hostile.html
> >
> > * igt@gem_ctx_persistence@legacy-engines-mixed:
> > - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099])
> > +3 similar issues
> >[8]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html
> >
> > * igt@gem_exec_fair@basic-none-rrul@rcs0:
> > - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842])
> >[9]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html
> >[10]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html
> >
> > * igt@gem_exec_fair@basic-none-solo@rcs0:
> > - shard-kbl: NOTRUN -> [FAIL][11] ([i915#2842])
> >[11]:
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
> >
> > * igt@gem_exec_fair@basic-none-vip@rcs0:
> >
[Intel-gfx] [PATCH v2 4/9] drm/i915: Move LPT PCH readout code
From: Ville Syrjälä
Nuke the hsw_get_ddi_port_state() eyesore by putting the
readout code into intel_pch_display.c, and calling it directly
from hsw_crt_get_config().
Note that the nuked TRANS_DDI_FUNC_CTL readout from
hsw_get_ddi_port_state() is now etirely redundant since we
get called from the encoder->get_config() so we already know
we're dealing with the correct DDI port. Previously the
code was called from a place where that wasn't known so
it had to checked manually.
v2: Clarify the TRANS_DDI_FUNC_CTL change (Dave)
Nuke the now unused *TRANS_DDI_FUNC_CTL_VAL_TO_PORT() (Dave)
Cc: Dave Airlie
Cc: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_crt.c | 2 +
drivers/gpu/drm/i915/display/intel_display.c | 46 ++-
drivers/gpu/drm/i915/display/intel_display.h | 2 +
.../gpu/drm/i915/display/intel_pch_display.c | 18
.../gpu/drm/i915/display/intel_pch_display.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 2 -
6 files changed, 26 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 4038ae342ea1..03cfae46f92f 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -147,6 +147,8 @@ static void hsw_crt_get_config(struct intel_encoder
*encoder,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ lpt_pch_get_config(pipe_config);
+
hsw_ddi_get_config(encoder, pipe_config);
pipe_config->hw.adjusted_mode.flags &= ~(DRM_MODE_FLAG_PHSYNC |
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2ee02c16bd1c..8f65b8b6a306 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4090,8 +4090,8 @@ void intel_dp_get_m_n(struct intel_crtc *crtc,
_config->dp_m2_n2);
}
-static void ilk_get_fdi_m_n_config(struct intel_crtc *crtc,
- struct intel_crtc_state *pipe_config)
+void ilk_get_fdi_m_n_config(struct intel_crtc *crtc,
+ struct intel_crtc_state *pipe_config)
{
intel_cpu_transcoder_get_m_n(crtc, pipe_config->cpu_transcoder,
_config->fdi_m_n, NULL);
@@ -4486,45 +4486,6 @@ static bool bxt_get_dsi_transcoder_state(struct
intel_crtc *crtc,
return transcoder_is_dsi(pipe_config->cpu_transcoder);
}
-static void hsw_get_ddi_port_state(struct intel_crtc *crtc,
- struct intel_crtc_state *pipe_config)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
- enum port port;
- u32 tmp;
-
- if (transcoder_is_dsi(cpu_transcoder)) {
- port = (cpu_transcoder == TRANSCODER_DSI_A) ?
- PORT_A : PORT_B;
- } else {
- tmp = intel_de_read(dev_priv,
- TRANS_DDI_FUNC_CTL(cpu_transcoder));
- if (!(tmp & TRANS_DDI_FUNC_ENABLE))
- return;
- if (DISPLAY_VER(dev_priv) >= 12)
- port = TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
- else
- port = TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
- }
-
- /*
-* Haswell has only FDI/PCH transcoder A. It is which is connected to
-* DDI E. So just check whether this pipe is wired to DDI E and whether
-* the PCH transcoder is on.
-*/
- if (DISPLAY_VER(dev_priv) < 9 &&
- (port == PORT_E) && intel_de_read(dev_priv, LPT_TRANSCONF) &
TRANS_ENABLE) {
- pipe_config->has_pch_encoder = true;
-
- tmp = intel_de_read(dev_priv, FDI_RX_CTL(PIPE_A));
- pipe_config->fdi_lanes = ((FDI_DP_PORT_WIDTH_MASK & tmp) >>
- FDI_DP_PORT_WIDTH_SHIFT) + 1;
-
- ilk_get_fdi_m_n_config(crtc, pipe_config);
- }
-}
-
static bool hsw_get_pipe_config(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config)
{
@@ -4562,8 +4523,7 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
/* we cannot read out most state, so don't bother.. */
pipe_config->quirks |= PIPE_CONFIG_QUIRK_BIGJOINER_SLAVE;
} else if (!transcoder_is_dsi(pipe_config->cpu_transcoder) ||
- DISPLAY_VER(dev_priv) >= 11) {
- hsw_get_ddi_port_state(crtc, pipe_config);
+ DISPLAY_VER(dev_priv) >= 11) {
intel_get_transcoder_timings(crtc, pipe_config);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 93c84f2174b5..5bc8d8913178 100644
---
Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: Ensure sink/link max lane count values are always valid
On Mon, Oct 18, 2021 at 06:13:19PM +0300, Imre Deak wrote:
> On Mon, Oct 18, 2021 at 06:04:18PM +0300, Ville Syrjälä wrote:
> > On Mon, Oct 18, 2021 at 12:41:52PM +0300, Imre Deak wrote:
> > > Print an error if the DPCD sink max lane count is invalid and fix it up.
> > >
> > > While at it also add an assert that the link max lane count (derived
> > > from intel_dp_max_common_lane_count(), potentially reduced by the LT
> > > fallback logic) value is also valid.
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Imre Deak
> > > ---
> > > .../drm/i915/display/intel_display_types.h| 2 +
> > > drivers/gpu/drm/i915/display/intel_dp.c | 44 ++-
> > > 2 files changed, 44 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > index 39e11eaec1a3f..1e42bf901263c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > @@ -1563,6 +1563,8 @@ struct intel_dp {
> > > int num_sink_rates;
> > > int sink_rates[DP_MAX_SUPPORTED_RATES];
> > > bool use_rate_select;
> > > + /* Max sink lane count as reported by DP_MAX_LANE_COUNT */
> > > + int max_sink_lane_count;
> > > /* intersection of source and sink rates */
> > > int num_common_rates;
> > > int common_rates[DP_MAX_SUPPORTED_RATES];
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index 1935eb49f9574..f7711779df132 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -197,6 +197,35 @@ static void intel_dp_set_sink_rates(struct intel_dp
> > > *intel_dp)
> > > intel_dp->num_sink_rates = i;
> > > }
> > >
> > > +static void intel_dp_set_default_max_sink_lane_count(struct intel_dp
> > > *intel_dp)
> > > +{
> > > + intel_dp->max_sink_lane_count = 1;
> > > +}
> > > +
> > > +static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
> > > +{
> > > + struct intel_connector *connector = intel_dp->attached_connector;
> > > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > > + struct intel_encoder *encoder = _dig_port->base;
> > > +
> > > + intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > > +
> > > + switch (intel_dp->max_sink_lane_count) {
> > > + case 1:
> > > + case 2:
> > > + case 4:
> > > + return;
> > > + }
> > > +
> > > + drm_err(_to_i915(intel_dp)->drm,
> > > + "[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD max lane count
> > > (%d), using default\n",
> > > + connector->base.base.id, connector->base.name,
> > > + encoder->base.base.id, encoder->base.name,
> > > + intel_dp->max_sink_lane_count);
> > > +
> > > + intel_dp_set_default_max_sink_lane_count(intel_dp);
> > > +}
> > > +
> > > /* Get length of rates array potentially limited by max_rate. */
> > > static int intel_dp_rate_limit_len(const int *rates, int len, int
> > > max_rate)
> > > {
> > > @@ -230,7 +259,7 @@ static int intel_dp_max_common_lane_count(struct
> > > intel_dp *intel_dp)
> > > {
> > > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > > int source_max = dig_port->max_lanes;
> > > - int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> > > + int sink_max = intel_dp->max_sink_lane_count;
> > > int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
> > > int lttpr_max =
> > > drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
> > >
> > > @@ -242,7 +271,15 @@ static int intel_dp_max_common_lane_count(struct
> > > intel_dp *intel_dp)
> > >
> > > int intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > > {
> > > - return intel_dp->max_link_lane_count;
> > > + switch (intel_dp->max_link_lane_count) {
> > > + case 1:
> > > + case 2:
> > > + case 4:
> > > + return intel_dp->max_link_lane_count;
> > > + default:
> > > + MISSING_CASE(intel_dp->max_link_lane_count);
> > > + return 1;
> > > + }
> > > }
> >
> > I guess this is just a second level sanity check. I was wondering it
> > gets confusing and people start thinking this can actually happen,
> > but I suppose the MISSING_CASE() should be indication enough that it
> > in fact should not happen.
>
> Yes it shouldn't happen. Given that we don't consider the FIA reg value
> external, but I think that's a reasonable assumption.
>
> > Series looks sane to me:
> > Reviewed-by: Ville Syrjälä
>
> Thanks.
>
> > BTW there's now some kms_bw thing in igt which seems to forcing
> > DP connectors on left and right, and thus triggering a bunch of
> > WARNs.
>
> Yes, noticed. This series should fix the WARN, however the modeset will
> still fail, due to using the minimum link_rate/lane_count set by default
> in this patchset. But due to the LT failing and fallback reducing the
> link params it would anyway fail
Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: Ensure sink/link max lane count values are always valid
On Mon, Oct 18, 2021 at 06:04:18PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 18, 2021 at 12:41:52PM +0300, Imre Deak wrote:
> > Print an error if the DPCD sink max lane count is invalid and fix it up.
> >
> > While at it also add an assert that the link max lane count (derived
> > from intel_dp_max_common_lane_count(), potentially reduced by the LT
> > fallback logic) value is also valid.
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > .../drm/i915/display/intel_display_types.h| 2 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 44 ++-
> > 2 files changed, 44 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 39e11eaec1a3f..1e42bf901263c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1563,6 +1563,8 @@ struct intel_dp {
> > int num_sink_rates;
> > int sink_rates[DP_MAX_SUPPORTED_RATES];
> > bool use_rate_select;
> > + /* Max sink lane count as reported by DP_MAX_LANE_COUNT */
> > + int max_sink_lane_count;
> > /* intersection of source and sink rates */
> > int num_common_rates;
> > int common_rates[DP_MAX_SUPPORTED_RATES];
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 1935eb49f9574..f7711779df132 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -197,6 +197,35 @@ static void intel_dp_set_sink_rates(struct intel_dp
> > *intel_dp)
> > intel_dp->num_sink_rates = i;
> > }
> >
> > +static void intel_dp_set_default_max_sink_lane_count(struct intel_dp
> > *intel_dp)
> > +{
> > + intel_dp->max_sink_lane_count = 1;
> > +}
> > +
> > +static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
> > +{
> > + struct intel_connector *connector = intel_dp->attached_connector;
> > + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > + struct intel_encoder *encoder = _dig_port->base;
> > +
> > + intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > +
> > + switch (intel_dp->max_sink_lane_count) {
> > + case 1:
> > + case 2:
> > + case 4:
> > + return;
> > + }
> > +
> > + drm_err(_to_i915(intel_dp)->drm,
> > + "[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD max lane count
> > (%d), using default\n",
> > + connector->base.base.id, connector->base.name,
> > + encoder->base.base.id, encoder->base.name,
> > + intel_dp->max_sink_lane_count);
> > +
> > + intel_dp_set_default_max_sink_lane_count(intel_dp);
> > +}
> > +
> > /* Get length of rates array potentially limited by max_rate. */
> > static int intel_dp_rate_limit_len(const int *rates, int len, int max_rate)
> > {
> > @@ -230,7 +259,7 @@ static int intel_dp_max_common_lane_count(struct
> > intel_dp *intel_dp)
> > {
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > int source_max = dig_port->max_lanes;
> > - int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> > + int sink_max = intel_dp->max_sink_lane_count;
> > int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
> > int lttpr_max =
> > drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
> >
> > @@ -242,7 +271,15 @@ static int intel_dp_max_common_lane_count(struct
> > intel_dp *intel_dp)
> >
> > int intel_dp_max_lane_count(struct intel_dp *intel_dp)
> > {
> > - return intel_dp->max_link_lane_count;
> > + switch (intel_dp->max_link_lane_count) {
> > + case 1:
> > + case 2:
> > + case 4:
> > + return intel_dp->max_link_lane_count;
> > + default:
> > + MISSING_CASE(intel_dp->max_link_lane_count);
> > + return 1;
> > + }
> > }
>
> I guess this is just a second level sanity check. I was wondering it
> gets confusing and people start thinking this can actually happen,
> but I suppose the MISSING_CASE() should be indication enough that it
> in fact should not happen.
Yes it shouldn't happen. Given that we don't consider the FIA reg value
external, but I think that's a reasonable assumption.
> Series looks sane to me:
> Reviewed-by: Ville Syrjälä
Thanks.
> BTW there's now some kms_bw thing in igt which seems to forcing
> DP connectors on left and right, and thus triggering a bunch of
> WARNs.
Yes, noticed. This series should fix the WARN, however the modeset will
still fail, due to using the minimum link_rate/lane_count set by default
in this patchset. But due to the LT failing and fallback reducing the
link params it would anyway fail after the first modeset. I wonder what
would be a good solution if the above kind of use case is important
enough (I at least use this for debugging). Maybe a virtual loopback
connector which could handle LT (in kernel perhaps)
Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: Ensure sink/link max lane count values are always valid
On Mon, Oct 18, 2021 at 12:41:52PM +0300, Imre Deak wrote:
> Print an error if the DPCD sink max lane count is invalid and fix it up.
>
> While at it also add an assert that the link max lane count (derived
> from intel_dp_max_common_lane_count(), potentially reduced by the LT
> fallback logic) value is also valid.
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_dp.c | 44 ++-
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 39e11eaec1a3f..1e42bf901263c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1563,6 +1563,8 @@ struct intel_dp {
> int num_sink_rates;
> int sink_rates[DP_MAX_SUPPORTED_RATES];
> bool use_rate_select;
> + /* Max sink lane count as reported by DP_MAX_LANE_COUNT */
> + int max_sink_lane_count;
> /* intersection of source and sink rates */
> int num_common_rates;
> int common_rates[DP_MAX_SUPPORTED_RATES];
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 1935eb49f9574..f7711779df132 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -197,6 +197,35 @@ static void intel_dp_set_sink_rates(struct intel_dp
> *intel_dp)
> intel_dp->num_sink_rates = i;
> }
>
> +static void intel_dp_set_default_max_sink_lane_count(struct intel_dp
> *intel_dp)
> +{
> + intel_dp->max_sink_lane_count = 1;
> +}
> +
> +static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct intel_encoder *encoder = _dig_port->base;
> +
> + intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> +
> + switch (intel_dp->max_sink_lane_count) {
> + case 1:
> + case 2:
> + case 4:
> + return;
> + }
> +
> + drm_err(_to_i915(intel_dp)->drm,
> + "[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD max lane count
> (%d), using default\n",
> + connector->base.base.id, connector->base.name,
> + encoder->base.base.id, encoder->base.name,
> + intel_dp->max_sink_lane_count);
> +
> + intel_dp_set_default_max_sink_lane_count(intel_dp);
> +}
> +
> /* Get length of rates array potentially limited by max_rate. */
> static int intel_dp_rate_limit_len(const int *rates, int len, int max_rate)
> {
> @@ -230,7 +259,7 @@ static int intel_dp_max_common_lane_count(struct intel_dp
> *intel_dp)
> {
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> int source_max = dig_port->max_lanes;
> - int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
> + int sink_max = intel_dp->max_sink_lane_count;
> int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
> int lttpr_max =
> drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
>
> @@ -242,7 +271,15 @@ static int intel_dp_max_common_lane_count(struct
> intel_dp *intel_dp)
>
> int intel_dp_max_lane_count(struct intel_dp *intel_dp)
> {
> - return intel_dp->max_link_lane_count;
> + switch (intel_dp->max_link_lane_count) {
> + case 1:
> + case 2:
> + case 4:
> + return intel_dp->max_link_lane_count;
> + default:
> + MISSING_CASE(intel_dp->max_link_lane_count);
> + return 1;
> + }
> }
I guess this is just a second level sanity check. I was wondering it
gets confusing and people start thinking this can actually happen,
but I suppose the MISSING_CASE() should be indication enough that it
in fact should not happen.
Series looks sane to me:
Reviewed-by: Ville Syrjälä
BTW there's now some kms_bw thing in igt which seems to forcing
DP connectors on left and right, and thus triggering a bunch of
WARNs.
>
> /*
> @@ -2600,6 +2637,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> intel_dp->use_rate_select = true;
> else
> intel_dp_set_sink_rates(intel_dp);
> + intel_dp_set_max_sink_lane_count(intel_dp);
>
> intel_dp_set_common_rates(intel_dp);
> intel_dp_reset_max_link_params(intel_dp);
> @@ -2645,6 +2683,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>drm_dp_is_branch(intel_dp->dpcd));
>
> intel_dp_set_sink_rates(intel_dp);
> + intel_dp_set_max_sink_lane_count(intel_dp);
> intel_dp_set_common_rates(intel_dp);
> }
>
> @@ -5011,6 +5050,7 @@ intel_dp_init_connector(struct intel_digital_port
> *dig_port,
>
> intel_dp_set_source_rates(intel_dp);
>
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/locking: fix __stack_depot_* name conflict
== Series Details == Series: drm/locking: fix __stack_depot_* name conflict URL : https://patchwork.freedesktop.org/series/95940/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10752_full -> Patchwork_21365_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21365_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21365_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_21365_full: ### IGT changes ### Possible regressions * igt@kms_bw@linear-tiling-1-displays-2560x1440p: - shard-snb: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-snb2/igt@kms...@linear-tiling-1-displays-2560x1440p.html Known issues Here are the changes found in Patchwork_21365_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-kbl: [PASS][2] -> [DMESG-WARN][3] ([i915#180]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-kbl1/igt@gem_ctx_isolation@preservation...@vecs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-kbl7/igt@gem_ctx_isolation@preservation...@vecs0.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +4 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-apl: NOTRUN -> [DMESG-WARN][9] ([i915#180]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-apl8/igt@gem_exec_susp...@basic-s3.html * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][10] -> [DMESG-WARN][11] ([i915#118]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk3/igt@gem_exec_whis...@basic-fds-all.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-glk5/igt@gem_exec_whis...@basic-fds-all.html * igt@gem_exec_whisper@basic-queues-forked: - shard-iclb: [PASS][12] -> [INCOMPLETE][13] ([i915#1895]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-iclb8/igt@gem_exec_whis...@basic-queues-forked.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-iclb5/igt@gem_exec_whis...@basic-queues-forked.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-tglb1/igt@gem_huc_c...@huc-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][16] ([i915#3002]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-snb5/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@unsync-overlap: - shard-tglb: NOTRUN -> [SKIP][17] ([i915#3297]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-tglb1/igt@gem_userptr_bl...@unsync-overlap.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN -> [FAIL][18] ([i915#3318]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-apl8/igt@gem_userptr_bl...@vma-merge.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / [i915#716]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/shard-glk8/igt@gen9_exec_pa...@allowed-all.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/shard-glk3/igt@gen9_exec_pa...@allowed-all.html * igt@i915_selftest@live@hangcheck: - shard-snb: [PASS][21] -> [INCOMPLETE][22] ([i915#3921]) [21]:
[Intel-gfx] [PATCH v2 2/6] drm/i915/dp: Ensure sink rate values are always valid
Atm, there are no sink rate values set for DP (vs. eDP) sinks until the
DPCD capabilities are successfully read from the sink. During this time
intel_dp->num_common_rates is 0 which can lead to a
intel_dp->common_rates[-1](*)
access, which is an undefined behaviour, in the following cases:
- In intel_dp_sync_state(), if the encoder is enabled without a sink
connected to the encoder's connector (BIOS enabled a monitor, but the
user unplugged the monitor until the driver loaded).
- In intel_dp_sync_state() if the encoder is enabled with a sink
connected, but for some reason the DPCD read has failed.
- In intel_dp_compute_link_config() if modesetting a connector without
a sink connected on it.
- In intel_dp_compute_link_config() if modesetting a connector with a
a sink connected on it, but before probing the connector first.
To avoid the (*) access in all the above cases, make sure that the sink
rate table - and hence the common rate table - is always valid, by
setting a default minimum sink rate when registering the connector
before anything could use it.
I also considered setting all the DP link rates by default, so that
modesetting with higher resolution modes also succeeds in the last two
cases above. However in case a sink is not connected that would stop
working after the first modeset, due to the LT fallback logic. So this
would need more work, beyond the scope of this fix.
As I mentioned in the previous patch, I don't think the issue this patch
fixes is user visible, however it is an undefined behaviour by
definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable.
v2: Clear the default sink rates, before initialzing these for eDP.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc:
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 23de500d56b52..9cbe85746fc41 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -120,6 +120,12 @@ bool intel_dp_is_uhbr(const struct intel_crtc_state
*crtc_state)
return crtc_state->port_clock >= 100;
}
+static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp)
+{
+ intel_dp->sink_rates[0] = 162000;
+ intel_dp->num_sink_rates = 1;
+}
+
/* update sink rates from dpcd */
static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
{
@@ -2556,6 +2562,9 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
*/
intel_psr_init_dpcd(intel_dp);
+ /* Clear the default sink rates */
+ intel_dp->num_sink_rates = 0;
+
/* Read the eDP 1.4+ supported link rates. */
if (intel_dp->edp_dpcd[0] >= DP_EDP_14) {
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
@@ -5003,6 +5012,8 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
}
intel_dp_set_source_rates(intel_dp);
+ intel_dp_set_default_sink_rates(intel_dp);
+ intel_dp_set_common_rates(intel_dp);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
--
2.27.0
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Split plane updates to noarm+arm phases
== Series Details == Series: drm/i915: Split plane updates to noarm+arm phases URL : https://patchwork.freedesktop.org/series/95962/ State : success == Summary == CI Bug Log - changes from CI_DRM_10752 -> Patchwork_21368 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/index.html Known issues Here are the changes found in Patchwork_21368 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([fdo#109315]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#1155]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#4103]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([fdo#109285]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([i915#1072]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#3301]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][11] ([i915#2940]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_lrc: - fi-bsw-n3050: [DMESG-FAIL][13] ([i915#2373]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21368/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 Participating hosts (38 -> 37) -- Additional (1): fi-tgl-1115g4 Missing(2): bat-dg1-6 bat-dg1-5 Build changes - * Linux: CI_DRM_10752 -> Patchwork_21368 CI-20190529: 20190529 CI_DRM_10752: c76aaeb23ed1eebb2af30e8ba3dca7c31b9f66ec @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6252: 996f2707195ed10c19905bcd8ccdb860a5e9d9c5 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21368: c83a5cef2006f8aa4919634eff6e2e4c8bbb3aff @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits ==
Re: [Intel-gfx] [PATCH] drm/i915: Clean-up bonding debug message.
On Mon, Oct 18, 2021 at 11:24:21AM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, Rodrigo Vivi wrote:
> > We should stop using the gen name and the "+" to reference
> > the newer platforms.
> > And on this case specifically we can simplify the debug
> > message even further.
>
> Reviewed-by: Jani Nikula
thanks, pushed
>
> >
> > Cc: Jani Nikula
> > Cc: Matthew Brost
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index d225d3dd0b40..30759b651180 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -479,7 +479,7 @@ set_proto_ctx_engines_bond(struct i915_user_extension
> > __user *base, void *data)
> > if (GRAPHICS_VER(i915) >= 12 && !IS_TIGERLAKE(i915) &&
> > !IS_ROCKETLAKE(i915) && !IS_ALDERLAKE_S(i915)) {
> > drm_dbg(>drm,
> > - "Bonding on gen12+ aside from TGL, RKL, and ADL_S not
> > supported\n");
> > + "Bonding not supported on this platform\n");
> > return -ENODEV;
> > }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Don't propagate the gen split confusion further
On Mon, Oct 18, 2021 at 11:25:00AM +0300, Jani Nikula wrote:
> On Fri, 15 Oct 2021, Rodrigo Vivi wrote:
> > There's no such thing as gen13. It is either display 13
> > or graphics 13. Don't propagate the gen12 confusion
> > further.
>
> Reviewed-by: Jani Nikula
thanks, pushed
>
> >
> > Cc: Joonas Lahtinen
> > Cc: Jani Nikula
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index da9055c3ebf0..1e221fbe37fd 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8263,7 +8263,7 @@ enum {
> >
> > /*
> > * The below are numbered starting from "S1" on gen11/gen12, but starting
> > - * with gen13 display, the bspec switches to a 0-based numbering scheme
> > + * with display 13, the bspec switches to a 0-based numbering scheme
> > * (although the addresses stay the same so new S0 = old S1, new S1 = old
> > S2).
> > * We'll just use the 0-based numbering here for all platforms since it's
> > the
> > * way things will be named by the hardware team going forward, plus it's
> > more
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Move PCH refclok stuff into its own file
On Mon, Oct 18, 2021 at 11:13:41AM +0300, Ville Syrjälä wrote: > On Mon, Oct 18, 2021 at 09:56:33AM +1000, David Airlie wrote: > > On Fri, Oct 15, 2021 at 5:16 PM Ville Syrjala > > wrote: > > > > > > From: Ville Syrjälä > > > > > > Move the PCH refclk stuff (including all the LPT/WPT > > > iCLKIP/CLKOUT_DP things) to its own file. > > > > > > We also suck in the mPHY programming from intel_fdi.c > > > since we're the only caller. > > > > The title of the patch has a typo refclok->reclock. > > I must be blind since I don't see the typo. Oh now I see it. Your suggested fix had another typo ;) -- Ville Syrjälä Intel
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Split plane updates to noarm+arm phases
== Series Details == Series: drm/i915: Split plane updates to noarm+arm phases URL : https://patchwork.freedesktop.org/series/95962/ 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_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Split plane updates to noarm+arm phases
== Series Details ==
Series: drm/i915: Split plane updates to noarm+arm phases
URL : https://patchwork.freedesktop.org/series/95962/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4347a5768329 drm/i915: Reject planar formats when doing async flips
9ca3181d87a4 drm/i915: Fix async flip with decryption and/or DPT
35deba336895 drm/i915: Fix up the sprite namespacing
41063002deec drm/i915: Split update_plane() into update_noarm() + update_arm()
-:596: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#596: FILE: drivers/gpu/drm/i915/i915_trace.h:324:
+ TP_STRUCT__entry(
-:605: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#605: FILE: drivers/gpu/drm/i915/i915_trace.h:333:
+ TP_fast_assign(
-:614: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#614: FILE: drivers/gpu/drm/i915/i915_trace.h:342:
+ TP_printk("pipe %c, plane %s, frame=%u, scanline=%u, "
DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,
total: 0 errors, 1 warnings, 2 checks, 521 lines checked
e1f91ae7cee9 drm/i915: Split skl+ plane update into noarm+arm pair
901268a16647 drm/i915: Split pre-skl primary plane update into noarm+arm pair
1202bc6cfc3a drm/i915: Split g4x+ sprite plane update into noarm+arm pair
437389a78c69 drm/i915: Split ivb+ sprite plane update into noarm+arm pair
c83a5cef2006 drm/i915: Split vlv/chv sprite plane update into noarm+arm pair
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: Fix link parameter use in lack of a valid DPCD
== Series Details == Series: drm/i915/dp: Fix link parameter use in lack of a valid DPCD URL : https://patchwork.freedesktop.org/series/95948/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10752 -> Patchwork_21367 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21367 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21367, 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_21367/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21367: ### IGT changes ### Possible regressions * igt@kms_setmode@basic-clone-single-crtc: - fi-bsw-kefka: [PASS][1] -> [WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-kefka/igt@kms_setm...@basic-clone-single-crtc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-bsw-kefka/igt@kms_setm...@basic-clone-single-crtc.html Known issues Here are the changes found in Patchwork_21367 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][3] ([fdo#109271]) +22 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([fdo#109315]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([fdo#109315] / [i915#2575]) +16 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#1155]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gem_contexts: - fi-kbl-7500u: [PASS][8] -> [INCOMPLETE][9] ([i915#2369] / [i915#794]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-kbl-7500u/igt@i915_selftest@live@gem_contexts.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-kbl-7500u/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][10] -> [INCOMPLETE][11] ([i915#3921]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_busy@basic: - fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271]) +4 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-skl-6600u/igt@kms_b...@basic.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#4103]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-bsw-kefka: [PASS][15] -> [SKIP][16] ([fdo#109271]) +25 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_flip@basic-plain-flip@c-dp1: - fi-cfl-8109u: [PASS][17] -> [FAIL][18] ([i915#4165]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][19] ([fdo#109285]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21367/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html *
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dp: Fix link parameter use in lack of a valid DPCD
== Series Details == Series: drm/i915/dp: Fix link parameter use in lack of a valid DPCD URL : https://patchwork.freedesktop.org/series/95948/ 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_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Fix link parameter use in lack of a valid DPCD
== Series Details == Series: drm/i915/dp: Fix link parameter use in lack of a valid DPCD URL : https://patchwork.freedesktop.org/series/95948/ State : warning == Summary == $ dim checkpatch origin/drm-tip 07ef5697be87 drm/i915/dp: Skip the HW readout of DPCD on disabled encoders 3e749fec1e8a drm/i915/dp: Ensure sink rate values are always valid 92ae68cc3ed6 drm/i915/dp: Ensure max link params are always valid 778589c2703f drm/i915/dp: Ensure sink/link max lane count values are always valid 596c4b44 drm/i915/dp: Sanitize sink rate DPCD register values -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: buggy monitor). So fixup the invalid DPCD sink rate values already and print total: 0 errors, 1 warnings, 0 checks, 33 lines checked 00e86ff8ce34 drm/i915/dp: Sanitize link common rate array lookups -:45: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #45: FILE: drivers/gpu/drm/i915/display/intel_dp.c:622: + intel_dp_common_rate(intel_dp, index - 1), total: 0 errors, 1 warnings, 0 checks, 77 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95942/ State : success == Summary == CI Bug Log - changes from CI_DRM_10752 -> Patchwork_21366 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/index.html Known issues Here are the changes found in Patchwork_21366 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([fdo#109315]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-kbl-soraka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([fdo#109315] / [i915#2575]) +16 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-1115g4: NOTRUN -> [FAIL][5] ([i915#1888]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#1155]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_heartbeat: - fi-bsw-nick:[PASS][8] -> [DMESG-FAIL][9] ([i915#541]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-nick/igt@i915_selftest@live@gt_heartbeat.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-bsw-nick/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-tgl-1115g4: NOTRUN -> [DMESG-FAIL][10] ([i915#3987]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#4103]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][13] ([fdo#109285]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#3301]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][16] ([i915#2940]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_lrc: - fi-bsw-n3050: [DMESG-FAIL][18] ([i915#2373]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21366/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
Re: [Intel-gfx] [PATCH v2 4/4] vgaswitcheroo: do not check for NULL debugfs dentry
On 10/17/2021 10:03 PM, Lukas Wunner wrote:
On Wed, Oct 13, 2021 at 08:36:01PM +0200, Nirmoy Das wrote:
Debugfs APIs returns encoded error on failure so use
debugfs_lookup() instead of checking for NULL.
The commit message no longer matches up with the patch itself
(debugfs_lookup() isn't called).
My suggestion would be something like:
Retry creation of the vga_switcheroo debugfs if a previous
invocation of debugfs_create_dir() returned an error code.
With that addressed,
Reviewed-by: Lukas Wunner
Thanks, Lukas. Yes, I missed that commit message modification.
Nirmoy
Thanks,
Lukas
Signed-off-by: Nirmoy Das
---
drivers/gpu/vga/vga_switcheroo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 365e6ddbe90f..07ab8d85e899 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -914,7 +914,7 @@ static void vga_switcheroo_debugfs_fini(struct vgasr_priv
*priv)
static void vga_switcheroo_debugfs_init(struct vgasr_priv *priv)
{
/* already initialised */
- if (priv->debugfs_root)
+ if (priv->debugfs_root && !IS_ERR(priv->debugfs_root))
return;
priv->debugfs_root = debugfs_create_dir("vgaswitcheroo", NULL);
--
2.32.0
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 2/2] dma-buf: Fix dma_resv_test_signaled.
Am 15.10.21 um 14:52 schrieb Maarten Lankhorst:
Op 15-10-2021 om 14:07 schreef Christian König:
Am 15.10.21 um 13:57 schrieb Maarten Lankhorst:
Commit 7fa828cb9265 ("dma-buf: use new iterator in dma_resv_test_signaled")
accidentally forgot to test whether the dma-buf is actually signaled, breaking
pretty much everything depending on it.
NAK, the dma_resv_for_each_fence_unlocked() returns only unsignaled fences. So
the code is correct as it is.
That seems like it might cause some unexpected behavior when that function is
called with one of the fence locks held, if it calls dma_fence_signal().
Could it be changed to only test the signaled bit, in which case this patch
would still be useful?
That's exactly what I suggested as well, but Daniel was against that
because of concerns around barriers.
Or at least add some lockdep annotations, that fence->lock might be taken. So
any hangs would at least be easy to spot with lockdep.
That should be trivial doable.
Christian.
~Maarten
___
Linaro-mm-sig mailing list
linaro-mm-...@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-mm-sig
[Intel-gfx] [PATCH linux-next] drm/i915/display: Remove unused assignment
The assignment will be overwritten by the later, but the variable is not used. The clang_analyzer complains as follows: drivers/gpu/drm/i915/display/intel_dpll.c:1568:2 warning: Value stored to 'dpio_val' is never read Reported-by: Zeal Robot Signed-off-by: luo penghao --- drivers/gpu/drm/i915/display/intel_dpll.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c b/drivers/gpu/drm/i915/display/intel_dpll.c index 28b1616..cb77d7f 100644 --- a/drivers/gpu/drm/i915/display/intel_dpll.c +++ b/drivers/gpu/drm/i915/display/intel_dpll.c @@ -1653,7 +1653,6 @@ static void chv_prepare_pll(const struct intel_crtc_state *crtc_state) bestp1 = crtc_state->dpll.p1; bestp2 = crtc_state->dpll.p2; vco = crtc_state->dpll.vco; - dpio_val = 0; loopfilter = 0; vlv_dpio_get(dev_priv); -- 2.15.2
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 1/2] dma-buf: Fix dma_resv_wait_timeout handling of timeout = 0.
Am 15.10.21 um 13:57 schrieb Maarten Lankhorst:
Commit ada5c48b11a3 ("dma-buf: use new iterator in dma_resv_wait_timeout")
accidentally started mishandling timeout = 0, by forcing a blocking wait
with timeout = 1 passed to fences. This is not intended, as timeout = 0
may be used for peeking, similar to test_signaled.
Fixes: ada5c48b11a3 ("dma-buf: use new iterator in dma_resv_wait_timeout")
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Maarten Lankhorst
Sorry for the delay, back from sick leave just today.
Good catch, but when I read the old code correctly that was also broken
before by passing in 1 to dma_fence_wait_timeout() for a timeout of 0.
---
drivers/dma-buf/dma-resv.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 9eb2baa387d4..70a8082660c5 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -617,18 +617,18 @@ EXPORT_SYMBOL_GPL(dma_resv_get_fences);
long dma_resv_wait_timeout(struct dma_resv *obj, bool wait_all, bool intr,
unsigned long timeout)
{
- long ret = timeout ? timeout : 1;
+ long ret = timeout ?: 1;
Please don't change the coding style here.
Apart from that looks good to me.
Christian.
struct dma_resv_iter cursor;
struct dma_fence *fence;
dma_resv_iter_begin(, obj, wait_all);
dma_resv_for_each_fence_unlocked(, fence) {
+ ret = dma_fence_wait_timeout(fence, intr, timeout);
+ if (ret <= 0)
+ break;
- ret = dma_fence_wait_timeout(fence, intr, ret);
- if (ret <= 0) {
- dma_resv_iter_end();
- return ret;
- }
+ if (timeout)
+ timeout = ret;
}
dma_resv_iter_end();
Re: [Intel-gfx] [PATCH 16/28] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2
Thanks for the notice. Going to take a deeper look into this tomorrow.
Basically looks like we messed up the fence ref count somehow.
Thanks,
Christian.
Am 17.10.21 um 16:40 schrieb Nicolas Frattaroli:
On Dienstag, 5. Oktober 2021 13:37:30 CEST Christian König wrote:
Simplifying the code a bit.
v2: use dma_resv_for_each_fence
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/scheduler/sched_main.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c index 042c16b5d54a..5bc5f775abe1
100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -699,30 +699,16 @@ int drm_sched_job_add_implicit_dependencies(struct
drm_sched_job *job, struct drm_gem_object *obj,
bool write)
{
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
int ret;
- struct dma_fence **fences;
- unsigned int i, fence_count;
-
- if (!write) {
- struct dma_fence *fence = dma_resv_get_excl_unlocked(obj-
resv);
-
- return drm_sched_job_add_dependency(job, fence);
- }
-
- ret = dma_resv_get_fences(obj->resv, NULL, _count, );
- if (ret || !fence_count)
- return ret;
- for (i = 0; i < fence_count; i++) {
- ret = drm_sched_job_add_dependency(job, fences[i]);
+ dma_resv_for_each_fence(, obj->resv, write, fence) {
+ ret = drm_sched_job_add_dependency(job, fence);
if (ret)
- break;
+ return ret;
}
-
- for (; i < fence_count; i++)
- dma_fence_put(fences[i]);
- kfree(fences);
- return ret;
+ return 0;
}
EXPORT_SYMBOL(drm_sched_job_add_implicit_dependencies);
Hi Christian,
unfortunately, this breaks lima on the rk3328 quite badly. Running glmark2-
es2-drm just locks up the device with the following traces:
[ 39.624100] [ cut here ]
[ 39.624555] refcount_t: addition on 0; use-after-free.
[ 39.625058] WARNING: CPU: 0 PID: 123 at lib/refcount.c:25
refcount_warn_saturate+0xa4/0x150
[ 39.625825] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.626753] CPU: 0 PID: 123 Comm: pp Tainted: G C5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.627614] Hardware name: Pine64 Rock64 (DT)
[ 39.628004] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.628628] pc : refcount_warn_saturate+0xa4/0x150
[ 39.629062] lr : refcount_warn_saturate+0xa4/0x150
[ 39.629495] sp : ffc0124d3d90
[ 39.629794] x29: ffc0124d3d90 x28: x27:
[ 39.630441] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.631087] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.631731] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.632377] x17: 0001 x16: 0001 x15:
0765076507720766
[ 39.633022] x14: 072d077207650774 x13: 0765076507720766 x12:
072d077207650774
[ 39.633668] x11: 0720072007200720 x10: ffc011c4b1b0 x9 :
ffc01010ac54
[ 39.634314] x8 : dfff x7 : ffc011cfb1b0 x6 :
0001
[ 39.634960] x5 : ff807fb4d980 x4 : x3 :
0027
[ 39.635605] x2 : x1 : x0 :
ff8000e1f000
[ 39.636250] Call trace:
[ 39.636475] refcount_warn_saturate+0xa4/0x150
[ 39.636879] drm_sched_entity_pop_job+0x414/0x4a0
[ 39.637307] drm_sched_main+0xe4/0x450
[ 39.637651] kthread+0x12c/0x140
[ 39.637949] ret_from_fork+0x10/0x20
[ 39.638279] ---[ end trace 47528e09b2512330 ]---
[ 39.638783] [ cut here ]
[ 39.639214] refcount_t: underflow; use-after-free.
[ 39.639687] WARNING: CPU: 0 PID: 123 at lib/refcount.c:28
refcount_warn_saturate+0xf8/0x150
[ 39.640447] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.641373] CPU: 0 PID: 123 Comm: pp Tainted: GWC5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.642237] Hardware name: Pine64 Rock64 (DT)
[ 39.642632] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.643257] pc : refcount_warn_saturate+0xf8/0x150
[ 39.643693] lr : refcount_warn_saturate+0xf8/0x150
[ 39.644128] sp : ffc0124d3d90
[ 39.644430] x29: ffc0124d3d90 x28: x27:
[ 39.645077] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.645724] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.646372] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.647020] x17: 0001 x16: 0001 x15:
[Intel-gfx] [PATCH linux-next] drm/i915/display: Remove unused variable and its assignment.
Variable is not used in functions, and its assignment is redundant too. So it should be deleted. The clang_analyzer complains as follows: drivers/gpu/drm/i915/display/intel_dpll.c:1653:2 warning: Value stored to 'bestm1' is never read. drivers/gpu/drm/i915/display/intel_dpll.c:1651:2 warning: Value stored to 'bestn' is never read. Reported-by: Zeal Robot Signed-off-by: luo penghao --- drivers/gpu/drm/i915/display/intel_dpll.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c b/drivers/gpu/drm/i915/display/intel_dpll.c index b84ed4a..28b1616 100644 --- a/drivers/gpu/drm/i915/display/intel_dpll.c +++ b/drivers/gpu/drm/i915/display/intel_dpll.c @@ -1644,13 +1644,11 @@ static void chv_prepare_pll(const struct intel_crtc_state *crtc_state) enum pipe pipe = crtc->pipe; enum dpio_channel port = vlv_pipe_to_channel(pipe); u32 loopfilter, tribuf_calcntr; - u32 bestn, bestm1, bestm2, bestp1, bestp2, bestm2_frac; + u32 bestm2, bestp1, bestp2, bestm2_frac; u32 dpio_val; int vco; - bestn = crtc_state->dpll.n; bestm2_frac = crtc_state->dpll.m2 & 0x3f; - bestm1 = crtc_state->dpll.m1; bestm2 = crtc_state->dpll.m2 >> 22; bestp1 = crtc_state->dpll.p1; bestp2 = crtc_state->dpll.p2; -- 2.15.2
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi Jani, On Fri, 15 Oct 2021 12:56:58 +0300 Jani Nikula wrote: > > The fix looks good, but I'd rename __stack_depot_print too added in the > same commit. Do you want to respin or shall I take it from here? If you are happy to take it on, then thanks. -- Cheers, Stephen Rothwell pgpMOSQCTIEFb.pgp Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH] drm/i915: Prefer struct_size over open coded arithmetic
Hi Daniel and Jani, On Wed, Oct 13, 2021 at 01:51:30PM +0200, Daniel Vetter wrote: > On Wed, Oct 13, 2021 at 02:24:05PM +0300, Jani Nikula wrote: > > On Mon, 11 Oct 2021, Len Baker wrote: > > > Hi, > > > > > > On Sun, Oct 03, 2021 at 12:42:58PM +0200, Len Baker wrote: > > >> As noted in the "Deprecated Interfaces, Language Features, Attributes, > > >> and Conventions" documentation [1], size calculations (especially > > >> multiplication) should not be performed in memory allocator (or similar) > > >> function arguments due to the risk of them overflowing. This could lead > > >> to values wrapping around and a smaller allocation being made than the > > >> caller was expecting. Using those allocations could lead to linear > > >> overflows of heap memory and other misbehaviors. > > >> > > >> In this case these are not actually dynamic sizes: all the operands > > >> involved in the calculation are constant values. However it is better to > > >> refactor them anyway, just to keep the open-coded math idiom out of > > >> code. > > >> > > >> So, add at the end of the struct i915_syncmap a union with two flexible > > >> array members (these arrays share the same memory layout). This is > > >> possible using the new DECLARE_FLEX_ARRAY macro. And then, use the > > >> struct_size() helper to do the arithmetic instead of the argument > > >> "size + count * size" in the kmalloc and kzalloc() functions. > > >> > > >> Also, take the opportunity to refactor the __sync_seqno and __sync_child > > >> making them more readable. > > >> > > >> This code was detected with the help of Coccinelle and audited and fixed > > >> manually. > > >> > > >> [1] > > >> https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments > > >> > > >> Signed-off-by: Len Baker > > >> --- > > >> drivers/gpu/drm/i915/i915_syncmap.c | 12 > > >> 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > I received a mail telling that this patch doesn't build: > > > > > > == Series Details == > > > > > > Series: drm/i915: Prefer struct_size over open coded arithmetic > > > URL : https://patchwork.freedesktop.org/series/95408/ > > > State : failure > > > > > > But it builds without error against linux-next (tag next-20211001). > > > Against > > > which tree and branch do I need to build? > > > > drm-tip [1]. It's a sort of linux-next for graphics. I think there are > > still some branches that don't feed to linux-next. > > Yeah we need to get gt-next in linux-next asap. Joonas promised to send > out his patch to make that happen in dim. > -Daniel Is there a possibility that you give an "Acked-by" tag? And then this patch goes to the mainline through the Kees' tree or Gustavo's tree? Or is it better to wait for drm-tip to update? Regards, Len > > > > > BR, > > Jani. > > > > > > [1] https://cgit.freedesktop.org/drm/drm-tip > > > > > > > > > > Regards, > > > Len > > > > -- > > Jani Nikula, Intel Open Source Graphics Center > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 16/28] drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2
On Dienstag, 5. Oktober 2021 13:37:30 CEST Christian König wrote:
> Simplifying the code a bit.
>
> v2: use dma_resv_for_each_fence
>
> Signed-off-by: Christian König
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 26 ++
> 1 file changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c index 042c16b5d54a..5bc5f775abe1
> 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -699,30 +699,16 @@ int drm_sched_job_add_implicit_dependencies(struct
> drm_sched_job *job, struct drm_gem_object *obj,
> bool write)
> {
> + struct dma_resv_iter cursor;
> + struct dma_fence *fence;
> int ret;
> - struct dma_fence **fences;
> - unsigned int i, fence_count;
> -
> - if (!write) {
> - struct dma_fence *fence = dma_resv_get_excl_unlocked(obj-
>resv);
> -
> - return drm_sched_job_add_dependency(job, fence);
> - }
> -
> - ret = dma_resv_get_fences(obj->resv, NULL, _count, );
> - if (ret || !fence_count)
> - return ret;
>
> - for (i = 0; i < fence_count; i++) {
> - ret = drm_sched_job_add_dependency(job, fences[i]);
> + dma_resv_for_each_fence(, obj->resv, write, fence) {
> + ret = drm_sched_job_add_dependency(job, fence);
> if (ret)
> - break;
> + return ret;
> }
> -
> - for (; i < fence_count; i++)
> - dma_fence_put(fences[i]);
> - kfree(fences);
> - return ret;
> + return 0;
> }
> EXPORT_SYMBOL(drm_sched_job_add_implicit_dependencies);
Hi Christian,
unfortunately, this breaks lima on the rk3328 quite badly. Running glmark2-
es2-drm just locks up the device with the following traces:
[ 39.624100] [ cut here ]
[ 39.624555] refcount_t: addition on 0; use-after-free.
[ 39.625058] WARNING: CPU: 0 PID: 123 at lib/refcount.c:25
refcount_warn_saturate+0xa4/0x150
[ 39.625825] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.626753] CPU: 0 PID: 123 Comm: pp Tainted: G C5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.627614] Hardware name: Pine64 Rock64 (DT)
[ 39.628004] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.628628] pc : refcount_warn_saturate+0xa4/0x150
[ 39.629062] lr : refcount_warn_saturate+0xa4/0x150
[ 39.629495] sp : ffc0124d3d90
[ 39.629794] x29: ffc0124d3d90 x28: x27:
[ 39.630441] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.631087] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.631731] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.632377] x17: 0001 x16: 0001 x15:
0765076507720766
[ 39.633022] x14: 072d077207650774 x13: 0765076507720766 x12:
072d077207650774
[ 39.633668] x11: 0720072007200720 x10: ffc011c4b1b0 x9 :
ffc01010ac54
[ 39.634314] x8 : dfff x7 : ffc011cfb1b0 x6 :
0001
[ 39.634960] x5 : ff807fb4d980 x4 : x3 :
0027
[ 39.635605] x2 : x1 : x0 :
ff8000e1f000
[ 39.636250] Call trace:
[ 39.636475] refcount_warn_saturate+0xa4/0x150
[ 39.636879] drm_sched_entity_pop_job+0x414/0x4a0
[ 39.637307] drm_sched_main+0xe4/0x450
[ 39.637651] kthread+0x12c/0x140
[ 39.637949] ret_from_fork+0x10/0x20
[ 39.638279] ---[ end trace 47528e09b2512330 ]---
[ 39.638783] [ cut here ]
[ 39.639214] refcount_t: underflow; use-after-free.
[ 39.639687] WARNING: CPU: 0 PID: 123 at lib/refcount.c:28
refcount_warn_saturate+0xf8/0x150
[ 39.640447] Modules linked in: 8021q garp stp mrp llc crct10dif_ce
hantro_vpu(C) fuse ip_tables x_tables ipv6
[ 39.641373] CPU: 0 PID: 123 Comm: pp Tainted: GWC5.15.0-
rc1fratti-00251-g9c2ba265352a #158
[ 39.642237] Hardware name: Pine64 Rock64 (DT)
[ 39.642632] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 39.643257] pc : refcount_warn_saturate+0xf8/0x150
[ 39.643693] lr : refcount_warn_saturate+0xf8/0x150
[ 39.644128] sp : ffc0124d3d90
[ 39.644430] x29: ffc0124d3d90 x28: x27:
[ 39.645077] x26: x25: ffc0117fe000 x24:
ff8001ad73f8
[ 39.645724] x23: ffc0107fc3e0 x22: ffc0117fe000 x21:
ff801066
[ 39.646372] x20: ff8001ad73c0 x19: ff807db094c8 x18:
[ 39.647020] x17: 0001 x16: 0001 x15:
072007200720072e
[ 39.647666] x14: 0765076507720766 x13: 072007200720072e x12:
0765076507720766
[ 39.648312] x11: 0720072007200720 x10:
[Intel-gfx] [PATCH linux-next] drm/i915/display: Remove unused variable and corresponding assignment
Variable is not used in functions, and its assignment is redundant too.
So it should be deleted.
The clang_analyzer complains as follows:
drivers/gpu/drm/i915/display/vlv_dsi.c:143:2 warning:
Value stored to 'data' is never read.
Reported-by: Zeal Robot
Signed-off-by: luo penghao
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 081b772..634de91 100644
--- a/drivers/gpu/drm/i915/display/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/display/vlv_dsi.c
@@ -131,7 +131,7 @@ static ssize_t intel_dsi_host_transfer(struct mipi_dsi_host
*host,
enum port port = intel_dsi_host->port;
struct mipi_dsi_packet packet;
ssize_t ret;
- const u8 *header, *data;
+ const u8 *header;
i915_reg_t data_reg, ctrl_reg;
u32 data_mask, ctrl_mask;
@@ -140,7 +140,6 @@ static ssize_t intel_dsi_host_transfer(struct mipi_dsi_host
*host,
return ret;
header = packet.header;
- data = packet.payload;
if (msg->flags & MIPI_DSI_MSG_USE_LPM) {
data_reg = MIPI_LP_GEN_DATA(port);
--
2.15.2
[Intel-gfx] [PATCH linux-next] drm/i915: Remove redundant assignments
From: penghao luo
The assignment of variables will be overwritten later, so the
assignment here is meaningless.
The clang_analyzer complains as follows:
drivers/gpu/drm/i915/gem/i915_gem_userptr.c:291: warning:
Although the value stored to 'ret' is used in the enclosing expression,
the value is never actually read from 'ret’.
Reported-by: Zeal Robot
Signed-off-by: penghao luo
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 8ea0fa6..f6f944d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -288,7 +288,7 @@ int i915_gem_object_userptr_submit_init(struct
drm_i915_gem_object *obj)
if (!i915_gem_object_is_readonly(obj))
gup_flags |= FOLL_WRITE;
- pinned = ret = 0;
+ pinned = 0;
while (pinned < num_pages) {
ret = pin_user_pages_fast(obj->userptr.ptr + pinned * PAGE_SIZE,
num_pages - pinned, gup_flags,
--
2.15.2
[Intel-gfx] [PATCH linux-next] drm/i915/display: Remove unused variable in the for loop.
Variable is not used in the loop, and its assignment is redundant too.
So it should be deleted.
The clang_analyzer complains as follows:
drivers/gpu/drm/i915/display/intel_fb.c:1018:3 warning:
Value stored to 'cpp' is never read.
Reported-by: Zeal Robot
Signed-off-by: luo penghao
---
drivers/gpu/drm/i915/display/intel_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index fa1f375..b9b6a7a 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -998,7 +998,7 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
struct intel_framebuffer *
for (i = 0; i < num_planes; i++) {
struct fb_plane_view_dims view_dims;
unsigned int width, height;
- unsigned int cpp, size;
+ unsigned int size;
u32 offset;
int x, y;
int ret;
@@ -1015,7 +1015,7 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
struct intel_framebuffer *
return -EINVAL;
}
- cpp = fb->base.format->cpp[i];
+ fb->base.format->cpp[i];
intel_fb_plane_dims(fb, i, , );
ret = convert_plane_offset_to_xy(fb, i, width, , );
--
2.15.2
Re: [Intel-gfx] [PATCH linux-next] drm/i915/display: Remove unused variable in the for loop.
Hi luo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20211015]
url:
https://github.com/0day-ci/linux/commits/luo-penghao/drm-i915-display-Remove-unused-variable-in-the-for-loop/20211018-164557
base:7c832d2f9b959e3181370c8b0dacaf9efe13fc05
config: x86_64-randconfig-r014-20211018 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project
d245f2e8597bfb52c34810a328d42b990e4af1a4)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/1a3c67fc7e245a1130e2b59fe5a04ce82de697c0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
luo-penghao/drm-i915-display-Remove-unused-variable-in-the-for-loop/20211018-164557
git checkout 1a3c67fc7e245a1130e2b59fe5a04ce82de697c0
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_fb.c:1018:25: error: expression result
>> unused [-Werror,-Wunused-value]
fb->base.format->cpp[i];
~^
1 error generated.
vim +1018 drivers/gpu/drm/i915/display/intel_fb.c
977
978 int intel_fill_fb_info(struct drm_i915_private *i915, struct
intel_framebuffer *fb)
979 {
980 struct drm_i915_gem_object *obj = intel_fb_obj(>base);
981 u32 gtt_offset_rotated = 0;
982 u32 gtt_offset_remapped = 0;
983 unsigned int max_size = 0;
984 int i, num_planes = fb->base.format->num_planes;
985 unsigned int tile_size = intel_tile_size(i915);
986
987 intel_fb_view_init(i915, >normal_view,
I915_GGTT_VIEW_NORMAL);
988
989 drm_WARN_ON(>drm,
990 intel_fb_supports_90_270_rotation(fb) &&
991 intel_fb_needs_pot_stride_remap(fb));
992
993 if (intel_fb_supports_90_270_rotation(fb))
994 intel_fb_view_init(i915, >rotated_view,
I915_GGTT_VIEW_ROTATED);
995 if (intel_fb_needs_pot_stride_remap(fb))
996 intel_fb_view_init(i915, >remapped_view,
I915_GGTT_VIEW_REMAPPED);
997
998 for (i = 0; i < num_planes; i++) {
999 struct fb_plane_view_dims view_dims;
1000 unsigned int width, height;
1001 unsigned int size;
1002 u32 offset;
1003 int x, y;
1004 int ret;
1005
1006 /*
1007 * Plane 2 of Render Compression with Clear Color fb
modifier
1008 * is consumed by the driver and not passed to DE. Skip
the
1009 * arithmetic related to alignment and offset
calculation.
1010 */
1011 if (is_gen12_ccs_cc_plane(>base, i)) {
1012 if (IS_ALIGNED(fb->base.offsets[i], PAGE_SIZE))
1013 continue;
1014 else
1015 return -EINVAL;
1016 }
1017
> 1018 fb->base.format->cpp[i];
1019 intel_fb_plane_dims(fb, i, , );
1020
1021 ret = convert_plane_offset_to_xy(fb, i, width, , );
1022 if (ret)
1023 return ret;
1024
1025 init_plane_view_dims(fb, i, width, height, _dims);
1026
1027 /*
1028 * First pixel of the framebuffer from
1029 * the start of the normal gtt mapping.
1030 */
1031 fb->normal_view.color_plane[i].x = x;
1032 fb->normal_view.color_plane[i].y = y;
1033 fb->normal_view.color_plane[i].stride =
fb->base.pitches[i];
1034
1035 offset = calc_plane_aligned_offset(fb, i, , );
1036
1037 if (intel_fb_supports_90_270_rotation(fb))
1038 gtt_offset_rotated += calc_plane_remap_info(fb,
i, _dims,
1039
offset, gtt_offset_rotated, x, y,
1040
>rotated_view);
1041
1042 if (intel_fb_needs_pot_stride_remap(fb))
1043 gtt_offset_remapped +=
calc_plane_remap_info(fb, i, _dims,
1044
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Simplify handling of modifiers (rev10)
Hi Petri, Tomi,
could you check the failure below?
On Fri, Oct 15, 2021 at 11:19:13AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Simplify handling of modifiers (rev10)
> URL : https://patchwork.freedesktop.org/series/95579/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10741_full -> Patchwork_21343_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_21343_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_21343_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_21343_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@kms_vblank@pipe-a-wait-busy:
> - shard-skl: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-skl1/igt@kms_vbl...@pipe-a-wait-busy.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-skl1/igt@kms_vbl...@pipe-a-wait-busy.html
This is from Patchwork_21343/shard-skl1/19/dmesg.log , where the above
test passes and is followed by more passing tests, until
kms_busy/extended-modeset-hang-oldfb
also passes at least according to igt_runner.log, though I can't see it in
dmesg.log. After that:
[1091.672412] Overall timeout time exceeded, stopping.
Is it just an overall timeout problem, or some test after
kms_busy/extended-modeset-hand-oldfb?
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@kms_bw@linear-tiling-3-displays-3840x2160p}:
> - shard-snb: NOTRUN -> [FAIL][3]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-snb6/igt@kms...@linear-tiling-3-displays-3840x2160p.html
>
> * {igt@kms_bw@linear-tiling-4-displays-1920x1080p}:
> - shard-apl: NOTRUN -> [DMESG-FAIL][4]
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-apl3/igt@kms...@linear-tiling-4-displays-1920x1080p.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_21343_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@feature_discovery@chamelium:
> - shard-tglb: NOTRUN -> [SKIP][5] ([fdo#111827])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-tglb3/igt@feature_discov...@chamelium.html
>
> * igt@gem_ctx_persistence@hostile:
> - shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-tglb2/igt@gem_ctx_persiste...@hostile.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-tglb5/igt@gem_ctx_persiste...@hostile.html
>
> * igt@gem_ctx_persistence@legacy-engines-mixed:
> - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +3
> similar issues
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html
>
> * igt@gem_exec_fair@basic-none-rrul@rcs0:
> - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html
>
> * igt@gem_exec_fair@basic-none-solo@rcs0:
> - shard-kbl: NOTRUN -> [FAIL][11] ([i915#2842])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
>
> * igt@gem_exec_fair@basic-none-vip@rcs0:
> - shard-tglb: NOTRUN -> [FAIL][12] ([i915#2842])
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-tglb1/igt@gem_exec_fair@basic-none-...@rcs0.html
>
> * igt@gem_exec_fair@basic-pace-solo@rcs0:
> - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842])
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-iclb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21343/shard-iclb4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
>
> * igt@gem_exec_whisper@basic-queues-forked-all:
> - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118])
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10741/shard-glk2/igt@gem_exec_whis...@basic-queues-forked-all.html
>[16]:
>
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Split skl+ plane update into noarm+arm pair
On Mon, Oct 18, 2021 at 02:50:26PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Chop skl_program_plane() into two halves. Fist half becomes
> the _noarm() variant, second part the _arm() variant.
>
> Fortunately I have already previously grouped the register
> writes into roughtly the correct order, so the split looks
> surprisingly clean.
>
> A few notable oddities I did not realize were self arming
> are AUX_DIST and COLOR_CTL.
>
> i915_update_info doesn't look too terrible on my cfl running
> kms_atomic_transition --r plane-all-transition --extended:
> w/o patch w/ patch
> Updates: 2178 Updates: 2018
>| |
>1us | 1us |
>| |
>4us | 4us |*
>|* |**
> 16us |**16us |***
>|***|
> 66us | 66us |
>| |
> 262us | 262us |
>| |
>1ms | 1ms |
>| |
>4ms | 4ms |
>| |
> 17ms | 17ms |
>| |
> Min update: 8332ns Min update: 6164ns
> Max update: 48758ns Max update: 31808ns
> Average update: 19959ns Average update: 13159ns
> Overruns > 100us: 0 Overruns > 100us: 0
>
> And with lockdep enabled:
> w/o patch w/ patch
> Updates: 2177 Updates: 2172
>| |
>1us | 1us |
>| |
>4us | 4us |
>|*** |*
> 16us |** 16us |**
>|*** |*
> 66us |66us |
>| |
> 262us | 262us |
>| |
>1ms | 1ms |
>| |
>4ms | 4ms |
>| |
> 17ms |17ms |
>| |
> Min update: 12645ns Min update: 9980ns
> Max update: 50153ns Max update: 33533ns
> Average update: 25337ns Average update: 18245ns
> Overruns > 250us: 0 Overruns > 250us: 0
>
> TODO: On icl+ everything seems to be armed by PLANE_SURF, so we
> can optimize this even further on modern platforms. But I
> think there's a bit of refactoring to be done first to
> figure out the best way to go about it (eg. just reusing
> the current skl+ functions, or doing a lower level split).
>
> TODO: Split scaler programming as well, but IIRC the scaler
> has some oddball double buffering behaviour on some
> platforms, so needs proper reverse engineering
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Ville Syrjälä
Should I use that one as a base for further splitting, i.e for DG2?
Which refactoring has to be done first, as I understand should be
pretty safe to leave only PLANE_SURF update in arm section, and
of course scaler is a different thing.
Stan
> ---
> .../drm/i915/display/skl_universal_plane.c| 113 +++---
> 1 file changed, 72 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 74f3870d39b1..2a822e1e465e 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -1050,60 +1050,32 @@ static void icl_plane_csc_load_black(struct
> intel_plane *plane)
> }
>
> static void
> -skl_program_plane(struct intel_plane *plane,
> - const struct intel_crtc_state *crtc_state,
> - const struct intel_plane_state *plane_state,
> - int color_plane)
> +skl_program_plane_noarm(struct intel_plane *plane,
> + const struct intel_crtc_state *crtc_state,
> + const struct intel_plane_state *plane_state,
> + int color_plane)
> {
> struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> enum plane_id plane_id = plane->id;
> enum pipe pipe = plane->pipe;
> - const struct drm_intel_sprite_colorkey *key = _state->ckey;
> u32 stride = skl_plane_stride(plane_state, color_plane);
> const struct
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95942/ 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_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v9,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95942/ State : warning == Summary == $ dim checkpatch origin/drm-tip 53802cc4ee04 drm/i915/gem: Break out some shmem backend utils 52832ef9f7a8 drm/i915/ttm: add tt shmem backend -:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #16: dropping the shrinker LRU lock and acquiring the object lock it could for total: 0 errors, 1 warnings, 0 checks, 486 lines checked f53947eeb752 drm/i915/gtt: drop unneeded make_unshrinkable 14c9126d88dc drm/i915: drop unneeded make_unshrinkable in free_object 391284f29461 drm/i915: add some kernel-doc for shrink_pin and friends cade90c069e7 drm/i915/ttm: move shrinker management into adjust_lru -:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #19: an object. Importantly this covers the case where TTM moves something from total: 0 errors, 1 warnings, 0 checks, 299 lines checked 1e11734bd61a drm/i915/ttm: use cached system pages when evicting lmem b5e031de1986 drm/i915/ttm: enable shmem tt backend
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/locking: fix __stack_depot_* name conflict
== Series Details == Series: drm/locking: fix __stack_depot_* name conflict URL : https://patchwork.freedesktop.org/series/95940/ State : success == Summary == CI Bug Log - changes from CI_DRM_10752 -> Patchwork_21365 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/index.html Known issues Here are the changes found in Patchwork_21365 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([fdo#109315]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@nop-gfx0: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([fdo#109315] / [i915#2575]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@amdgpu/amd_cs_...@nop-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#1155]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][6] -> [INCOMPLETE][7] ([i915#3921]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([i915#4103]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([fdo#109285]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@primary_mmap_gtt: - fi-tgl-1115g4: NOTRUN -> [SKIP][11] ([i915#1072]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@kms_psr@primary_mmap_gtt.html * igt@prime_vgem@basic-userptr: - fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#3301]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-tgl-1115g4/igt@prime_v...@basic-userptr.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][13] ([i915#2940]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][15] ([i915#4269]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10752/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21365/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269 Participating hosts (38 -> 37) -- Additional (1): fi-tgl-1115g4 Missing(2): bat-dg1-6 bat-dg1-5 Build changes -
[Intel-gfx] [PATCH 9/9] drm/i915: Split vlv/chv sprite plane update into noarm+arm pair
From: Ville Syrjälä
Chop vlv_sprite_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
Looks like most of the hardware logic wa scopied from the
pre-ctg sprite C, so SPSTRIDE/POS/SIZE are armed by SPSURF,
while the rest are self arming. SPCONSTALPHA is the one
entirely new register that didn't exist in the old sprite C,
and looks like that one is self arming. The CHV pipe B CSC
is also self arming, like the rest of the CHV pipe B
additions.
I didn't have time to capture i915_update_info numbers for
these, but since all the other platforms generally showed
improvements, and crucially no regression, I am fairly
confident this should behave similarly.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c | 45 ++---
1 file changed, 30 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 4e5f95aebeca..fc6ecb41a40e 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -416,35 +416,24 @@ static void vlv_sprite_update_gamma(const struct
intel_plane_state *plane_state)
gamma[i] << 16 | gamma[i] << 8 | gamma[i]);
}
-/* TODO: split into noarm+arm pair */
static void
-vlv_sprite_update_arm(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
+vlv_sprite_update_noarm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum pipe pipe = plane->pipe;
enum plane_id plane_id = plane->id;
- u32 sprsurf_offset = plane_state->view.color_plane[0].offset;
- u32 linear_offset;
- const struct drm_intel_sprite_colorkey *key = _state->ckey;
int crtc_x = plane_state->uapi.dst.x1;
int crtc_y = plane_state->uapi.dst.y1;
u32 crtc_w = drm_rect_width(_state->uapi.dst);
u32 crtc_h = drm_rect_height(_state->uapi.dst);
- u32 x = plane_state->view.color_plane[0].x;
- u32 y = plane_state->view.color_plane[0].y;
unsigned long irqflags;
- u32 sprctl;
-
- sprctl = plane_state->ctl | vlv_sprite_ctl_crtc(crtc_state);
/* Sizes are 0 based */
crtc_w--;
crtc_h--;
- linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
-
spin_lock_irqsave(_priv->uncore.lock, irqflags);
intel_de_write_fw(dev_priv, SPSTRIDE(pipe, plane_id),
@@ -453,7 +442,30 @@ vlv_sprite_update_arm(struct intel_plane *plane,
(crtc_y << 16) | crtc_x);
intel_de_write_fw(dev_priv, SPSIZE(pipe, plane_id),
(crtc_h << 16) | crtc_w);
- intel_de_write_fw(dev_priv, SPCONSTALPHA(pipe, plane_id), 0);
+
+ spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+}
+
+static void
+vlv_sprite_update_arm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+ enum plane_id plane_id = plane->id;
+ const struct drm_intel_sprite_colorkey *key = _state->ckey;
+ u32 sprsurf_offset = plane_state->view.color_plane[0].offset;
+ u32 x = plane_state->view.color_plane[0].x;
+ u32 y = plane_state->view.color_plane[0].y;
+ u32 sprctl, linear_offset;
+ unsigned long irqflags;
+
+ sprctl = plane_state->ctl | vlv_sprite_ctl_crtc(crtc_state);
+
+ linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
+
+ spin_lock_irqsave(_priv->uncore.lock, irqflags);
if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B)
chv_sprite_update_csc(plane_state);
@@ -467,6 +479,8 @@ vlv_sprite_update_arm(struct intel_plane *plane,
key->max_value);
}
+ intel_de_write_fw(dev_priv, SPCONSTALPHA(pipe, plane_id), 0);
+
intel_de_write_fw(dev_priv, SPLINOFF(pipe, plane_id), linear_offset);
intel_de_write_fw(dev_priv, SPTILEOFF(pipe, plane_id), (y << 16) | x);
@@ -1791,6 +1805,7 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
return plane;
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+ plane->update_noarm = vlv_sprite_update_noarm;
plane->update_arm = vlv_sprite_update_arm;
plane->disable_arm = vlv_sprite_disable_arm;
[Intel-gfx] [PATCH 8/9] drm/i915: Split ivb+ sprite plane update into noarm+arm pair
From: Ville Syrjälä
Chop ivb_sprite_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
Didn't bother with i915_update_info numbers for this one.
I expect the results to be pretty much identical to the snb
numbers from the corresponding g4x+ sprite modification.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c | 42 ++---
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 03e3bf890ce9..4e5f95aebeca 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -835,30 +835,22 @@ static void ivb_sprite_update_gamma(const struct
intel_plane_state *plane_state)
i++;
}
-/* TODO: split into noarm+arm pair */
static void
-ivb_sprite_update_arm(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
+ivb_sprite_update_noarm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum pipe pipe = plane->pipe;
- u32 sprsurf_offset = plane_state->view.color_plane[0].offset;
- u32 linear_offset;
- const struct drm_intel_sprite_colorkey *key = _state->ckey;
int crtc_x = plane_state->uapi.dst.x1;
int crtc_y = plane_state->uapi.dst.y1;
u32 crtc_w = drm_rect_width(_state->uapi.dst);
u32 crtc_h = drm_rect_height(_state->uapi.dst);
- u32 x = plane_state->view.color_plane[0].x;
- u32 y = plane_state->view.color_plane[0].y;
u32 src_w = drm_rect_width(_state->uapi.src) >> 16;
u32 src_h = drm_rect_height(_state->uapi.src) >> 16;
- u32 sprctl, sprscale = 0;
+ u32 sprscale = 0;
unsigned long irqflags;
- sprctl = plane_state->ctl | ivb_sprite_ctl_crtc(crtc_state);
-
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -868,8 +860,6 @@ ivb_sprite_update_arm(struct intel_plane *plane,
if (crtc_w != src_w || crtc_h != src_h)
sprscale = SPRITE_SCALE_ENABLE | (src_w << 16) | src_h;
- linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
-
spin_lock_irqsave(_priv->uncore.lock, irqflags);
intel_de_write_fw(dev_priv, SPRSTRIDE(pipe),
@@ -879,6 +869,29 @@ ivb_sprite_update_arm(struct intel_plane *plane,
if (IS_IVYBRIDGE(dev_priv))
intel_de_write_fw(dev_priv, SPRSCALE(pipe), sprscale);
+ spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+}
+
+static void
+ivb_sprite_update_arm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ enum pipe pipe = plane->pipe;
+ const struct drm_intel_sprite_colorkey *key = _state->ckey;
+ u32 sprsurf_offset = plane_state->view.color_plane[0].offset;
+ u32 x = plane_state->view.color_plane[0].x;
+ u32 y = plane_state->view.color_plane[0].y;
+ u32 sprctl, linear_offset;
+ unsigned long irqflags;
+
+ sprctl = plane_state->ctl | ivb_sprite_ctl_crtc(crtc_state);
+
+ linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
+
+ spin_lock_irqsave(_priv->uncore.lock, irqflags);
+
if (key->flags) {
intel_de_write_fw(dev_priv, SPRKEYVAL(pipe), key->min_value);
intel_de_write_fw(dev_priv, SPRKEYMSK(pipe),
@@ -1796,6 +1809,7 @@ intel_sprite_plane_create(struct drm_i915_private
*dev_priv,
plane_funcs = _sprite_funcs;
} else if (DISPLAY_VER(dev_priv) >= 7) {
+ plane->update_noarm = ivb_sprite_update_noarm;
plane->update_arm = ivb_sprite_update_arm;
plane->disable_arm = ivb_sprite_disable_arm;
plane->get_hw_state = ivb_sprite_get_hw_state;
--
2.32.0
[Intel-gfx] [PATCH 7/9] drm/i915: Split g4x+ sprite plane update into noarm+arm pair
From: Ville Syrjälä
Chop g4x_sprite_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
Not much of a change in i915_update_info on these older
platforms that don't have so many planes or registers to
begin with. Here are the numbers from snb (totally unpatched
vs. both primary plane and sprite patched applied) running
kms_atomic_transition --r plane-all-transition --extended:
w/o patch w/ patch
Updates: 5404 Updates: 5405
| |
1us |** 1us |**
|* |*
4us |***4us |***
|** |**
16us |**16us |**
| |
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 1400ns Min update: 1307ns
Max update: 19809ns Max update: 20194ns
Average update: 6957ns Average update: 6432ns
Overruns > 100us: 0 Overruns > 100us: 0
But there seems to be a slight improvement with
lockdep enabled:
w/o patch w/ patch
Updates: 17612 Updates: 16364
| |
1us | 1us |
|** |**
4us |** 4us |**
| |*
16us |* 16us |
|***|*
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 3141ns Min update: 3562ns
Max update: 126450nsMax update: 73354ns
Average update: 16373ns Average update: 15153ns
Overruns > 250us: 0 Overruns > 250us: 0
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c | 41 ++---
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 9c36c1492b33..03e3bf890ce9 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -1165,28 +1165,21 @@ static void ilk_sprite_update_gamma(const struct
intel_plane_state *plane_state)
}
static void
-g4x_sprite_update_arm(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
+g4x_sprite_update_noarm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum pipe pipe = plane->pipe;
- u32 dvssurf_offset = plane_state->view.color_plane[0].offset;
- u32 linear_offset;
- const struct drm_intel_sprite_colorkey *key = _state->ckey;
int crtc_x = plane_state->uapi.dst.x1;
int crtc_y = plane_state->uapi.dst.y1;
u32 crtc_w = drm_rect_width(_state->uapi.dst);
u32 crtc_h = drm_rect_height(_state->uapi.dst);
- u32 x = plane_state->view.color_plane[0].x;
- u32 y = plane_state->view.color_plane[0].y;
u32 src_w = drm_rect_width(_state->uapi.src) >> 16;
u32 src_h = drm_rect_height(_state->uapi.src) >> 16;
- u32 dvscntr, dvsscale = 0;
+ u32 dvsscale = 0;
unsigned long irqflags;
- dvscntr = plane_state->ctl | g4x_sprite_ctl_crtc(crtc_state);
-
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -1196,8 +1189,6 @@ g4x_sprite_update_arm(struct intel_plane *plane,
if (crtc_w != src_w || crtc_h != src_h)
dvsscale = DVS_SCALE_ENABLE | (src_w << 16) | src_h;
- linear_offset = intel_fb_xy_to_linear(x, y,
[Intel-gfx] [PATCH 6/9] drm/i915: Split pre-skl primary plane update into noarm+arm pair
From: Ville Syrjälä
Chop i9xx_plane_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
One slightly surprising fact was that the CHV pipe B PRIMPOS/SIZE
registers are self arming unlike their pre-ctg DSPPOS/SIZE
counterparts. In fact all the new CHV pipe B registers are
self arming.
I didn't do any i915_update_info measurements for this one
alone. I'll get total numbers with the corrsponding sprite
plane changes.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 61 +++
1 file changed, 40 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 93163f9100a8..9dfd0a53e0ee 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -418,23 +418,49 @@ static int i9xx_plane_min_cdclk(const struct
intel_crtc_state *crtc_state,
return DIV_ROUND_UP(pixel_rate * num, den);
}
-/* TODO: split into noarm+arm pair */
+static void i9xx_plane_update_noarm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(_priv->uncore.lock, irqflags);
+
+ intel_de_write_fw(dev_priv, DSPSTRIDE(i9xx_plane),
+ plane_state->view.color_plane[0].stride);
+
+ if (DISPLAY_VER(dev_priv) < 4) {
+ int crtc_x = plane_state->uapi.dst.x1;
+ int crtc_y = plane_state->uapi.dst.y1;
+ int crtc_w = drm_rect_width(_state->uapi.dst);
+ int crtc_h = drm_rect_height(_state->uapi.dst);
+
+ /*
+* PLANE_A doesn't actually have a full window
+* generator but let's assume we still need to
+* program whatever is there.
+*/
+ intel_de_write_fw(dev_priv, DSPPOS(i9xx_plane),
+ (crtc_y << 16) | crtc_x);
+ intel_de_write_fw(dev_priv, DSPSIZE(i9xx_plane),
+ ((crtc_h - 1) << 16) | (crtc_w - 1));
+ }
+
+ spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+}
+
static void i9xx_plane_update_arm(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
- u32 linear_offset;
int x = plane_state->view.color_plane[0].x;
int y = plane_state->view.color_plane[0].y;
- int crtc_x = plane_state->uapi.dst.x1;
- int crtc_y = plane_state->uapi.dst.y1;
- int crtc_w = drm_rect_width(_state->uapi.dst);
- int crtc_h = drm_rect_height(_state->uapi.dst);
+ u32 dspcntr, dspaddr_offset, linear_offset;
unsigned long irqflags;
- u32 dspaddr_offset;
- u32 dspcntr;
dspcntr = plane_state->ctl | i9xx_plane_ctl_crtc(crtc_state);
@@ -447,20 +473,12 @@ static void i9xx_plane_update_arm(struct intel_plane
*plane,
spin_lock_irqsave(_priv->uncore.lock, irqflags);
- intel_de_write_fw(dev_priv, DSPSTRIDE(i9xx_plane),
- plane_state->view.color_plane[0].stride);
+ if (IS_CHERRYVIEW(dev_priv) && i9xx_plane == PLANE_B) {
+ int crtc_x = plane_state->uapi.dst.x1;
+ int crtc_y = plane_state->uapi.dst.y1;
+ int crtc_w = drm_rect_width(_state->uapi.dst);
+ int crtc_h = drm_rect_height(_state->uapi.dst);
- if (DISPLAY_VER(dev_priv) < 4) {
- /*
-* PLANE_A doesn't actually have a full window
-* generator but let's assume we still need to
-* program whatever is there.
-*/
- intel_de_write_fw(dev_priv, DSPPOS(i9xx_plane),
- (crtc_y << 16) | crtc_x);
- intel_de_write_fw(dev_priv, DSPSIZE(i9xx_plane),
- ((crtc_h - 1) << 16) | (crtc_w - 1));
- } else if (IS_CHERRYVIEW(dev_priv) && i9xx_plane == PLANE_B) {
intel_de_write_fw(dev_priv, PRIMPOS(i9xx_plane),
(crtc_y << 16) | crtc_x);
intel_de_write_fw(dev_priv, PRIMSIZE(i9xx_plane),
@@ -852,6 +870,7 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
[Intel-gfx] [PATCH 5/9] drm/i915: Split skl+ plane update into noarm+arm pair
From: Ville Syrjälä
Chop skl_program_plane() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
A few notable oddities I did not realize were self arming
are AUX_DIST and COLOR_CTL.
i915_update_info doesn't look too terrible on my cfl running
kms_atomic_transition --r plane-all-transition --extended:
w/o patch w/ patch
Updates: 2178 Updates: 2018
| |
1us | 1us |
| |
4us | 4us |*
|* |**
16us |**16us |***
|***|
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 8332ns Min update: 6164ns
Max update: 48758ns Max update: 31808ns
Average update: 19959ns Average update: 13159ns
Overruns > 100us: 0 Overruns > 100us: 0
And with lockdep enabled:
w/o patch w/ patch
Updates: 2177 Updates: 2172
| |
1us | 1us |
| |
4us | 4us |
|***|*
16us |**16us |**
|***|*
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 12645ns Min update: 9980ns
Max update: 50153ns Max update: 33533ns
Average update: 25337ns Average update: 18245ns
Overruns > 250us: 0 Overruns > 250us: 0
TODO: On icl+ everything seems to be armed by PLANE_SURF, so we
can optimize this even further on modern platforms. But I
think there's a bit of refactoring to be done first to
figure out the best way to go about it (eg. just reusing
the current skl+ functions, or doing a lower level split).
TODO: Split scaler programming as well, but IIRC the scaler
has some oddball double buffering behaviour on some
platforms, so needs proper reverse engineering
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/skl_universal_plane.c| 113 +++---
1 file changed, 72 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 74f3870d39b1..2a822e1e465e 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1050,60 +1050,32 @@ static void icl_plane_csc_load_black(struct intel_plane
*plane)
}
static void
-skl_program_plane(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state,
- int color_plane)
+skl_program_plane_noarm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state,
+ int color_plane)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum plane_id plane_id = plane->id;
enum pipe pipe = plane->pipe;
- const struct drm_intel_sprite_colorkey *key = _state->ckey;
u32 stride = skl_plane_stride(plane_state, color_plane);
const struct drm_framebuffer *fb = plane_state->hw.fb;
- int aux_plane = skl_main_to_aux_plane(fb, color_plane);
int crtc_x = plane_state->uapi.dst.x1;
int crtc_y = plane_state->uapi.dst.y1;
- u32 x = plane_state->view.color_plane[color_plane].x;
- u32 y = plane_state->view.color_plane[color_plane].y;
u32 src_w = drm_rect_width(_state->uapi.src) >> 16;
u32 src_h = drm_rect_height(_state->uapi.src) >> 16;
- u8 alpha =
[Intel-gfx] [PATCH 4/9] drm/i915: Split update_plane() into update_noarm() + update_arm()
From: Ville Syrjälä
The amount of plane registers we have to write has been steadily
increasing, putting more pressure on the vblank evasion mechanism
and forcing us to increase its time budget. Let's try to take some
of the pressure off by splitting plane updates into two parts:
1) write all non-self arming plane registers, ie. the registers
where the write actually does nothing until a separate arming
register is also written which will cause the hardware to latch
the new register values at the next start of vblank
2) write all self arming plane registers, ie. registers which always
just latch at the next start of vblank, and registers which also
arm other registers to do so
Here we just provide the mechanism, but don't actually implement
the split on any platform yet. so everything stays now in the _arm()
hooks. Subsequently we can move a whole bunch of stuff into the
_noarm() part, especially in more modern platforms where the number
of registers we have to write is also the greatest. On older
platforms this is less beneficial probably, but no real reason
to deviate from a common behaviour.
And let's sprinkle some TODOs around the areas that will need
adapting.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 15 ++--
.../gpu/drm/i915/display/intel_atomic_plane.c | 88 ++-
.../gpu/drm/i915/display/intel_atomic_plane.h | 23 +++--
drivers/gpu/drm/i915/display/intel_cursor.c | 44 +-
drivers/gpu/drm/i915/display/intel_display.c | 12 +--
.../drm/i915/display/intel_display_types.h| 12 ++-
drivers/gpu/drm/i915/display/intel_sprite.c | 44 +-
.../drm/i915/display/skl_universal_plane.c| 15 ++--
drivers/gpu/drm/i915/i915_trace.h | 33 ++-
9 files changed, 192 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index b1439ba78f67..93163f9100a8 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -418,9 +418,10 @@ static int i9xx_plane_min_cdclk(const struct
intel_crtc_state *crtc_state,
return DIV_ROUND_UP(pixel_rate * num, den);
}
-static void i9xx_update_plane(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
+/* TODO: split into noarm+arm pair */
+static void i9xx_plane_update_arm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
@@ -493,8 +494,8 @@ static void i9xx_update_plane(struct intel_plane *plane,
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
}
-static void i9xx_disable_plane(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state)
+static void i9xx_plane_disable_arm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum i9xx_plane_id i9xx_plane = plane->i9xx_plane;
@@ -851,8 +852,8 @@ intel_primary_plane_create(struct drm_i915_private
*dev_priv, enum pipe pipe)
plane->max_stride = ilk_primary_max_stride;
}
- plane->update_plane = i9xx_update_plane;
- plane->disable_plane = i9xx_disable_plane;
+ plane->update_arm = i9xx_plane_update_arm;
+ plane->disable_arm = i9xx_plane_disable_arm;
plane->get_hw_state = i9xx_plane_get_hw_state;
plane->check_plane = i9xx_plane_check;
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 0be8c00e3db9..ae21770fc321 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -469,31 +469,72 @@ skl_next_plane_to_commit(struct intel_atomic_state *state,
return NULL;
}
-void intel_update_plane(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
+void intel_plane_update_noarm(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- trace_intel_update_plane(>base, crtc);
+ trace_intel_plane_update_noarm(>base, crtc);
+
+ if (plane->update_noarm)
+ plane->update_noarm(plane, crtc_state, plane_state);
+}
+
+void intel_plane_update_arm(struct intel_plane *plane,
+
[Intel-gfx] [PATCH 3/9] drm/i915: Fix up the sprite namespacing
From: Ville Syrjälä
Give all sprite exclusive functions/etc. a proper namespace.
Cc: Stanislav Lisovskiy
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c | 106 ++--
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 08116f41da26..1daa3360cf02 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -118,7 +118,7 @@ static void i9xx_plane_linear_gamma(u16 gamma[8])
}
static void
-chv_update_csc(const struct intel_plane_state *plane_state)
+chv_sprite_update_csc(const struct intel_plane_state *plane_state)
{
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
@@ -190,7 +190,7 @@ chv_update_csc(const struct intel_plane_state *plane_state)
#define COS_0 1
static void
-vlv_update_clrc(const struct intel_plane_state *plane_state)
+vlv_sprite_update_clrc(const struct intel_plane_state *plane_state)
{
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
@@ -393,7 +393,7 @@ static u32 vlv_sprite_ctl(const struct intel_crtc_state
*crtc_state,
return sprctl;
}
-static void vlv_update_gamma(const struct intel_plane_state *plane_state)
+static void vlv_sprite_update_gamma(const struct intel_plane_state
*plane_state)
{
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
@@ -417,9 +417,9 @@ static void vlv_update_gamma(const struct intel_plane_state
*plane_state)
}
static void
-vlv_update_plane(struct intel_plane *plane,
-const struct intel_crtc_state *crtc_state,
-const struct intel_plane_state *plane_state)
+vlv_sprite_update(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum pipe pipe = plane->pipe;
@@ -455,7 +455,7 @@ vlv_update_plane(struct intel_plane *plane,
intel_de_write_fw(dev_priv, SPCONSTALPHA(pipe, plane_id), 0);
if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B)
- chv_update_csc(plane_state);
+ chv_sprite_update_csc(plane_state);
if (key->flags) {
intel_de_write_fw(dev_priv, SPKEYMINVAL(pipe, plane_id),
@@ -478,15 +478,15 @@ vlv_update_plane(struct intel_plane *plane,
intel_de_write_fw(dev_priv, SPSURF(pipe, plane_id),
intel_plane_ggtt_offset(plane_state) +
sprsurf_offset);
- vlv_update_clrc(plane_state);
- vlv_update_gamma(plane_state);
+ vlv_sprite_update_clrc(plane_state);
+ vlv_sprite_update_gamma(plane_state);
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
}
static void
-vlv_disable_plane(struct intel_plane *plane,
- const struct intel_crtc_state *crtc_state)
+vlv_sprite_disable(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum pipe pipe = plane->pipe;
@@ -502,8 +502,8 @@ vlv_disable_plane(struct intel_plane *plane,
}
static bool
-vlv_plane_get_hw_state(struct intel_plane *plane,
- enum pipe *pipe)
+vlv_sprite_get_hw_state(struct intel_plane *plane,
+ enum pipe *pipe)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum intel_display_power_domain power_domain;
@@ -805,7 +805,7 @@ static void ivb_sprite_linear_gamma(const struct
intel_plane_state *plane_state,
i++;
}
-static void ivb_update_gamma(const struct intel_plane_state *plane_state)
+static void ivb_sprite_update_gamma(const struct intel_plane_state
*plane_state)
{
struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
@@ -835,9 +835,9 @@ static void ivb_update_gamma(const struct intel_plane_state
*plane_state)
}
static void
-ivb_update_plane(struct intel_plane *plane,
-const struct intel_crtc_state *crtc_state,
-const struct intel_plane_state *plane_state)
+ivb_sprite_update(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum pipe pipe = plane->pipe;
@@ -902,14 +902,14 @@ ivb_update_plane(struct intel_plane *plane,
intel_de_write_fw(dev_priv, SPRSURF(pipe),
intel_plane_ggtt_offset(plane_state)
[Intel-gfx] [PATCH 2/9] drm/i915: Fix async flip with decryption and/or DPT
From: Ville Syrjälä
We're currently forgetting to set the PLANE_SURF_DECRYPT
flag in the async flip path. So if the hardware were to
latch that bit despite this being an async flip we'd start
scanning out garbage. And if it doesn't latch it then I
guess we'd just end up with a weird register value that
doesn't actually match the hardware state, which isn't
great for anyone starting at register dumps.
Similarly the async flip path also forgets to call
skl_surf_address() which means the DPT address space to
GGTT address space downshift is not being applied to
the offset. Which means we are pointing PLANE_SURF
at some random location in GGTT instead of the correct
DPT page.
So let's fix two birds with one stone and extract the
PLANE_SURF calculation from skl_program_plane() into
a small helper and use it in the async flip path as well.
Cc: Anshuman Gupta
Cc: Daniele Ceraolo Spurio
Cc: Juston Li
Cc: Rodrigo Vivi
Cc: Uma Shankar
Cc: Karthik B S
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/skl_universal_plane.c| 30 ---
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 7444b88829ea..e2f024449149 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1011,6 +1011,20 @@ static u32 skl_surf_address(const struct
intel_plane_state *plane_state,
}
}
+static u32 skl_plane_surf(const struct intel_plane_state *plane_state,
+ int color_plane)
+{
+ u32 plane_surf;
+
+ plane_surf = intel_plane_ggtt_offset(plane_state) +
+ skl_surf_address(plane_state, color_plane);
+
+ if (plane_state->decrypt)
+ plane_surf |= PLANE_SURF_DECRYPT;
+
+ return plane_surf;
+}
+
static void icl_plane_csc_load_black(struct intel_plane *plane)
{
struct drm_i915_private *i915 = to_i915(plane->base.dev);
@@ -1045,7 +1059,6 @@ skl_program_plane(struct intel_plane *plane,
enum plane_id plane_id = plane->id;
enum pipe pipe = plane->pipe;
const struct drm_intel_sprite_colorkey *key = _state->ckey;
- u32 surf_addr = skl_surf_address(plane_state, color_plane);
u32 stride = skl_plane_stride(plane_state, color_plane);
const struct drm_framebuffer *fb = plane_state->hw.fb;
int aux_plane = skl_main_to_aux_plane(fb, color_plane);
@@ -1058,7 +1071,7 @@ skl_program_plane(struct intel_plane *plane,
u8 alpha = plane_state->hw.alpha >> 8;
u32 plane_color_ctl = 0, aux_dist = 0;
unsigned long irqflags;
- u32 keymsk, keymax, plane_surf;
+ u32 keymsk, keymax;
u32 plane_ctl = plane_state->ctl;
plane_ctl |= skl_plane_ctl_crtc(crtc_state);
@@ -1084,16 +1097,13 @@ skl_program_plane(struct intel_plane *plane,
}
if (aux_plane) {
- aux_dist = skl_surf_address(plane_state, aux_plane) - surf_addr;
+ aux_dist = skl_surf_address(plane_state, aux_plane) -
+ skl_surf_address(plane_state, color_plane);
if (DISPLAY_VER(dev_priv) < 12)
aux_dist |= skl_plane_stride(plane_state, aux_plane);
}
- plane_surf = intel_plane_ggtt_offset(plane_state) + surf_addr;
- if (plane_state->decrypt)
- plane_surf |= PLANE_SURF_DECRYPT;
-
spin_lock_irqsave(_priv->uncore.lock, irqflags);
/*
@@ -1157,7 +1167,8 @@ skl_program_plane(struct intel_plane *plane,
* the control register just before the surface register.
*/
intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
- intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), plane_surf);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
+ skl_plane_surf(plane_state, color_plane));
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
}
@@ -1172,7 +1183,6 @@ skl_plane_async_flip(struct intel_plane *plane,
unsigned long irqflags;
enum plane_id plane_id = plane->id;
enum pipe pipe = plane->pipe;
- u32 surf_addr = plane_state->view.color_plane[0].offset;
u32 plane_ctl = plane_state->ctl;
plane_ctl |= skl_plane_ctl_crtc(crtc_state);
@@ -1184,7 +1194,7 @@ skl_plane_async_flip(struct intel_plane *plane,
intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
- intel_plane_ggtt_offset(plane_state) + surf_addr);
+ skl_plane_surf(plane_state, 0));
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
}
--
2.32.0
[Intel-gfx] [PATCH 1/9] drm/i915: Reject planar formats when doing async flips
From: Ville Syrjälä
Async flips are only capable of changing PLANE_SURF, hence we
they can't easily be used with planar formats.
Older platforms could require updating AUX_DIST as well, which
is not possible. We'd have to make sure AUX_DIST doesn't change
before allowing the async flip through. If we could get async
flips with CCS then that might be interesting, but since the hw
doesn't allow async flips with CCS I don't see much point in
allowing this for planar formats either. No one renders their
game content in YUV anyway.
icl+ could in theory do this I suppose since each color plane
has its own PLANE_SURF register, but I don't know if there is
some magic to guarantee that both the Y and UV plane would
async flip synchronously if you will. Ie. beyond just a clean
tear we'd potentially get some kind of weird tear with some
random mix of luma and chroma from the old and new frames.
So let's just say no to async flips when scanning out planar
formats.
Cc: Karthik B S
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ce5d6633029a..8bb87e839f4a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8884,6 +8884,12 @@ static int intel_atomic_check_async(struct
intel_atomic_state *state)
return -EINVAL;
}
+ if (new_plane_state->hw.fb->format->num_planes > 1) {
+ drm_dbg_kms(>drm,
+ "Planar formats not supported with async
flips\n");
+ return -EINVAL;
+ }
+
if (old_plane_state->view.color_plane[0].stride !=
new_plane_state->view.color_plane[0].stride) {
drm_dbg_kms(>drm, "Stride cannot be changed in
async flip\n");
--
2.32.0
[Intel-gfx] [PATCH 0/9] drm/i915: Split plane updates to noarm+arm phases
From: Ville Syrjälä Write all non-arming double buffered plane registers ahead of the vblank evade critical section. This reduces the amount of work we have to inside the critical section and thus should speed it up a bit. I didn't convert cursors yet because IIRC they had some intersting double buffering behaviours. Similar story with skl+ scalers. Need to do further studies on those topics to do this safely. For now we're left with a few TODOs. Also tossed in a few async flip fixes at the start. Ville Syrjälä (9): drm/i915: Reject planar formats when doing async flips drm/i915: Fix async flip with decryption and/or DPT drm/i915: Fix up the sprite namespacing drm/i915: Split update_plane() into update_noarm() + update_arm() drm/i915: Split skl+ plane update into noarm+arm pair drm/i915: Split pre-skl primary plane update into noarm+arm pair drm/i915: Split g4x+ sprite plane update into noarm+arm pair drm/i915: Split ivb+ sprite plane update into noarm+arm pair drm/i915: Split vlv/chv sprite plane update into noarm+arm pair drivers/gpu/drm/i915/display/i9xx_plane.c | 72 +++--- .../gpu/drm/i915/display/intel_atomic_plane.c | 88 +-- .../gpu/drm/i915/display/intel_atomic_plane.h | 23 +- drivers/gpu/drm/i915/display/intel_cursor.c | 44 ++-- drivers/gpu/drm/i915/display/intel_display.c | 18 +- .../drm/i915/display/intel_display_types.h| 12 +- drivers/gpu/drm/i915/display/intel_sprite.c | 214 +++--- .../drm/i915/display/skl_universal_plane.c| 150 +++- drivers/gpu/drm/i915/i915_trace.h | 33 ++- 9 files changed, 431 insertions(+), 223 deletions(-) -- 2.32.0
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/locking: fix __stack_depot_* name conflict
== Series Details == Series: drm/locking: fix __stack_depot_* name conflict URL : https://patchwork.freedesktop.org/series/95940/ State : warning == Summary == $ dim checkpatch origin/drm-tip bc53b22a35fb drm/locking: fix __stack_depot_* name conflict -:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #13: References: https://lore.kernel.org/r/20211015202648.25844...@canb.auug.org.au -:51: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations #51: FILE: drivers/gpu/drm/drm_modeset_lock.c:115: } +static void __drm_stack_depot_print(depot_stack_handle_t stack_depot) total: 0 errors, 1 warnings, 1 checks, 53 lines checked
Re: [Intel-gfx] [PATCH] drm/i915: Use dma_resv_iter for waiting in i915_gem_object_wait_reservation.
Op 14-10-2021 om 15:56 schreef Tvrtko Ursulin:
>
> On 14/10/2021 14:45, Maarten Lankhorst wrote:
>> Op 14-10-2021 om 15:25 schreef Tvrtko Ursulin:
>>>
>>> On 14/10/2021 13:05, Maarten Lankhorst wrote:
Op 14-10-2021 om 10:37 schreef Tvrtko Ursulin:
>
> On 13/10/2021 11:41, Maarten Lankhorst wrote:
>> No memory should be allocated when calling i915_gem_object_wait,
>> because it may be called to idle a BO when evicting memory.
>>
>> Fix this by using dma_resv_iter helpers to call
>> i915_gem_object_wait_fence() on each fence, which cleans up the code a
>> lot.
>> Also remove dma_resv_prune, it's questionably.
>>
>> This will result in the following lockdep splat.
>
>
>
>> @@ -37,56 +36,17 @@ i915_gem_object_wait_reservation(struct dma_resv
>> *resv,
>> unsigned int flags,
>> long timeout)
>> {
>> - struct dma_fence *excl;
>> - bool prune_fences = false;
>> -
>> - if (flags & I915_WAIT_ALL) {
>> - struct dma_fence **shared;
>> - unsigned int count, i;
>> - int ret;
>> + struct dma_resv_iter cursor;
>> + struct dma_fence *fence;
>> - ret = dma_resv_get_fences(resv, , , );
>> - if (ret)
>> - return ret;
>> -
>> - for (i = 0; i < count; i++) {
>> - timeout = i915_gem_object_wait_fence(shared[i],
>> - flags, timeout);
>> - if (timeout < 0)
>> - break;
>> + dma_resv_iter_begin(, resv, flags & I915_WAIT_ALL);
>> + dma_resv_for_each_fence_unlocked(, fence) {
>> - dma_fence_put(shared[i]);
>> - }
>> -
>> - for (; i < count; i++)
>> - dma_fence_put(shared[i]);
>> - kfree(shared);
>> -
>> - /*
>> - * If both shared fences and an exclusive fence exist,
>> - * then by construction the shared fences must be later
>> - * than the exclusive fence. If we successfully wait for
>> - * all the shared fences, we know that the exclusive fence
>> - * must all be signaled. If all the shared fences are
>> - * signaled, we can prune the array and recover the
>> - * floating references on the fences/requests.
>> - */
>> - prune_fences = count && timeout >= 0;
>> - } else {
>> - excl = dma_resv_get_excl_unlocked(resv);
>> + timeout = i915_gem_object_wait_fence(fence, flags, timeout);
>> + if (timeout <= 0)
>> + break;
>
> You have another change in behaviour here, well a bug really. When
> userspace passes in zero timeout you fail to report activity in other
> than the first fence.
Hmm, not necessarily, passing 0 to i915_gem_object_wait_fence timeout = 0
is a special case and means test only. It will return 1 on success.
>>>
>>> I tried to enumerate the whole chain here. All for timeout == 0. Please
>>> double check I did not make a mistake somewhere since there are many return
>>> code inversions here.
>>>
>>> As building blocks for the whole "game" we have:
>>>
>>> 1. dma_fence_default_wait, it returns for states:
>>> not signaled -> 0
>>> signaled -> 1
>>>
>>> 2. i915_request_wait
>>>
>>> not signaled -> -ETIME
>>> signaled -> 0
>>>
>>> Then i915_gem_object_wait_fence builds on top of it and has therefore these
>>> possible outputs:
>>>
>>> signaled -> 0
>>> not signaled:
>>> i915 path -> -ETIME
>>> ext fence -> 0
>>>
>>> So this looks a like problem already with 0 for signaled and not signaled.
>>> Unless it is by design that the return value does not want to report
>>> external fences? But it is not documented and it still waits on them so odd.
>>>
>>> Then in i915_gem_object_wait_reservation we have a loop:
>>>
>>> for (i = 0; i < count; i++) {
>>> timeout = i915_gem_object_wait_fence(shared[i],
>>> flags, timeout);
>>> if (timeout < 0)
>>> break;
>>>
>>> So short circuit happens only for i915 fences, by virtue of no negative
>>> return codes otherwise.
>>>
>>> If we focus for i915 fences only for a moment. It means it keeps skipping
>>> signaled to check if any is not, therefore returning -ETIME if any is not
>>> signaled. i915_gem_object_wait passes the negative return on.
>>>
>>> With your patch you have:
>>>
>>> + timeout = i915_gem_object_wait_fence(fence, flags, timeout);
>>> + if (timeout <= 0)
>>> + break;
>>>
>>> Which means you break on first signaled fence (i915 or external), therefore
>>> missing to report any possible subsequent unsignaled fences. So gem_wait
>>> ioctl breaks unless I am missing something.
>>
>>
Re: [Intel-gfx] [PATCH] drm/i915: Prefer struct_size over open coded arithmetic
On Sat, 16 Oct 2021, Len Baker wrote: > Hi Daniel and Jani, > > On Wed, Oct 13, 2021 at 01:51:30PM +0200, Daniel Vetter wrote: >> On Wed, Oct 13, 2021 at 02:24:05PM +0300, Jani Nikula wrote: >> > On Mon, 11 Oct 2021, Len Baker wrote: >> > > Hi, >> > > >> > > On Sun, Oct 03, 2021 at 12:42:58PM +0200, Len Baker wrote: >> > >> As noted in the "Deprecated Interfaces, Language Features, Attributes, >> > >> and Conventions" documentation [1], size calculations (especially >> > >> multiplication) should not be performed in memory allocator (or similar) >> > >> function arguments due to the risk of them overflowing. This could lead >> > >> to values wrapping around and a smaller allocation being made than the >> > >> caller was expecting. Using those allocations could lead to linear >> > >> overflows of heap memory and other misbehaviors. >> > >> >> > >> In this case these are not actually dynamic sizes: all the operands >> > >> involved in the calculation are constant values. However it is better to >> > >> refactor them anyway, just to keep the open-coded math idiom out of >> > >> code. >> > >> >> > >> So, add at the end of the struct i915_syncmap a union with two flexible >> > >> array members (these arrays share the same memory layout). This is >> > >> possible using the new DECLARE_FLEX_ARRAY macro. And then, use the >> > >> struct_size() helper to do the arithmetic instead of the argument >> > >> "size + count * size" in the kmalloc and kzalloc() functions. >> > >> >> > >> Also, take the opportunity to refactor the __sync_seqno and __sync_child >> > >> making them more readable. >> > >> >> > >> This code was detected with the help of Coccinelle and audited and fixed >> > >> manually. >> > >> >> > >> [1] >> > >> https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments >> > >> >> > >> Signed-off-by: Len Baker >> > >> --- >> > >> drivers/gpu/drm/i915/i915_syncmap.c | 12 >> > >> 1 file changed, 8 insertions(+), 4 deletions(-) >> > > >> > > I received a mail telling that this patch doesn't build: >> > > >> > > == Series Details == >> > > >> > > Series: drm/i915: Prefer struct_size over open coded arithmetic >> > > URL : https://patchwork.freedesktop.org/series/95408/ >> > > State : failure >> > > >> > > But it builds without error against linux-next (tag next-20211001). >> > > Against >> > > which tree and branch do I need to build? >> > >> > drm-tip [1]. It's a sort of linux-next for graphics. I think there are >> > still some branches that don't feed to linux-next. >> >> Yeah we need to get gt-next in linux-next asap. Joonas promised to send >> out his patch to make that happen in dim. >> -Daniel > > Is there a possibility that you give an "Acked-by" tag? And then this patch > goes to the mainline through the Kees' tree or Gustavo's tree? If this does not apply to drm-intel-gt-next (or drm-tip), applying it to some other branch will just cause unnecessary conflicts later on. It's unnecessary extra work. It's not an urgent fix or anything, there is no reason to do that. So that's a NAK. > Or is it better to wait for drm-tip to update? drm-tip is up to date, it's just that one of the branches that feed to it is (was?) not feeding to linux-next. If you're contributing to drm, please consider basing your patches on top of drm-tip. BR, Jani. > > Regards, > Len > >> >> > >> > BR, >> > Jani. >> > >> > >> > [1] https://cgit.freedesktop.org/drm/drm-tip >> > >> > >> > > >> > > Regards, >> > > Len >> > >> > -- >> > Jani Nikula, Intel Open Source Graphics Center >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 6/6] drm/i915/dp: Sanitize link common rate array lookups
Add an assert that lookups from the intel_dp->common_rates[] array
are always valid.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f8082eb8e7263..3869d454c10f0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -267,10 +267,19 @@ static int intel_dp_common_len_rate_limit(const struct
intel_dp *intel_dp,
intel_dp->num_common_rates, max_rate);
}
+static int intel_dp_common_rate(struct intel_dp *intel_dp, int index)
+{
+ if (drm_WARN_ON(_to_i915(intel_dp)->drm,
+ index < 0 || index >= intel_dp->num_common_rates))
+ return 162000;
+
+ return intel_dp->common_rates[index];
+}
+
/* Theoretical max between source and sink */
static int intel_dp_max_common_rate(struct intel_dp *intel_dp)
{
- return intel_dp->common_rates[intel_dp->num_common_rates - 1];
+ return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates - 1);
}
/* Theoretical max between source and sink */
@@ -610,13 +619,13 @@ int intel_dp_get_link_train_fallback_values(struct
intel_dp *intel_dp,
if (index > 0) {
if (intel_dp_is_edp(intel_dp) &&
!intel_dp_can_link_train_fallback_for_edp(intel_dp,
-
intel_dp->common_rates[index - 1],
+
intel_dp_common_rate(intel_dp, index - 1),
lane_count)) {
drm_dbg_kms(>drm,
"Retrying Link training for eDP with same
parameters\n");
return 0;
}
- intel_dp->max_link_rate = intel_dp->common_rates[index - 1];
+ intel_dp->max_link_rate = intel_dp_common_rate(intel_dp, index
- 1);
intel_dp->max_link_lane_count = lane_count;
} else if (lane_count > 1) {
if (intel_dp_is_edp(intel_dp) &&
@@ -1056,14 +1065,11 @@ static void intel_dp_print_rates(struct intel_dp
*intel_dp)
int
intel_dp_max_link_rate(struct intel_dp *intel_dp)
{
- struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int len;
len = intel_dp_common_len_rate_limit(intel_dp, intel_dp->max_link_rate);
- if (drm_WARN_ON(>drm, len <= 0))
- return 162000;
- return intel_dp->common_rates[len - 1];
+ return intel_dp_common_rate(intel_dp, len - 1);
}
int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
@@ -1260,7 +1266,7 @@ intel_dp_compute_link_config_wide(struct intel_dp
*intel_dp,
output_bpp);
for (i = 0; i < intel_dp->num_common_rates; i++) {
- link_rate = intel_dp->common_rates[i];
+ link_rate = intel_dp_common_rate(intel_dp, i);
if (link_rate < limits->min_rate ||
link_rate > limits->max_rate)
continue;
@@ -1508,17 +1514,10 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
_config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct link_config_limits limits;
- int common_len;
int ret;
- common_len = intel_dp_common_len_rate_limit(intel_dp,
- intel_dp->max_link_rate);
-
- /* No common link rates between source and sink */
- drm_WARN_ON(encoder->base.dev, common_len <= 0);
-
- limits.min_rate = intel_dp->common_rates[0];
- limits.max_rate = intel_dp->common_rates[common_len - 1];
+ limits.min_rate = intel_dp_common_rate(intel_dp, 0);
+ limits.max_rate = intel_dp_max_link_rate(intel_dp);
limits.min_lane_count = 1;
limits.max_lane_count = intel_dp_max_lane_count(intel_dp);
--
2.27.0
[Intel-gfx] [PATCH 5/6] drm/i915/dp: Sanitize sink rate DPCD register values
If the DPCD sink rate values read from the sink are invalid, the
driver will sanitize this in intel_dp_set_common_rates(), by setting a
default 162000 link rate in common rates and printing a WARN().
WARN()s should only be triggered by bugs in the code and not by external
factors like the above (an invalid DPCD injected maliciously or read from a
buggy monitor). So fixup the invalid DPCD sink rate values already and print
an error in this case (since it's still a user visible problem).
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f7711779df132..f8082eb8e7263 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -127,7 +127,7 @@ static void intel_dp_set_default_sink_rates(struct intel_dp
*intel_dp)
}
/* update sink rates from dpcd */
-static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
+static void intel_dp_set_dpcd_sink_rates(struct intel_dp *intel_dp)
{
static const int dp_rates[] = {
162000, 27, 54, 81
@@ -197,6 +197,25 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
intel_dp->num_sink_rates = i;
}
+static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
+{
+ struct intel_connector *connector = intel_dp->attached_connector;
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = _dig_port->base;
+
+ intel_dp_set_dpcd_sink_rates(intel_dp);
+
+ if (intel_dp->num_sink_rates)
+ return;
+
+ drm_err(_to_i915(intel_dp)->drm,
+ "[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD with no link
rates, using defaults\n",
+ connector->base.base.id, connector->base.name,
+ encoder->base.base.id, encoder->base.name);
+
+ intel_dp_set_default_sink_rates(intel_dp);
+}
+
static void intel_dp_set_default_max_sink_lane_count(struct intel_dp *intel_dp)
{
intel_dp->max_sink_lane_count = 1;
--
2.27.0
[Intel-gfx] [PATCH 4/6] drm/i915/dp: Ensure sink/link max lane count values are always valid
Print an error if the DPCD sink max lane count is invalid and fix it up.
While at it also add an assert that the link max lane count (derived
from intel_dp_max_common_lane_count(), potentially reduced by the LT
fallback logic) value is also valid.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/display/intel_dp.c | 44 ++-
2 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 39e11eaec1a3f..1e42bf901263c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1563,6 +1563,8 @@ struct intel_dp {
int num_sink_rates;
int sink_rates[DP_MAX_SUPPORTED_RATES];
bool use_rate_select;
+ /* Max sink lane count as reported by DP_MAX_LANE_COUNT */
+ int max_sink_lane_count;
/* intersection of source and sink rates */
int num_common_rates;
int common_rates[DP_MAX_SUPPORTED_RATES];
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1935eb49f9574..f7711779df132 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -197,6 +197,35 @@ static void intel_dp_set_sink_rates(struct intel_dp
*intel_dp)
intel_dp->num_sink_rates = i;
}
+static void intel_dp_set_default_max_sink_lane_count(struct intel_dp *intel_dp)
+{
+ intel_dp->max_sink_lane_count = 1;
+}
+
+static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
+{
+ struct intel_connector *connector = intel_dp->attached_connector;
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = _dig_port->base;
+
+ intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+
+ switch (intel_dp->max_sink_lane_count) {
+ case 1:
+ case 2:
+ case 4:
+ return;
+ }
+
+ drm_err(_to_i915(intel_dp)->drm,
+ "[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD max lane count
(%d), using default\n",
+ connector->base.base.id, connector->base.name,
+ encoder->base.base.id, encoder->base.name,
+ intel_dp->max_sink_lane_count);
+
+ intel_dp_set_default_max_sink_lane_count(intel_dp);
+}
+
/* Get length of rates array potentially limited by max_rate. */
static int intel_dp_rate_limit_len(const int *rates, int len, int max_rate)
{
@@ -230,7 +259,7 @@ static int intel_dp_max_common_lane_count(struct intel_dp
*intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
int source_max = dig_port->max_lanes;
- int sink_max = drm_dp_max_lane_count(intel_dp->dpcd);
+ int sink_max = intel_dp->max_sink_lane_count;
int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
int lttpr_max =
drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
@@ -242,7 +271,15 @@ static int intel_dp_max_common_lane_count(struct intel_dp
*intel_dp)
int intel_dp_max_lane_count(struct intel_dp *intel_dp)
{
- return intel_dp->max_link_lane_count;
+ switch (intel_dp->max_link_lane_count) {
+ case 1:
+ case 2:
+ case 4:
+ return intel_dp->max_link_lane_count;
+ default:
+ MISSING_CASE(intel_dp->max_link_lane_count);
+ return 1;
+ }
}
/*
@@ -2600,6 +2637,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
intel_dp->use_rate_select = true;
else
intel_dp_set_sink_rates(intel_dp);
+ intel_dp_set_max_sink_lane_count(intel_dp);
intel_dp_set_common_rates(intel_dp);
intel_dp_reset_max_link_params(intel_dp);
@@ -2645,6 +2683,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
drm_dp_is_branch(intel_dp->dpcd));
intel_dp_set_sink_rates(intel_dp);
+ intel_dp_set_max_sink_lane_count(intel_dp);
intel_dp_set_common_rates(intel_dp);
}
@@ -5011,6 +5050,7 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp_set_default_sink_rates(intel_dp);
+ intel_dp_set_default_max_sink_lane_count(intel_dp);
intel_dp_set_common_rates(intel_dp);
intel_dp_reset_max_link_params(intel_dp);
--
2.27.0
[Intel-gfx] [PATCH 2/6] drm/i915/dp: Ensure sink rate values are always valid
Atm, there are no sink rate values set for DP (vs. eDP) sinks until the
DPCD capabilities are successfully read from the sink. During this time
intel_dp->num_common_rates is 0 which can lead to a
intel_dp->common_rates[-1](*)
access, which is an undefined behaviour, in the following cases:
- In intel_dp_sync_state(), if the encoder is enabled without a sink
connected to the encoder's connector (BIOS enabled a monitor, but the
user unplugged the monitor until the driver loaded).
- In intel_dp_sync_state() if the encoder is enabled with a sink
connected, but for some reason the DPCD read has failed.
- In intel_dp_compute_link_config() if modesetting a connector without
a sink connected on it.
- In intel_dp_compute_link_config() if modesetting a connector with a
a sink connected on it, but before probing the connector first.
To avoid the (*) access in all the above cases, make sure that the sink
rate table - and hence the common rate table - is always valid, by
setting a default minimum sink rate when registering the connector
before anything could use it.
I also considered setting all the DP link rates by default, so that
modesetting with higher resolution modes also succeeds in the last two
cases above. However in case a sink is not connected that would stop
working after the first modeset, due to the LT fallback logic. So this
would need more work, beyond the scope of this fix.
As I mentioned in the previous patch, I don't think the issue this patch
fixes is user visible, however it is an undefined behaviour by
definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc:
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 23de500d56b52..153ae944a354b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -120,6 +120,12 @@ bool intel_dp_is_uhbr(const struct intel_crtc_state
*crtc_state)
return crtc_state->port_clock >= 100;
}
+static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp)
+{
+ intel_dp->sink_rates[0] = 162000;
+ intel_dp->num_sink_rates = 1;
+}
+
/* update sink rates from dpcd */
static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
{
@@ -5003,6 +5009,8 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
}
intel_dp_set_source_rates(intel_dp);
+ intel_dp_set_default_sink_rates(intel_dp);
+ intel_dp_set_common_rates(intel_dp);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
--
2.27.0
[Intel-gfx] [PATCH 1/6] drm/i915/dp: Skip the HW readout of DPCD on disabled encoders
Reading out the DP encoders' DPCD during booting or resume is only
required for enabled encoders: such encoders may be modesetted during
the initial commit and the link training this involves depends on an
initialized DPCD. For DDI encoders reading out the DPCD is skipped, do
the same on pre-DDI platforms.
Atm, the first DPCD readout without a sink connected - which is a likely
scneario if the encoder is disabled - leaves intel_dp->num_common_rates
at 0, which resulted in
intel_dp_sync_state()->intel_dp_max_common_rate()
in a
intel_dp->common_rates[-1]
access. This by definition results in an undefined behaviour, though to
my best knowledge in all HW/compiler configurations it actually results
in accessing the array item type value preceding the array. In this
case the preceding value happens to be intel_dp->num_common_rates,
which is 0, so this issue - by luck - didn't cause a user visible
problem.
Nevertheless it's still an undefined behaviour and in CONFIG_UBSAN
builds leads to a kernel BUG() (which revealed this problem for us),
hence CC:stable.
A related problem in case the encoder is enabled but the sink is not
connected or the DPCD readout fails is fixed by the next patch.
v2: Amend the commit message describing the root cause of the
CONFIG_UBSAN BUG().
Fixes: a532cde31de3 ("drm/i915/tc: Fix TypeC port init/resume time
sanitization")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4297
Reported-and-tested-by: Mat Jonczyk
Cc: Mat Jonczyk
Cc: José Roberto de Souza
Cc: Jani Nikula
Cc: Ville Syrjälä
Cc:
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 9d8132dd4cc5a..23de500d56b52 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2007,6 +2007,9 @@ void intel_dp_sync_state(struct intel_encoder *encoder,
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ if (!crtc_state)
+ return;
+
/*
* Don't clobber DPCD if it's been already read out during output
* setup (eDP) or detect.
--
2.27.0
[Intel-gfx] [PATCH 3/6] drm/i915/dp: Ensure max link params are always valid
Atm until the DPCD for a connector is read the max link rate and lane
count params are invalid. If the connector is modeset, in
intel_dp_compute_config(), intel_dp_common_len_rate_limit(max_link_rate)
will return 0, leading to a intel_dp->common_rates[-1] access.
Fix the above by making sure the max link params are always valid.
The above access leads to an undefined behaviour by definition, though
not causing a user visible problem to my best knowledge, see the previous
patch why. Nevertheless it is an undefined behaviour and it triggers a
BUG() in CONFIG_UBSAN builds, hence CC:stable.
Cc: Ville Syrjälä
Cc:
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 153ae944a354b..1935eb49f9574 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1864,6 +1864,12 @@ void intel_dp_set_link_params(struct intel_dp *intel_dp,
intel_dp->lane_count = lane_count;
}
+static void intel_dp_reset_max_link_params(struct intel_dp *intel_dp)
+{
+ intel_dp->max_link_lane_count =
intel_dp_max_common_lane_count(intel_dp);
+ intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
+}
+
/* Enable backlight PWM and backlight PP control. */
void intel_edp_backlight_on(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
@@ -2023,8 +2029,7 @@ void intel_dp_sync_state(struct intel_encoder *encoder,
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
intel_dp_get_dpcd(intel_dp);
- intel_dp->max_link_lane_count =
intel_dp_max_common_lane_count(intel_dp);
- intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
+ intel_dp_reset_max_link_params(intel_dp);
}
bool intel_dp_initial_fastset_check(struct intel_encoder *encoder,
@@ -2597,6 +2602,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
intel_dp_set_sink_rates(intel_dp);
intel_dp_set_common_rates(intel_dp);
+ intel_dp_reset_max_link_params(intel_dp);
/* Read the eDP DSC DPCD registers */
if (DISPLAY_VER(dev_priv) >= 10)
@@ -4338,12 +4344,7 @@ intel_dp_detect(struct drm_connector *connector,
* supports link training fallback params.
*/
if (intel_dp->reset_link_params || intel_dp->is_mst) {
- /* Initial max link lane count */
- intel_dp->max_link_lane_count =
intel_dp_max_common_lane_count(intel_dp);
-
- /* Initial max link rate */
- intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
-
+ intel_dp_reset_max_link_params(intel_dp);
intel_dp->reset_link_params = false;
}
@@ -5011,6 +5012,7 @@ intel_dp_init_connector(struct intel_digital_port
*dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp_set_default_sink_rates(intel_dp);
intel_dp_set_common_rates(intel_dp);
+ intel_dp_reset_max_link_params(intel_dp);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
--
2.27.0
[Intel-gfx] [PATCH 0/6] drm/i915/dp: Fix link parameter use in lack of a valid DPCD
This patchset fixes a few issues, related to invalid accesses from the intel_dp->common_rates[] array and in general the link rate, lane count parameters being invalid until a valid DPCD is read from the sink. One issue in intel_dp_sync_state() was caught by the CONFIG_UBSAN feature. The first 3 patches are also needed for stable kernels. Cc: José Roberto de Souza Cc: Jani Nikula Cc: Ville Syrjälä Imre Deak (6): drm/i915/dp: Skip the HW readout of DPCD on disabled encoders drm/i915/dp: Ensure sink rate values are always valid drm/i915/dp: Ensure max link params are always valid drm/i915/dp: Ensure sink/link max lane count values are always valid drm/i915/dp: Sanitize sink rate DPCD register values drm/i915/dp: Sanitize link common rate array lookups .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp.c | 127 ++ 2 files changed, 101 insertions(+), 28 deletions(-) -- 2.27.0
[Intel-gfx] [PATCH v9 7/8] drm/i915/ttm: use cached system pages when evicting lmem
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 8de1031a2c6e..d37581d9194c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -134,11 +134,11 @@ static enum ttm_caching
i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
{
/*
-* Objects only allowed in system get cached cpu-mappings.
-* Other objects get WC mapping for now. Even if in system.
+* Objects only allowed in system get cached cpu-mappings, or when
+* evicting lmem-only buffers to system for swapping. Other objects get
+* WC mapping for now. Even if in system.
*/
- if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
- obj->mm.n_placements <= 1)
+ if (obj->mm.n_placements <= 1)
return ttm_cached;
return ttm_write_combined;
--
2.26.3
Re: [Intel-gfx] [PATCH linux-next] drm/i915/display: Remove unused variable in the for loop.
On Mon, 18 Oct 2021, luo penghao wrote:
> Variable is not used in the loop, and its assignment is redundant too.
> So it should be deleted.
>
> The clang_analyzer complains as follows:
>
> drivers/gpu/drm/i915/display/intel_fb.c:1018:3 warning:
>
> Value stored to 'cpp' is never read.
>
> Reported-by: Zeal Robot
> Signed-off-by: luo penghao
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index fa1f375..b9b6a7a 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -998,7 +998,7 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
> struct intel_framebuffer *
> for (i = 0; i < num_planes; i++) {
> struct fb_plane_view_dims view_dims;
> unsigned int width, height;
> - unsigned int cpp, size;
> + unsigned int size;
> u32 offset;
> int x, y;
> int ret;
> @@ -1015,7 +1015,7 @@ int intel_fill_fb_info(struct drm_i915_private *i915,
> struct intel_framebuffer *
> return -EINVAL;
> }
>
> - cpp = fb->base.format->cpp[i];
> + fb->base.format->cpp[i];
Thanks for the report. However, this "fix" isn't any better than having
the unused variable. It's obviously wrong.
It would be useful to dig into the history of the function, and figure
out when and why the variable became unused, and whether that caused an
actual bug or whether this was just leftovers from some refactoring.
So that's what I did. Some git blame and git log -p revealed commit
d3c5e10b6059 ("drm/i915/intel_fb: Factor out
convert_plane_offset_to_xy()") that moved the check that used the cpp
variable to a separate function, and the local variable and the line
above became unused and useless.
That's the actually helpful part. It's easy to see and verify that the
right fix is to just remove the line completely.
BR,
Jani.
> intel_fb_plane_dims(fb, i, , );
>
> ret = convert_plane_offset_to_xy(fb, i, width, , );
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH v9 8/8] drm/i915/ttm: enable shmem tt backend
Turn on the shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index d37581d9194c..4fd2edb20dd9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1113,7 +1113,8 @@ static u64 i915_ttm_mmap_offset(struct
drm_i915_gem_object *obj)
static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
.name = "i915_gem_object_ttm",
- .flags = I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
+ .flags = I915_GEM_OBJECT_IS_SHRINKABLE |
+I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
.get_pages = i915_ttm_get_pages,
.put_pages = i915_ttm_put_pages,
--
2.26.3
