[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Add definitions for VRR registers and bits (rev3)
== Series Details == Series: drm/i915/tgl: Add definitions for VRR registers and bits (rev3) URL : https://patchwork.freedesktop.org/series/74410/ State : success == Summary == CI Bug Log - changes from CI_DRM_8156_full -> Patchwork_17019_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17019_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-vcs1: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +15 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-iclb4/igt@gem_b...@busy-vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-iclb7/igt@gem_b...@busy-vcs1.html * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-kbl3/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-kbl1/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-tglb3/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-tglb8/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@implicit-read-write-bsd1: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276] / [i915#677]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-iclb1/igt@gem_exec_sched...@implicit-read-write-bsd1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-iclb8/igt@gem_exec_sched...@implicit-read-write-bsd1.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-iclb7/igt@gem_exec_sched...@pi-common-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-iclb8/igt@gem_exec_sched...@reorder-wide-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-apl6/igt@gem_workarou...@suspend-resume-context.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([i915#151] / [i915#155]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-kbl7/igt@i915_pm_...@system-suspend-modeset.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-kbl6/igt@i915_pm_...@system-suspend-modeset.html * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#182]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-skl3/igt@kms_co...@pipe-a-ctm-0-5.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-skl9/igt@kms_co...@pipe-a-ctm-0-5.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#300]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#79]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@plain-flip-fb-recreate: - shard-kbl: [PASS][25] -> [FAIL][26] ([i915#34]) [25]:
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Add new PCI IDs to TGL (rev2)
On Thu, Mar 19, 2020 at 01:49:23AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/tgl: Add new PCI IDs to TGL (rev2) > URL : https://patchwork.freedesktop.org/series/74795/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_8154_full -> Patchwork_17017_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Applied to dinq. Thanks for the patch. Matt > > > > Known issues > > > Here are the changes found in Patchwork_17017_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_isolation@bcs0-s3: > - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl2/igt@gem_ctx_isolat...@bcs0-s3.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-apl6/igt@gem_ctx_isolat...@bcs0-s3.html > > * igt@gem_ctx_isolation@vecs0-s3: > - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl7/igt@gem_ctx_isolat...@vecs0-s3.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-apl1/igt@gem_ctx_isolat...@vecs0-s3.html > > * igt@gem_ctx_persistence@close-replace-race: > - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#1402]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-kbl1/igt@gem_ctx_persiste...@close-replace-race.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-kbl2/igt@gem_ctx_persiste...@close-replace-race.html > > * igt@gem_ctx_shared@exec-single-timeline-bsd: > - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html > > * igt@gem_exec_balancer@smoke: > - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110854]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_balan...@smoke.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb5/igt@gem_exec_balan...@smoke.html > > * igt@gem_exec_parallel@vcs1-fds: > - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112080]) +11 similar > issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb2/igt@gem_exec_paral...@vcs1-fds.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html > > * igt@gem_exec_schedule@implicit-both-bsd2: > - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276] / > [i915#677]) +2 similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd2.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd2.html > > * igt@gem_exec_schedule@independent-bsd2: > - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +32 similar > issues >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html > > * igt@gem_exec_schedule@pi-common-bsd: > - shard-iclb: [PASS][17] -> [SKIP][18] ([i915#677]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html > > * igt@gem_exec_schedule@preemptive-hang-bsd: > - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#112146]) +5 similar > issues >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb5/igt@gem_exec_sched...@preemptive-hang-bsd.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html > > * igt@i915_selftest@live@execlists: > - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#1430] / > [i915#656]) >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl4/igt@i915_selftest@l...@execlists.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-skl7/igt@i915_selftest@l...@execlists.html > - shard-glk: [PASS][23] -> [INCOMPLETE][24] ([i915#1430] / > [i915#58] / [i915#656] / [k.org#198133]) >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-glk8/igt@i915_selftest@l...@execlists.html >[24]: >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Add definitions for VRR registers and bits (rev3)
== Series Details == Series: drm/i915/tgl: Add definitions for VRR registers and bits (rev3) URL : https://patchwork.freedesktop.org/series/74410/ State : success == Summary == CI Bug Log - changes from CI_DRM_8156 -> Patchwork_17019 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/index.html Known issues Here are the changes found in Patchwork_17019 that come from known issues: ### IGT changes ### Possible fixes * igt@i915_selftest@live@execlists: - fi-apl-guc: [INCOMPLETE][1] ([fdo#103927] / [i915#1430] / [i915#656]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/fi-apl-guc/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/fi-apl-guc/igt@i915_selftest@l...@execlists.html - fi-bsw-kefka: [DMESG-FAIL][3] ([i915#1314]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][5] ([fdo#111407]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8156/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 [i915#1314]: https://gitlab.freedesktop.org/drm/intel/issues/1314 [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (44 -> 40) -- Missing(4): fi-bsw-cyan fi-byt-clapper fi-gdg-551 fi-snb-2520m Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8156 -> Patchwork_17019 CI-20190529: 20190529 CI_DRM_8156: ecef6724d06ce8e5adac2c4e77ab18f605b09a9a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17019: 0a8a0885ae0998b020295f4f865cb5d113138ae8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0a8a0885ae09 drm/i915/tgl: Add definitions for VRR registers and bits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17019/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: Add definitions for VRR registers and bits (rev3)
== Series Details == Series: drm/i915/tgl: Add definitions for VRR registers and bits (rev3) URL : https://patchwork.freedesktop.org/series/74410/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0a8a0885ae09 drm/i915/tgl: Add definitions for VRR registers and bits -:24: WARNING:BAD_SIGN_OFF: Duplicate signature #24: Signed-off-by: Aditya Swarup total: 0 errors, 1 warnings, 0 checks, 96 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
== Series Details == Series: series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences URL : https://patchwork.freedesktop.org/series/74851/ State : success == Summary == CI Bug Log - changes from CI_DRM_8154_full -> Patchwork_17018_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17018_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@engines-mixed-process@bcs0: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#679]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl6/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html * igt@gem_ctx_persistence@engines-mixed-process@vcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#1239]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl6/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-skl9/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb5/igt@gem_exec_sched...@preemptive-hang-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_exec_whisper@basic-fds-priority: - shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([i915#1401]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-tglb1/igt@gem_exec_whis...@basic-fds-priority.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-tglb5/igt@gem_exec_whis...@basic-fds-priority.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#644]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-kbl7/igt@gem_pp...@flink-and-close-vma-leak.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-kbl6/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_rpm@cursor-dpms: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#151]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl7/igt@i915_pm_...@cursor-dpms.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-skl3/igt@i915_pm_...@cursor-dpms.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#72]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl3/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-apl1/igt@kms_f...@flip-vs-suspend-interruptible.html - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +5 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-kbl6/igt@kms_f...@flip-vs-suspend-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-kbl2/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl5/igt@kms_...@bpc-switch.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-skl3/igt@kms_...@bpc-switch.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#69]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl10/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-skl:
[Intel-gfx] [PATCH v4] drm/i915/tgl: Add definitions for VRR registers and bits
Add definitions for registers grouped under Transcoder VRR function
with necessary bitfields.
Bspec: 49268
v2: Use REG_GENMASK, correct tabs/space indentation and move the
definitions near the transcoder section.(Jani)
v3: Remove unnecessary prefix from bit/mask definitions.(Manasi)
v4: Use 'trans' in macro for better readability.(Manasi)
Cc: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Matt Roper
Signed-off-by: Aditya Swarup
Reviewed-by: Manasi Navare
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 90 +
1 file changed, 90 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c53fe918be6..e154a3a73cf4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4324,6 +4324,96 @@ enum {
#define EXITLINE_MASKREG_GENMASK(12, 0)
#define EXITLINE_SHIFT 0
+/* VRR registers */
+#define _TRANS_VRR_CTL_A 0x60420
+#define _TRANS_VRR_CTL_B 0x61420
+#define _TRANS_VRR_CTL_C 0x62420
+#define _TRANS_VRR_CTL_D 0x63420
+#define TRANS_VRR_CTL(trans) _MMIO_TRANS2(trans, _TRANS_VRR_CTL_A)
+#define VRR_CTL_VRR_ENABLE REG_BIT(31)
+#define VRR_CTL_IGN_MAX_SHIFTREG_BIT(30)
+#define VRR_CTL_FLIP_LINE_EN REG_BIT(29)
+#define VRR_CTL_LINE_COUNT_MASK REG_GENMASK(10, 3)
+#define VRR_CTL_SW_FULLLINE_COUNTREG_BIT(0)
+
+#define _TRANS_VRR_VMAX_A 0x60424
+#define _TRANS_VRR_VMAX_B 0x61424
+#define _TRANS_VRR_VMAX_C 0x62424
+#define _TRANS_VRR_VMAX_D 0x63424
+#define TRANS_VRR_VMAX(trans) _MMIO_TRANS2(trans, _TRANS_VRR_VMAX_A)
+#define VRR_VMAX_MASKREG_GENMASK(19, 0)
+
+#define _TRANS_VRR_VMIN_A 0x60434
+#define _TRANS_VRR_VMIN_B 0x61434
+#define _TRANS_VRR_VMIN_C 0x62434
+#define _TRANS_VRR_VMIN_D 0x63434
+#define TRANS_VRR_VMIN(trans) _MMIO_TRANS2(trans, _TRANS_VRR_VMIN_A)
+#define VRR_VMIN_MASKREG_GENMASK(15, 0)
+
+#define _TRANS_VRR_VMAXSHIFT_A 0x60428
+#define _TRANS_VRR_VMAXSHIFT_B 0x61428
+#define _TRANS_VRR_VMAXSHIFT_C 0x62428
+#define _TRANS_VRR_VMAXSHIFT_D 0x63428
+#define TRANS_VRR_VMAXSHIFT(trans) _MMIO_TRANS2(trans, \
+ _TRANS_VRR_VMAXSHIFT_A)
+#define VRR_VMAXSHIFT_DEC_MASK REG_GENMASK(29, 16)
+#define VRR_VMAXSHIFT_DECREG_BIT(16)
+#define VRR_VMAXSHIFT_INC_MASK REG_GENMASK(12, 0)
+
+#define _TRANS_VRR_STATUS_A0x6042C
+#define _TRANS_VRR_STATUS_B0x6142C
+#define _TRANS_VRR_STATUS_C0x6242C
+#define _TRANS_VRR_STATUS_D0x6342C
+#define TRANS_VRR_STATUS(trans)_MMIO_TRANS2(trans,
_TRANS_VRR_STATUS_A)
+#define VRR_STATUS_VMAX_REACHED REG_BIT(31)
+#define VRR_STATUS_NOFLIP_TILL_BNDR REG_BIT(30)
+#define VRR_STATUS_FLIP_BEF_BNDR REG_BIT(29)
+#define VRR_STATUS_NO_FLIP_FRAME REG_BIT(28)
+#define VRR_STATUS_VRR_EN_LIVE REG_BIT(27)
+#define VRR_STATUS_FLIPS_SERVICEDREG_BIT(26)
+#define VRR_STATUS_VBLANK_MASK REG_GENMASK(22, 20)
+#define STATUS_FSM_IDLE REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
0)
+#define STATUS_FSM_WAIT_TILL_FDB REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
1)
+#define STATUS_FSM_WAIT_TILL_FS REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
2)
+#define STATUS_FSM_WAIT_TILL_FLIPREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
3)
+#define STATUS_FSM_PIPELINE_FILL REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
4)
+#define STATUS_FSM_ACTIVEREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
5)
+#define STATUS_FSM_LEGACY_VBLANK REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
6)
+
+#define _TRANS_VRR_VTOTAL_PREV_A 0x60480
+#define _TRANS_VRR_VTOTAL_PREV_B 0x61480
+#define _TRANS_VRR_VTOTAL_PREV_C 0x62480
+#define _TRANS_VRR_VTOTAL_PREV_D 0x63480
+#define TRANS_VRR_VTOTAL_PREV(trans) _MMIO_TRANS2(trans, \
+ _TRANS_VRR_VTOTAL_PREV_A)
+#define VRR_VTOTAL_FLIP_BEFR_BNDRREG_BIT(31)
+#define VRR_VTOTAL_FLIP_AFTER_BNDR REG_BIT(30)
+#define VRR_VTOTAL_FLIP_AFTER_DBLBUF REG_BIT(29)
+#define VRR_VTOTAL_PREV_FRAME_MASK REG_GENMASK(19, 0)
+
+#define _TRANS_VRR_FLIPLINE_A 0x60438
+#define _TRANS_VRR_FLIPLINE_B 0x61438
+#define _TRANS_VRR_FLIPLINE_C 0x62438
+#define _TRANS_VRR_FLIPLINE_D 0x63438
+#define TRANS_VRR_FLIPLINE(trans) _MMIO_TRANS2(trans, \
+ _TRANS_VRR_FLIPLINE_A)
+#define VRR_FLIPLINE_MASKREG_GENMASK(19, 0)
+
+#define _TRANS_VRR_STATUS2_A 0x6043C
+#define _TRANS_VRR_STATUS2_B 0x6143C
+#define _TRANS_VRR_STATUS2_C 0x6243C
+#define
[Intel-gfx] [PATCH v4] drm/i915/tgl: Add definitions for VRR registers and bits
Add definitions for registers grouped under Transcoder VRR function
with necessary bitfields.
Bspec: 49268
v2: Use REG_GENMASK, correct tabs/space indentation and move the
definitions near the transcoder section.(Jani)
v3: Remove unnecessary prefix from bit/mask definitions.(Manasi)
v4: Use 'trans' in macro for better readability.(Manasi)
Cc: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Matt Roper
Signed-off-by: Aditya Swarup
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/i915_reg.h | 90 +
1 file changed, 90 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c53fe918be6..b785142d4930 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4324,6 +4324,96 @@ enum {
#define EXITLINE_MASKREG_GENMASK(12, 0)
#define EXITLINE_SHIFT 0
+/* VRR registers */
+#define _TRANS_VRR_CTL_A 0x60420
+#define _TRANS_VRR_CTL_B 0x61420
+#define _TRANS_VRR_CTL_C 0x62420
+#define _TRANS_VRR_CTL_D 0x63420
+#define TRANS_VRR_CTL(tran)_MMIO_TRANS2(tran, _TRANS_VRR_CTL_A)
+#define VRR_CTL_VRR_ENABLE REG_BIT(31)
+#define VRR_CTL_IGN_MAX_SHIFTREG_BIT(30)
+#define VRR_CTL_FLIP_LINE_EN REG_BIT(29)
+#define VRR_CTL_LINE_COUNT_MASK REG_GENMASK(10, 3)
+#define VRR_CTL_SW_FULLLINE_COUNTREG_BIT(0)
+
+#define _TRANS_VRR_VMAX_A 0x60424
+#define _TRANS_VRR_VMAX_B 0x61424
+#define _TRANS_VRR_VMAX_C 0x62424
+#define _TRANS_VRR_VMAX_D 0x63424
+#define TRANS_VRR_VMAX(tran) _MMIO_TRANS2(tran, _TRANS_VRR_VMAX_A)
+#define VRR_VMAX_MASKREG_GENMASK(19, 0)
+
+#define _TRANS_VRR_VMIN_A 0x60434
+#define _TRANS_VRR_VMIN_B 0x61434
+#define _TRANS_VRR_VMIN_C 0x62434
+#define _TRANS_VRR_VMIN_D 0x63434
+#define TRANS_VRR_VMIN(tran) _MMIO_TRANS2(tran, _TRANS_VRR_VMIN_A)
+#define VRR_VMIN_MASKREG_GENMASK(15, 0)
+
+#define _TRANS_VRR_VMAXSHIFT_A 0x60428
+#define _TRANS_VRR_VMAXSHIFT_B 0x61428
+#define _TRANS_VRR_VMAXSHIFT_C 0x62428
+#define _TRANS_VRR_VMAXSHIFT_D 0x63428
+#define TRANS_VRR_VMAXSHIFT(tran) _MMIO_TRANS2(tran, \
+ _TRANS_VRR_VMAXSHIFT_A)
+#define VRR_VMAXSHIFT_DEC_MASK REG_GENMASK(29, 16)
+#define VRR_VMAXSHIFT_DECREG_BIT(16)
+#define VRR_VMAXSHIFT_INC_MASK REG_GENMASK(12, 0)
+
+#define _TRANS_VRR_STATUS_A0x6042C
+#define _TRANS_VRR_STATUS_B0x6142C
+#define _TRANS_VRR_STATUS_C0x6242C
+#define _TRANS_VRR_STATUS_D0x6342C
+#define TRANS_VRR_STATUS(tran) _MMIO_TRANS2(tran, _TRANS_VRR_STATUS_A)
+#define VRR_STATUS_VMAX_REACHED REG_BIT(31)
+#define VRR_STATUS_NOFLIP_TILL_BNDR REG_BIT(30)
+#define VRR_STATUS_FLIP_BEF_BNDR REG_BIT(29)
+#define VRR_STATUS_NO_FLIP_FRAME REG_BIT(28)
+#define VRR_STATUS_VRR_EN_LIVE REG_BIT(27)
+#define VRR_STATUS_FLIPS_SERVICEDREG_BIT(26)
+#define VRR_STATUS_VBLANK_MASK REG_GENMASK(22, 20)
+#define STATUS_FSM_IDLE REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
0)
+#define STATUS_FSM_WAIT_TILL_FDB REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
1)
+#define STATUS_FSM_WAIT_TILL_FS REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
2)
+#define STATUS_FSM_WAIT_TILL_FLIPREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
3)
+#define STATUS_FSM_PIPELINE_FILL REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
4)
+#define STATUS_FSM_ACTIVEREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
5)
+#define STATUS_FSM_LEGACY_VBLANK REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
6)
+
+#define _TRANS_VRR_VTOTAL_PREV_A 0x60480
+#define _TRANS_VRR_VTOTAL_PREV_B 0x61480
+#define _TRANS_VRR_VTOTAL_PREV_C 0x62480
+#define _TRANS_VRR_VTOTAL_PREV_D 0x63480
+#define TRANS_VRR_VTOTAL_PREV(tran)_MMIO_TRANS2(tran, \
+ _TRANS_VRR_VTOTAL_PREV_A)
+#define VRR_VTOTAL_FLIP_BEFR_BNDRREG_BIT(31)
+#define VRR_VTOTAL_FLIP_AFTER_BNDR REG_BIT(30)
+#define VRR_VTOTAL_FLIP_AFTER_DBLBUF REG_BIT(29)
+#define VRR_VTOTAL_PREV_FRAME_MASK REG_GENMASK(19, 0)
+
+#define _TRANS_VRR_FLIPLINE_A 0x60438
+#define _TRANS_VRR_FLIPLINE_B 0x61438
+#define _TRANS_VRR_FLIPLINE_C 0x62438
+#define _TRANS_VRR_FLIPLINE_D 0x63438
+#define TRANS_VRR_FLIPLINE(tran) _MMIO_TRANS2(tran, \
+ _TRANS_VRR_FLIPLINE_A)
+#define VRR_FLIPLINE_MASKREG_GENMASK(19, 0)
+
+#define _TRANS_VRR_STATUS2_A 0x6043C
+#define _TRANS_VRR_STATUS2_B 0x6143C
+#define _TRANS_VRR_STATUS2_C 0x6243C
+#define _TRANS_VRR_STATUS2_D 0x6343C
+#define
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Add new PCI IDs to TGL (rev2)
== Series Details == Series: drm/i915/tgl: Add new PCI IDs to TGL (rev2) URL : https://patchwork.freedesktop.org/series/74795/ State : success == Summary == CI Bug Log - changes from CI_DRM_8154_full -> Patchwork_17017_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17017_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl2/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-apl6/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_ctx_isolation@vecs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl7/igt@gem_ctx_isolat...@vecs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-apl1/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_ctx_persistence@close-replace-race: - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-kbl1/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-kbl2/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110854]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_balan...@smoke.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112080]) +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb2/igt@gem_exec_paral...@vcs1-fds.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd2: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276] / [i915#677]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd2.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb5/igt@gem_exec_sched...@implicit-both-bsd2.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +32 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][17] -> [SKIP][18] ([i915#677]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#112146]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb5/igt@gem_exec_sched...@preemptive-hang-bsd.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@i915_selftest@live@execlists: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#1430] / [i915#656]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl4/igt@i915_selftest@l...@execlists.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-skl7/igt@i915_selftest@l...@execlists.html - shard-glk: [PASS][23] -> [INCOMPLETE][24] ([i915#1430] / [i915#58] / [i915#656] / [k.org#198133]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-glk8/igt@i915_selftest@l...@execlists.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/shard-glk3/igt@i915_selftest@l...@execlists.html * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#72]) +1 similar issue [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off (rev3)
== Series Details == Series: drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off (rev3) URL : https://patchwork.freedesktop.org/series/74346/ State : success == Summary == CI Bug Log - changes from CI_DRM_8154_full -> Patchwork_17016_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17016_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +8 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_persistence@close-replace-race: - shard-kbl: [PASS][3] -> [INCOMPLETE][4] ([i915#1402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-kbl1/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-kbl6/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110841]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb8/igt@gem_exec_balan...@smoke.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112080]) +13 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb2/igt@gem_exec_paral...@vcs1-fds.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb6/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb6/igt@gem_exec_sched...@implicit-both-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb4/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +31 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#112146]) +7 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb5/igt@gem_exec_sched...@preemptive-hang-bsd.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb1/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#644]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl6/igt@gem_pp...@flink-and-close-vma-leak.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-apl4/igt@gem_pp...@flink-and-close-vma-leak.html - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb5/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_dc@dc5-dpms: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#447]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@i915_pm...@dc5-dpms.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/shard-iclb3/igt@i915_pm...@dc5-dpms.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][25] -> [DMESG-WARN][26] ([i915#180]) +1 similar issue [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html [26]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
== Series Details ==
Series: series starting with [1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
URL : https://patchwork.freedesktop.org/series/74851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8154 -> Patchwork_17018
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/index.html
Known issues
Here are the changes found in Patchwork_17018 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [FAIL][2] ([i915#579])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-bxt-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] /
[i915#656])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gem_contexts:
- fi-cml-s: [PASS][5] -> [DMESG-FAIL][6] ([i915#877])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
Possible fixes
* igt@i915_selftest@live@active:
- {fi-tgl-dsi}: [DMESG-FAIL][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-tgl-dsi/igt@i915_selftest@l...@active.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/fi-tgl-dsi/igt@i915_selftest@l...@active.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
[i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (47 -> 34)
--
Additional (1): fi-skl-guc
Missing(14): fi-kbl-soraka fi-ilk-m540 fi-bdw-samus fi-kbl-7560u
fi-bsw-n3050 fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-elk-e7500
fi-blb-e6850 fi-byt-clapper fi-skl-6600u fi-snb-2600
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8154 -> Patchwork_17018
CI-20190529: 20190529
CI_DRM_8154: 937a904e393752c47b8dfdeed993f04fd75af74d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17018: b56d3d92d0d79433bc14c62573d2e57132835e72 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b56d3d92d0d7 drm/i915/dp: Get TC link reference during DP detection
9ac457dd1e6a drm/i915/tc/icl: Implement the TC cold exit sequence
c6cad1aa0dcc drm/i915/display: Add intel_aux_ch_to_power_domain()
d52f8a2c3474 drm/i915/display: Implement intel_display_power_wait_enable_ack()
c582abc2c612 drm/i915/display: Add intel_display_power_get_without_ack()
ad57d1f87abe drm/i915/tc/tgl: Implement TCCOLD sequences
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17018/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Port sync for skl+ (rev3)
== Series Details == Series: drm/i915: Port sync for skl+ (rev3) URL : https://patchwork.freedesktop.org/series/74691/ State : success == Summary == CI Bug Log - changes from CI_DRM_8154_full -> Patchwork_17014_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17014_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-kbl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#1277]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-tglb2/igt@gem_exec_balan...@hang.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-tglb5/igt@gem_exec_balan...@hang.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_balan...@smoke.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-iclb3/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@implicit-both-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276] / [i915#677]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb1/igt@gem_exec_sched...@implicit-both-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-iclb7/igt@gem_exec_sched...@implicit-both-bsd2.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb8/igt@gem_exec_sched...@pi-common-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276]) +29 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb7/igt@gem_exec_sched...@reorder-wide-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-iclb1/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_exec_whisper@basic-fds-priority: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#1394] / [i915#1401]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb6/igt@gem_exec_whis...@basic-fds-priority.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-iclb2/igt@gem_exec_whis...@basic-fds-priority.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl6/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-apl2/igt@gem_pp...@flink-and-close-vma-leak.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#454]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-iclb4/igt@i915_pm...@dc6-dpms.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-sliding: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#54]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-256x85-sliding.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-256x85-sliding.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#79]) [25]:
[Intel-gfx] [PATCH 2/6] drm/i915/display: Add intel_display_power_get_without_ack()
To implement ICL TC static sequences is required to get the port aux
powerwell without wait for hardware ack.
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 71 +++
.../drm/i915/display/intel_display_power.h| 12
2 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 246e406bb385..9035b220dfa0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -157,14 +157,24 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
}
}
-static void intel_power_well_enable(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well)
+static void _intel_power_well_enable(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well,
+bool wait_ack)
{
drm_dbg_kms(_priv->drm, "enabling %s\n", power_well->desc->name);
- power_well->desc->ops->enable(dev_priv, power_well);
+ if (wait_ack || !power_well->desc->ops->enable_without_ack)
+ power_well->desc->ops->enable(dev_priv, power_well);
+ else
+ power_well->desc->ops->enable_without_ack(dev_priv, power_well);
power_well->hw_enabled = true;
}
+static void intel_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ _intel_power_well_enable(dev_priv, power_well, true);
+}
+
static void intel_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
@@ -174,10 +184,11 @@ static void intel_power_well_disable(struct
drm_i915_private *dev_priv,
}
static void intel_power_well_get(struct drm_i915_private *dev_priv,
-struct i915_power_well *power_well)
+struct i915_power_well *power_well,
+bool wait_ack)
{
if (!power_well->count++)
- intel_power_well_enable(dev_priv, power_well);
+ _intel_power_well_enable(dev_priv, power_well, wait_ack);
}
static void intel_power_well_put(struct drm_i915_private *dev_priv,
@@ -353,8 +364,9 @@ static void gen9_wait_for_power_well_fuses(struct
drm_i915_private *dev_priv,
SKL_FUSE_PG_DIST_STATUS(pg), 1));
}
-static void hsw_power_well_enable(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well)
+static void _hsw_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well,
+ bool wait_ack)
{
const struct i915_power_well_regs *regs = power_well->desc->hsw.regs;
int pw_idx = power_well->desc->hsw.idx;
@@ -379,7 +391,8 @@ static void hsw_power_well_enable(struct drm_i915_private
*dev_priv,
val = intel_de_read(dev_priv, regs->driver);
intel_de_write(dev_priv, regs->driver,
val | HSW_PWR_WELL_CTL_REQ(pw_idx));
- hsw_wait_for_power_well_enable(dev_priv, power_well);
+ if (wait_ack)
+ hsw_wait_for_power_well_enable(dev_priv, power_well);
/* Display WA #1178: cnl */
if (IS_CANNONLAKE(dev_priv) &&
@@ -398,6 +411,12 @@ static void hsw_power_well_enable(struct drm_i915_private
*dev_priv,
power_well->desc->hsw.has_vga);
}
+static void hsw_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ _hsw_power_well_enable(dev_priv, power_well, true);
+}
+
static void hsw_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
@@ -1960,7 +1979,8 @@ intel_display_power_grab_async_put_ref(struct
drm_i915_private *dev_priv,
static void
__intel_display_power_get_domain(struct drm_i915_private *dev_priv,
-enum intel_display_power_domain domain)
+enum intel_display_power_domain domain,
+bool wait_ack)
{
struct i915_power_domains *power_domains = _priv->power_domains;
struct i915_power_well *power_well;
@@ -1969,7 +1989,7 @@ __intel_display_power_get_domain(struct drm_i915_private
*dev_priv,
return;
for_each_power_domain_well(dev_priv, power_well, BIT_ULL(domain))
- intel_power_well_get(dev_priv, power_well);
+ intel_power_well_get(dev_priv, power_well, wait_ack);
power_domains->domain_use_count[domain]++;
}
[Intel-gfx] [PATCH 5/6] drm/i915/tc/icl: Implement the TC cold exit sequence
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.
Just request PCODE to exit TCCOLD is not enough as it could enter
again be driver makes use of the port, to prevent it BSpec states that
aux powerwell should be held.
So before detecting the mode, aux power is requested without wait for
hardware ack, PCODE is requested to exit TCCOLD and the TC detection
sequences follows as normal.
After detection if mode is not static aux can be powered off otherwise
we need to wait for HW ack as future calls to intel_display_power_get()
over aux will not check for HW ack.
BSpec: 21750
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 30 +-
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_tc.c | 56 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 80 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index a7e531b64e16..71a4c5d790ea 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -573,8 +573,9 @@ static void icl_tc_port_assert_ref_held(struct
drm_i915_private *dev_priv,
#define TGL_AUX_PW_TO_TC_PORT(pw_idx) ((pw_idx) - TGL_PW_CTL_IDX_AUX_TC1)
static void
-icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
-struct i915_power_well *power_well)
+_icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well,
+ bool wait_ack)
{
enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
u32 val;
@@ -587,7 +588,7 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
val |= DP_AUX_CH_CTL_TBT_IO;
intel_de_write(dev_priv, DP_AUX_CH_CTL(aux_ch), val);
- hsw_power_well_enable(dev_priv, power_well);
+ _hsw_power_well_enable(dev_priv, power_well, wait_ack);
if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc->hsw.is_tc_tbt) {
enum tc_port tc_port;
@@ -603,6 +604,20 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
}
}
+static void
+icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+ _icl_tc_phy_aux_power_well_enable(dev_priv, power_well, true);
+}
+
+static void
+icl_tc_phy_aux_power_well_enable_without_ack(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+ _icl_tc_phy_aux_power_well_enable(dev_priv, power_well, false);
+}
+
static void
icl_tc_phy_aux_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
@@ -642,6 +657,13 @@ static bool hsw_power_well_enabled(struct drm_i915_private
*dev_priv,
return (val & mask) == mask;
}
+static void
+hsw_power_well_wait_ack(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ hsw_wait_for_power_well_enable(dev_priv, power_well);
+}
+
static void assert_can_enable_dc9(struct drm_i915_private *dev_priv)
{
drm_WARN_ONCE(_priv->drm,
@@ -3582,8 +3604,10 @@ static const struct i915_power_well_ops
icl_combo_phy_aux_power_well_ops = {
static const struct i915_power_well_ops icl_tc_phy_aux_power_well_ops = {
.sync_hw = hsw_power_well_sync_hw,
.enable = icl_tc_phy_aux_power_well_enable,
+ .enable_without_ack = icl_tc_phy_aux_power_well_enable_without_ack,
.disable = icl_tc_phy_aux_power_well_disable,
.is_enabled = hsw_power_well_enabled,
+ .wait_enable_ack = hsw_power_well_wait_ack,
};
static const struct i915_power_well_regs icl_aux_power_well_regs = {
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077..9b90be43d67d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1386,6 +1386,7 @@ struct intel_digital_port {
enum tc_port_mode tc_mode;
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
+ intel_wakeref_t tc_cold_wakeref;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index e4c5de5ce874..e33dad9646a5 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -416,9 +416,6 @@ static void
[Intel-gfx] [PATCH 6/6] drm/i915/dp: Get TC link reference during DP detection
As now the cost to lock and use a TC port is higher due the
implementation of the TCCOLD sequences it is worty to hold a reference
of the TC port to avoid all this locking at every aux transaction
part of the DisplayPort detection.
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_dp.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index ef2e06e292d5..89b52211928b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5718,6 +5718,7 @@ intel_dp_detect(struct drm_connector *connector,
struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = _port->base;
+ enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
enum drm_connector_status status;
drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s]\n",
@@ -5726,12 +5727,17 @@ intel_dp_detect(struct drm_connector *connector,
!drm_modeset_is_locked(_priv->drm.mode_config.connection_mutex));
/* Can't disconnect eDP */
- if (intel_dp_is_edp(intel_dp))
+ if (intel_dp_is_edp(intel_dp)) {
status = edp_detect(intel_dp);
- else if (intel_digital_port_connected(encoder))
- status = intel_dp_detect_dpcd(intel_dp);
- else
- status = connector_status_disconnected;
+ } else {
+ if (intel_phy_is_tc(dev_priv, phy))
+ intel_tc_port_get_link(dig_port, 1);
+
+ if (intel_digital_port_connected(encoder))
+ status = intel_dp_detect_dpcd(intel_dp);
+ else
+ status = connector_status_disconnected;
+ }
if (status == connector_status_disconnected) {
memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5809,6 +5815,9 @@ intel_dp_detect(struct drm_connector *connector,
if (status != connector_status_connected && !intel_dp->is_mst)
intel_dp_unset_edid(intel_dp);
+ if (intel_phy_is_tc(dev_priv, phy))
+ intel_tc_port_put_link(dig_port);
+
/*
* Make sure the refs for power wells enabled during detect are
* dropped to avoid a new detect cycle triggered by HPD polling.
--
2.25.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915/display: Add intel_aux_ch_to_power_domain()
This is a similar function to intel_aux_power_domain() but it do not
care about TBT ports, this will be needed by GEN11 TC sequences.
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 14 --
drivers/gpu/drm/i915/display/intel_display.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f23c4d51c33..151e49ee6161 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7312,7 +7312,17 @@ intel_aux_power_domain(struct intel_digital_port
*dig_port)
}
}
- switch (dig_port->aux_ch) {
+ return intel_aux_ch_to_power_domain(dig_port->aux_ch);
+}
+
+/*
+ * Converts aux_ch to power_domain without caring about TBT ports for that use
+ * intel_aux_power_domain()
+ */
+enum intel_display_power_domain
+intel_aux_ch_to_power_domain(enum aux_ch aux_ch)
+{
+ switch (aux_ch) {
case AUX_CH_A:
return POWER_DOMAIN_AUX_A;
case AUX_CH_B:
@@ -7328,7 +7338,7 @@ intel_aux_power_domain(struct intel_digital_port
*dig_port)
case AUX_CH_G:
return POWER_DOMAIN_AUX_G;
default:
- MISSING_CASE(dig_port->aux_ch);
+ MISSING_CASE(aux_ch);
return POWER_DOMAIN_AUX_A;
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index adb1225a3480..ad50119c0453 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -579,6 +579,8 @@ void hsw_disable_ips(const struct intel_crtc_state
*crtc_state);
enum intel_display_power_domain intel_port_to_power_domain(enum port port);
enum intel_display_power_domain
intel_aux_power_domain(struct intel_digital_port *dig_port);
+enum intel_display_power_domain
+intel_aux_ch_to_power_domain(enum aux_ch aux_ch);
void intel_mode_from_pipe_config(struct drm_display_mode *mode,
struct intel_crtc_state *pipe_config);
void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
--
2.25.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/display: Implement intel_display_power_wait_enable_ack()
This function is meant to be used after
intel_display_power_get_without_ack() this way we can be sure that the
HW tied to the powerdomain will be powered and ready.
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 29 +++
.../drm/i915/display/intel_display_power.h| 9 ++
2 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 9035b220dfa0..a7e531b64e16 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -2328,6 +2328,35 @@ intel_display_power_flush_work_sync(struct
drm_i915_private *i915)
drm_WARN_ON(>drm, power_domains->async_put_wakeref);
}
+/**
+ * intel_display_power_wait_enable_ack - wait for enabled hardware ack
+ * @dev_priv: i915 device instance
+ * @domain: power domain to reference
+ *
+ * This function must be called after intel_display_power_get_without_ack() and
+ * only in power domains that implements it.
+ */
+void intel_display_power_wait_enable_ack(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain domain)
+{
+ struct i915_power_domains *power_domains = _priv->power_domains;
+ struct i915_power_well *power_well;
+
+ mutex_lock(_domains->lock);
+
+ for_each_power_domain_well_reverse(dev_priv, power_well,
+ BIT_ULL(domain)) {
+ if (drm_WARN_ON(_priv->drm,
+ !power_well->desc->ops->wait_enable_ack))
+ break;
+
+ power_well->desc->ops->wait_enable_ack(dev_priv, power_well);
+ break;
+ }
+
+ mutex_unlock(_domains->lock);
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
/**
* intel_display_power_put - release a power domain reference
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 5db86cc862c3..108096177deb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -148,6 +148,13 @@ struct i915_power_well_ops {
/* Returns the hw enabled state. */
bool (*is_enabled)(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well);
+
+ /*
+* Waits for hardware enabling ack, this is meant to be used together
+* with enable_without_ack() and also optional.
+*/
+ void (*wait_enable_ack)(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well);
};
struct i915_power_well_regs {
@@ -291,6 +298,8 @@ void __intel_display_power_put_async(struct
drm_i915_private *i915,
enum intel_display_power_domain domain,
intel_wakeref_t wakeref);
void intel_display_power_flush_work(struct drm_i915_private *i915);
+void intel_display_power_wait_enable_ack(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain
domain);
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
void intel_display_power_put(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain,
--
2.25.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915/tc/tgl: Implement TCCOLD sequences
TC ports can enter in TCCOLD to save power and is required to request
to PCODE to exit this state before use or read to TC registers.
For TGL there is a new MBOX command to do that with a parameter to ask
PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
For GEN11 the sequence is more complex and will be handled in a
separated patch.
BSpec: 49294
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_tc.c | 61 -
drivers/gpu/drm/i915/i915_reg.h | 3 ++
drivers/gpu/drm/i915/intel_sideband.c | 22 +
drivers/gpu/drm/i915/intel_sideband.h | 4 ++
4 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 9b850c11aa78..e4c5de5ce874 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -7,6 +7,7 @@
#include "intel_display.h"
#include "intel_display_types.h"
#include "intel_dp_mst.h"
+#include "intel_sideband.h"
#include "intel_tc.h"
static const char *tc_port_mode_name(enum tc_port_mode mode)
@@ -496,6 +497,55 @@ bool intel_tc_port_connected(struct intel_digital_port
*dig_port)
return is_connected;
}
+static inline int tgl_tc_cold_request(struct intel_digital_port *dig_port,
+ bool block)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ u32 low_val, high_val;
+ u8 tries = 0;
+ int ret;
+
+ do {
+ low_val = 0;
+ high_val = block ? 0 : TGL_PCODE_EXIT_TCCOLD_DATA_H_UNBLOCK_REQ;
+
+ ret = sandybridge_pcode_write_read_timeout(i915,
+ TGL_PCODE_TCCOLD,
+ _val, _val,
+ 150, 1);
+ if (ret == 0) {
+ if (block &&
+ low_val & TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED)
+ ret = -EIO;
+ else
+ break;
+ }
+
+ if (ret != -EAGAIN)
+ tries++;
+ } while (tries < 3);
+
+ return ret;
+}
+
+static int tc_cold_request(struct intel_digital_port *dig_port, bool block)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ int ret;
+
+ if (INTEL_GEN(i915) >= 12)
+ ret = tgl_tc_cold_request(dig_port, block);
+ else
+ /* TODO: implement GEN11 TCCOLD sequences */
+ ret = 0;
+
+ drm_dbg_kms(>drm, "Port %s: TCCOLD %sblock %s\n",
+ dig_port->tc_port_name, (block ? "" : "un"),
+ (ret == 0 ? "succeeded" : "failed"));
+
+ return ret;
+}
+
static void __intel_tc_port_lock(struct intel_digital_port *dig_port,
int required_lanes)
{
@@ -506,9 +556,11 @@ static void __intel_tc_port_lock(struct intel_digital_port
*dig_port,
mutex_lock(_port->tc_lock);
- if (!dig_port->tc_link_refcount &&
- intel_tc_port_needs_reset(dig_port))
+ if (dig_port->tc_link_refcount == 0) {
+ tc_cold_request(dig_port, true);
+ intel_tc_port_needs_reset(dig_port);
intel_tc_port_reset_mode(dig_port, required_lanes);
+ }
drm_WARN_ON(>drm, dig_port->tc_lock_wakeref);
dig_port->tc_lock_wakeref = wakeref;
@@ -524,6 +576,9 @@ void intel_tc_port_unlock(struct intel_digital_port
*dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
intel_wakeref_t wakeref = fetch_and_zero(_port->tc_lock_wakeref);
+ if (dig_port->tc_link_refcount == 0)
+ tc_cold_request(dig_port, false);
+
mutex_unlock(_port->tc_lock);
intel_display_power_put_async(i915, POWER_DOMAIN_DISPLAY_CORE,
@@ -548,6 +603,8 @@ void intel_tc_port_put_link(struct intel_digital_port
*dig_port)
{
mutex_lock(_port->tc_lock);
dig_port->tc_link_refcount--;
+ if (dig_port->tc_link_refcount == 0)
+ tc_cold_request(dig_port, false);
mutex_unlock(_port->tc_lock);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c53fe918be6..7e341d9945b3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9019,6 +9019,9 @@ enum {
#define GEN6_PCODE_WRITE_D_COMP 0x11
#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
#define DISPLAY_IPS_CONTROL 0x19
+#define TGL_PCODE_TCCOLD 0x26
+#define TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED REG_BIT(0)
+#define TGL_PCODE_EXIT_TCCOLD_DATA_H_UNBLOCK_REQ REG_BIT(0)
/* See also
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Add new PCI IDs to TGL (rev2)
== Series Details ==
Series: drm/i915/tgl: Add new PCI IDs to TGL (rev2)
URL : https://patchwork.freedesktop.org/series/74795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8154 -> Patchwork_17017
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/index.html
Known issues
Here are the changes found in Patchwork_17017 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@active:
- {fi-tgl-dsi}: [DMESG-FAIL][1] -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-tgl-dsi/igt@i915_selftest@l...@active.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/fi-tgl-dsi/igt@i915_selftest@l...@active.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
Participating hosts (47 -> 40)
--
Additional (1): fi-skl-guc
Missing(8): fi-ilk-m540 fi-byt-j1900 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8154 -> Patchwork_17017
CI-20190529: 20190529
CI_DRM_8154: 937a904e393752c47b8dfdeed993f04fd75af74d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17017: 9d5998b1eddd9e4e8a6a6bbd0a39edb14664eed4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9d5998b1eddd drm/i915/tgl: Add new PCI IDs to TGL
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17017/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/13] drm/i915: Implement port sync for SKL+
On Fri, Mar 13, 2020 at 06:48:26PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Transcoder port sync was introduced to the hardware in BDW. We
> can trivially enable it for SKL+ since the same codepaths are
> already used for ICL+ port sync. The only difference is the actual
> location of the bits we need to poke.
>
> We leave BDW out (at least for now) since it uses different modeset
> paths that haven't been adapted for port sync, and IIRC using the
> feature would involve some extra workarounds we've not implemented.
>
> Pre-BDW hardware does not support port sync so we'd have to tweak
> the modeset sequence to start the pipes as close together as possible
> and hope for the best. So far no one has seriously tried to implement
> that.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/issues/27
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 70 +---
> drivers/gpu/drm/i915/display/intel_dp.c | 6 +-
> drivers/gpu/drm/i915/i915_reg.h | 3 +
> 3 files changed, 59 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 0fea2ec2cdd8..9e6eb0ee5ba4 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1450,6 +1450,14 @@ void intel_ddi_set_dp_msa(const struct
> intel_crtc_state *crtc_state,
> intel_de_write(dev_priv, TRANS_MSA_MISC(cpu_transcoder), temp);
> }
>
> +static u32 bdw_trans_port_sync_master_select(enum transcoder
> master_transcoder)
> +{
> + if (master_transcoder == TRANSCODER_EDP)
> + return 0;
> + else
> + return master_transcoder + 1;
> +}
> +
> /*
> * Returns the TRANS_DDI_FUNC_CTL value based on CRTC state.
> *
> @@ -1550,6 +1558,15 @@ intel_ddi_transcoder_func_reg_val_get(const struct
> intel_crtc_state *crtc_state)
> temp |= DDI_PORT_WIDTH(crtc_state->lane_count);
> }
>
> + if (IS_GEN_RANGE(dev_priv, 8, 10) &&
> + crtc_state->master_transcoder != INVALID_TRANSCODER) {
> + u8 master_select =
> +
> bdw_trans_port_sync_master_select(crtc_state->master_transcoder);
> +
> + temp |= TRANS_DDI_PORT_SYNC_ENABLE |
> + TRANS_DDI_PORT_SYNC_MASTER_SELECT(master_select);
> + }
> +
> return temp;
> }
>
> @@ -1565,12 +1582,8 @@ void intel_ddi_enable_transcoder_func(const struct
> intel_crtc_state *crtc_state)
> u32 ctl2 = 0;
>
> if (master_transcoder != INVALID_TRANSCODER) {
> - u8 master_select;
> -
> - if (master_transcoder == TRANSCODER_EDP)
> - master_select = 0;
> - else
> - master_select = master_transcoder + 1;
> + u8 master_select =
> +
> bdw_trans_port_sync_master_select(master_transcoder);
>
> ctl2 |= PORT_SYNC_MODE_ENABLE |
> PORT_SYNC_MODE_MASTER_SELECT(master_select);
> @@ -1614,8 +1627,13 @@ void intel_ddi_disable_transcoder_func(const struct
> intel_crtc_state *crtc_state
> intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL2(cpu_transcoder),
> 0);
>
> ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> +
> ctl &= ~TRANS_DDI_FUNC_ENABLE;
>
> + if (IS_GEN_RANGE(dev_priv, 8, 10))
> + ctl &= ~(TRANS_DDI_PORT_SYNC_ENABLE |
> + TRANS_DDI_PORT_SYNC_MASTER_SELECT_MASK);
> +
> if (INTEL_GEN(dev_priv) >= 12) {
> if (!intel_dp_mst_is_master_trans(crtc_state)) {
> ctl &= ~(TGL_TRANS_DDI_PORT_MASK |
> @@ -1624,6 +1642,7 @@ void intel_ddi_disable_transcoder_func(const struct
> intel_crtc_state *crtc_state
> } else {
> ctl &= ~(TRANS_DDI_PORT_MASK | TRANS_DDI_MODE_SELECT_MASK);
> }
> +
> intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), ctl);
>
> if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
> @@ -3842,17 +3861,26 @@ void intel_ddi_compute_min_voltage_level(struct
> drm_i915_private *dev_priv,
> crtc_state->min_voltage_level = 2;
> }
>
> -static enum transcoder transcoder_master_readout(struct drm_i915_private
> *dev_priv,
> - enum transcoder cpu_transcoder)
> +static enum transcoder bdw_transcoder_master_readout(struct drm_i915_private
> *dev_priv,
> + enum transcoder
> cpu_transcoder)
> {
> - u32 ctl2, master_select;
> + u32 master_select;
>
> - ctl2 = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL2(cpu_transcoder));
> + if (INTEL_GEN(dev_priv) >= 11) {
> + u32 ctl2 = intel_de_read(dev_priv,
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off (rev3)
== Series Details ==
Series: drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off (rev3)
URL : https://patchwork.freedesktop.org/series/74346/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8154 -> Patchwork_17016
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/index.html
Known issues
Here are the changes found in Patchwork_17016 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][1] -> [FAIL][2] ([i915#323])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@i915_selftest@live@active:
- {fi-tgl-dsi}: [DMESG-FAIL][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-tgl-dsi/igt@i915_selftest@l...@active.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/fi-tgl-dsi/igt@i915_selftest@l...@active.html
* igt@i915_selftest@live@execlists:
- {fi-kbl-7560u}: [INCOMPLETE][5] ([fdo#112259] / [i915#1430] /
[i915#656]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-7560u/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/fi-kbl-7560u/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#112259]: https://bugs.freedesktop.org/show_bug.cgi?id=112259
[i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
Participating hosts (47 -> 41)
--
Additional (1): fi-skl-guc
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8154 -> Patchwork_17016
CI-20190529: 20190529
CI_DRM_8154: 937a904e393752c47b8dfdeed993f04fd75af74d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17016: 8e25aebc066eeff2e34cde892ae2798f236662cf @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8e25aebc066e drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17016/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/13] drm/i915: Include port sync state in the state dump
On Fri, Mar 13, 2020 at 06:48:24PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Dump the port sync stat in intel_dump_pipe_config(). > > Signed-off-by: Ville Syrjälä Reviewed-by: Manasi Navare Manasi > --- > drivers/gpu/drm/i915/display/intel_display.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 5c5a131db8b4..4840988dc58d 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -12947,6 +12947,11 @@ static void intel_dump_pipe_config(const struct > intel_crtc_state *pipe_config, > transcoder_name(pipe_config->cpu_transcoder), > pipe_config->pipe_bpp, pipe_config->dither); > > + drm_dbg_kms(_priv->drm, > + "port sync: master transcoder: %s, slave transcoder bitmask > = 0x%x\n", > + transcoder_name(pipe_config->master_transcoder), > + pipe_config->sync_mode_slaves_mask); > + > if (pipe_config->has_pch_encoder) > intel_dump_m_n_config(pipe_config, "fdi", > pipe_config->fdi_lanes, > -- > 2.24.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Reject dumb buffers when driver/device doesn't support modesetting (rev2)
== Series Details == Series: drm: Reject dumb buffers when driver/device doesn't support modesetting (rev2) URL : https://patchwork.freedesktop.org/series/74841/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8154 -> Patchwork_17015 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17015 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17015, 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_17015/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17015: ### IGT changes ### Possible regressions * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-8809g: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-kbl-8809g/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@gem_ringfill@basic-default-forked: - fi-hsw-peppy: [PASS][2] -> [FAIL][3] +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-hsw-peppy/igt@gem_ringf...@basic-default-forked.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-hsw-peppy/igt@gem_ringf...@basic-default-forked.html - fi-kbl-x1275: [PASS][4] -> [FAIL][5] +18 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-x1275/igt@gem_ringf...@basic-default-forked.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-kbl-x1275/igt@gem_ringf...@basic-default-forked.html * igt@i915_selftest@live@blt: - fi-snb-2520m: [PASS][6] -> [DMESG-FAIL][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-snb-2520m/igt@i915_selftest@l...@blt.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-snb-2520m/igt@i915_selftest@l...@blt.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-7500u: [PASS][8] -> [FAIL][9] +18 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html * igt@prime_vgem@basic-fence-mmap: - fi-byt-j1900: [PASS][10] -> [FAIL][11] +18 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-byt-j1900/igt@prime_v...@basic-fence-mmap.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-byt-j1900/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-fence-read: - fi-bsw-kefka: [PASS][12] -> [FAIL][13] +17 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-bsw-kefka/igt@prime_v...@basic-fence-read.html - fi-cml-s: [PASS][14] -> [FAIL][15] +18 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-cml-s/igt@prime_v...@basic-fence-read.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-cml-s/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-fence-wait-default: - fi-cfl-8109u: [PASS][16] -> [FAIL][17] +18 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-cfl-8109u/igt@prime_v...@basic-fence-wait-default.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-cfl-8109u/igt@prime_v...@basic-fence-wait-default.html - fi-bsw-nick:[PASS][18] -> [FAIL][19] +17 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-bsw-nick/igt@prime_v...@basic-fence-wait-default.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-bsw-nick/igt@prime_v...@basic-fence-wait-default.html * igt@prime_vgem@basic-gtt: - fi-ilk-650: [PASS][20] -> [FAIL][21] +18 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-ilk-650/igt@prime_v...@basic-gtt.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-ilk-650/igt@prime_v...@basic-gtt.html * igt@prime_vgem@basic-read: - fi-kbl-guc: [PASS][22] -> [FAIL][23] +17 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-guc/igt@prime_v...@basic-read.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-kbl-guc/igt@prime_v...@basic-read.html - fi-icl-guc: [PASS][24] -> [FAIL][25] +18 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-icl-guc/igt@prime_v...@basic-read.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17015/fi-icl-guc/igt@prime_v...@basic-read.html -
Re: [Intel-gfx] [PATCH 05/13] drm/i915: Use REG_FIELD_PREP() & co. for TRANS_DDI_FUNC_CTL2
On Fri, Mar 13, 2020 at 06:48:23PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Clean up the TRANS_DDI_FUNC_CTL2 programming/readout by
> using REG_FIELD_PREP() & co.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
> drivers/gpu/drm/i915/i915_reg.h | 10 --
> 2 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 39f3e9452aad..8bb6c583abb8 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1573,9 +1573,7 @@ void intel_ddi_enable_transcoder_func(const struct
> intel_crtc_state *crtc_state)
> master_select = master_transcoder + 1;
>
> ctl2 |= PORT_SYNC_MODE_ENABLE |
> - (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> - PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> - PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> + PORT_SYNC_MODE_MASTER_SELECT(master_select);
> }
>
> intel_de_write(dev_priv,
> @@ -3854,7 +3852,7 @@ static enum transcoder transcoder_master_readout(struct
> drm_i915_private *dev_pr
> if ((ctl2 & PORT_SYNC_MODE_ENABLE) == 0)
> return INVALID_TRANSCODER;
>
> - master_select = ctl2 & PORT_SYNC_MODE_MASTER_SELECT_MASK;
> + master_select = REG_FIELD_GET(PORT_SYNC_MODE_MASTER_SELECT_MASK, ctl2);
>
> if (master_select == 0)
> return TRANSCODER_EDP;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 309cb7d96b35..fc5c00bfed87 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9726,12 +9726,10 @@ enum skl_power_gate {
> #define _TRANS_DDI_FUNC_CTL2_EDP 0x6f404
> #define _TRANS_DDI_FUNC_CTL2_DSI00x6b404
> #define _TRANS_DDI_FUNC_CTL2_DSI10x6bc04
> -#define TRANS_DDI_FUNC_CTL2(tran)_MMIO_TRANS2(tran, \
> - _TRANS_DDI_FUNC_CTL2_A)
> -#define PORT_SYNC_MODE_ENABLE (1 << 4)
> -#define PORT_SYNC_MODE_MASTER_SELECT(x) ((x) << 0)
> -#define PORT_SYNC_MODE_MASTER_SELECT_MASK (0x7 << 0)
> -#define PORT_SYNC_MODE_MASTER_SELECT_SHIFT 0
> +#define TRANS_DDI_FUNC_CTL2(tran)_MMIO_TRANS2(tran,
> _TRANS_DDI_FUNC_CTL2_A)
> +#define PORT_SYNC_MODE_ENABLE REG_BIT(4)
> +#define PORT_SYNC_MODE_MASTER_SELECT_MASK REG_GENMASK(2, 0)
> +#define PORT_SYNC_MODE_MASTER_SELECT(x)
> REG_FIELD_PREP(PORT_SYNC_MODE_MASTER_SELECT_MASK, (x))
>
> /* DisplayPort Transport Control */
> #define _DP_TP_CTL_A 0x64040
> --
> 2.24.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/13] drm/i915: Move icl_get_trans_port_sync_config() into the DDI code
On Fri, Mar 13, 2020 at 06:48:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the port sync readout into the DDI code where it belongs.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 54 ++
> drivers/gpu/drm/i915/display/intel_display.c | 59
> 2 files changed, 54 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 8d486282eea3..39f3e9452aad 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3844,6 +3844,57 @@ void intel_ddi_compute_min_voltage_level(struct
> drm_i915_private *dev_priv,
> crtc_state->min_voltage_level = 2;
> }
>
> +static enum transcoder transcoder_master_readout(struct drm_i915_private
> *dev_priv,
> + enum transcoder cpu_transcoder)
> +{
> + u32 ctl2, master_select;
> +
> + ctl2 = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL2(cpu_transcoder));
> +
> + if ((ctl2 & PORT_SYNC_MODE_ENABLE) == 0)
> + return INVALID_TRANSCODER;
> +
> + master_select = ctl2 & PORT_SYNC_MODE_MASTER_SELECT_MASK;
> +
> + if (master_select == 0)
> + return TRANSCODER_EDP;
> + else
> + return master_select - 1;
> +}
> +
> +static void icl_get_trans_port_sync_config(struct intel_crtc_state
> *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> + u32 transcoders = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
> + BIT(TRANSCODER_C) | BIT(TRANSCODER_D);
> + enum transcoder cpu_transcoder;
> +
> + crtc_state->master_transcoder =
> + transcoder_master_readout(dev_priv, crtc_state->cpu_transcoder);
> +
> + for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
> + enum intel_display_power_domain power_domain;
> + intel_wakeref_t trans_wakeref;
> +
> + power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> + trans_wakeref = intel_display_power_get_if_enabled(dev_priv,
> +
> power_domain);
> +
> + if (!trans_wakeref)
> + continue;
> +
> + if (transcoder_master_readout(dev_priv, cpu_transcoder) ==
> + crtc_state->cpu_transcoder)
> + crtc_state->sync_mode_slaves_mask |=
> BIT(cpu_transcoder);
> +
> + intel_display_power_put(dev_priv, power_domain, trans_wakeref);
> + }
> +
> + drm_WARN_ON(_priv->drm,
> + crtc_state->master_transcoder != INVALID_TRANSCODER &&
> + crtc_state->sync_mode_slaves_mask);
> +}
> +
> void intel_ddi_get_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config)
> {
> @@ -3995,6 +4046,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
> intel_read_infoframe(encoder, pipe_config,
>HDMI_INFOFRAME_TYPE_DRM,
>_config->infoframes.drm);
> +
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_get_trans_port_sync_config(pipe_config);
> }
>
> static enum intel_output_type
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 12823d8f6afe..5c5a131db8b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11049,61 +11049,6 @@ static void hsw_get_ddi_port_state(struct intel_crtc
> *crtc,
> }
> }
>
> -static enum transcoder transcoder_master_readout(struct drm_i915_private
> *dev_priv,
> - enum transcoder cpu_transcoder)
> -{
> - u32 trans_port_sync, master_select;
> -
> - trans_port_sync = intel_de_read(dev_priv,
> - TRANS_DDI_FUNC_CTL2(cpu_transcoder));
> -
> - if ((trans_port_sync & PORT_SYNC_MODE_ENABLE) == 0)
> - return INVALID_TRANSCODER;
> -
> - master_select = trans_port_sync &
> - PORT_SYNC_MODE_MASTER_SELECT_MASK;
> - if (master_select == 0)
> - return TRANSCODER_EDP;
> - else
> - return master_select - 1;
> -}
> -
> -static void icl_get_trans_port_sync_config(struct intel_crtc_state
> *crtc_state)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> - u32 transcoders;
> - enum transcoder cpu_transcoder;
> -
> - crtc_state->master_transcoder = transcoder_master_readout(dev_priv,
> -
> crtc_state->cpu_transcoder);
> -
> - transcoders = BIT(TRANSCODER_A) |
> - BIT(TRANSCODER_B) |
> - BIT(TRANSCODER_C) |
>
Re: [Intel-gfx] [PATCH 03/13] drm/i915: Drop usless master_transcoder assignments
On Fri, Mar 13, 2020 at 06:48:21PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The entire crtc state has been reset before readout so > master_transcoder is already set to INVALID. But wont that mean that the master transcoder would be set to 0 on reset and what we want is actually setting that to INVALID Manasi > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_display.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index c49b4e6eb3d4..12823d8f6afe 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -9364,7 +9364,6 @@ static bool i9xx_get_pipe_config(struct intel_crtc > *crtc, > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; > pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe; > pipe_config->shared_dpll = NULL; > - pipe_config->master_transcoder = INVALID_TRANSCODER; > > ret = false; > > @@ -10588,7 +10587,6 @@ static bool ilk_get_pipe_config(struct intel_crtc > *crtc, > > pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe; > pipe_config->shared_dpll = NULL; > - pipe_config->master_transcoder = INVALID_TRANSCODER; > > ret = false; > tmp = intel_de_read(dev_priv, PIPECONF(crtc->pipe)); > -- > 2.24.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/13] drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it belongs
On Fri, Mar 13, 2020 at 06:48:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> This port sync enable/disable stuff is misplaced. It's just another step
> of the normal TRANS_DDI_FUNC_CTL enable. Move it to its natural place.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 71 +++-
> drivers/gpu/drm/i915/display/intel_display.c | 34 --
> 2 files changed, 39 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 73d0f4648c06..8d486282eea3 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1558,12 +1558,34 @@ void intel_ddi_enable_transcoder_func(const struct
> intel_crtc_state *crtc_state)
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - u32 temp;
> + u32 ctl;
>
> - temp = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> + if (INTEL_GEN(dev_priv) >= 11) {
> + enum transcoder master_transcoder =
> crtc_state->master_transcoder;
> + u32 ctl2 = 0;
> +
> + if (master_transcoder != INVALID_TRANSCODER) {
> + u8 master_select;
> +
> + if (master_transcoder == TRANSCODER_EDP)
> + master_select = 0;
> + else
> + master_select = master_transcoder + 1;
> +
> + ctl2 |= PORT_SYNC_MODE_ENABLE |
> + (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> + PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> + }
> +
> + intel_de_write(dev_priv,
> +TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> ctl2);
> + }
> +
> + ctl = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
> - temp |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
> - intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
> + ctl |= TRANS_DDI_DP_VC_PAYLOAD_ALLOC;
> + intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), ctl);
> }
>
> /*
> @@ -1576,11 +1598,11 @@ intel_ddi_config_transcoder_func(const struct
> intel_crtc_state *crtc_state)
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - u32 temp;
> + u32 ctl;
>
> - temp = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> - temp &= ~TRANS_DDI_FUNC_ENABLE;
> - intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
> + ctl = intel_ddi_transcoder_func_reg_val_get(crtc_state);
> + ctl &= ~TRANS_DDI_FUNC_ENABLE;
> + intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), ctl);
> }
>
> void intel_ddi_disable_transcoder_func(const struct intel_crtc_state
> *crtc_state)
> @@ -1588,20 +1610,23 @@ void intel_ddi_disable_transcoder_func(const struct
> intel_crtc_state *crtc_state
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> - u32 val;
> + u32 ctl;
>
> - val = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> - val &= ~TRANS_DDI_FUNC_ENABLE;
> + if (INTEL_GEN(dev_priv) >= 11)
> + intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL2(cpu_transcoder),
> 0);
This should be set to 0 only for the slave where we enable the port sync mode so
set it to 0 only if if (old_crtc_state->master_transcoder != INVALID_TRANSCODER)
This will just ensure that we dont accidently set it to 0 for non slave
transcoders
Manasi
> +
> + ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
> + ctl &= ~TRANS_DDI_FUNC_ENABLE;
>
> if (INTEL_GEN(dev_priv) >= 12) {
> if (!intel_dp_mst_is_master_trans(crtc_state)) {
> - val &= ~(TGL_TRANS_DDI_PORT_MASK |
> + ctl &= ~(TGL_TRANS_DDI_PORT_MASK |
>TRANS_DDI_MODE_SELECT_MASK);
> }
> } else {
> - val &= ~(TRANS_DDI_PORT_MASK | TRANS_DDI_MODE_SELECT_MASK);
> + ctl &= ~(TRANS_DDI_PORT_MASK | TRANS_DDI_MODE_SELECT_MASK);
> }
> - intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), val);
> + intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), ctl);
>
> if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
>
[Intel-gfx] [PATCH] drm/i915/tgl: Add new PCI IDs to TGL
Adding 4 new PCI IDs to TGL Bspec: 44455 Signed-off-by: Swathi Dhanavanthri --- include/drm/i915_pciids.h | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h index 1d2c12219f44..662d8351c87a 100644 --- a/include/drm/i915_pciids.h +++ b/include/drm/i915_pciids.h @@ -593,12 +593,16 @@ /* TGL */ #define INTEL_TGL_12_IDS(info) \ - INTEL_VGA_DEVICE(0x9A49, info), \ INTEL_VGA_DEVICE(0x9A40, info), \ + INTEL_VGA_DEVICE(0x9A49, info), \ INTEL_VGA_DEVICE(0x9A59, info), \ INTEL_VGA_DEVICE(0x9A60, info), \ INTEL_VGA_DEVICE(0x9A68, info), \ INTEL_VGA_DEVICE(0x9A70, info), \ - INTEL_VGA_DEVICE(0x9A78, info) + INTEL_VGA_DEVICE(0x9A78, info), \ + INTEL_VGA_DEVICE(0x9AC0, info), \ + INTEL_VGA_DEVICE(0x9AC9, info), \ + INTEL_VGA_DEVICE(0x9AD9, info), \ + INTEL_VGA_DEVICE(0x9AF8, info) #endif /* _I915_PCIIDS_H */ -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Port sync for skl+ (rev3)
== Series Details ==
Series: drm/i915: Port sync for skl+ (rev3)
URL : https://patchwork.freedesktop.org/series/74691/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8154 -> Patchwork_17014
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/index.html
Known issues
Here are the changes found in Patchwork_17014 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@active:
- fi-icl-dsi: [PASS][1] -> [DMESG-FAIL][2] ([i915#765])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-icl-dsi/igt@i915_selftest@l...@active.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/fi-icl-dsi/igt@i915_selftest@l...@active.html
* igt@i915_selftest@live@execlists:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] /
[i915#656])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-apl-guc/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/fi-apl-guc/igt@i915_selftest@l...@execlists.html
- fi-bxt-dsi: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927] /
[i915#656])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111407])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@i915_selftest@live@active:
- {fi-tgl-dsi}: [DMESG-FAIL][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-tgl-dsi/igt@i915_selftest@l...@active.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/fi-tgl-dsi/igt@i915_selftest@l...@active.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
[i915#765]: https://gitlab.freedesktop.org/drm/intel/issues/765
Participating hosts (47 -> 39)
--
Additional (1): fi-skl-guc
Missing(9): fi-ilk-m540 fi-hsw-peppy fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-ivb-3770 fi-kbl-7560u fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8154 -> Patchwork_17014
CI-20190529: 20190529
CI_DRM_8154: 937a904e393752c47b8dfdeed993f04fd75af74d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17014: eea643cabc5fb832cbdffe3f04546c82dfd034a6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
eea643cabc5f drm/i915: Move the port sync DP_TP_CTL stuff to the encoder hook
ba9ff9562959 drm/i915: Pass atomic state to encoder hooks
65906b744e8d drm/i915: Do pipe updates after enables for everyone
a85031aa5231 drm/i915: Fix port sync code to work with >2 pipes
ed313611cd9d drm/i915: Eliminate port sync copy pasta
2084e75f8c82 drm/i915: Implement port sync for SKL+
248ad2bd291b drm/i915: Store cpu_transcoder_mask in device info
e832ccd1183a drm/i915: Include port sync state in the state dump
6f316fb900f8 drm/i915: Use REG_FIELD_PREP() & co. for TRANS_DDI_FUNC_CTL2
aebcfc348cec drm/i915: Move icl_get_trans_port_sync_config() into the DDI code
7200689fa007 drm/i915: Drop usless master_transcoder assignments
0124ef44a60a drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it belongs
72dac032db0d drm/i915/mst: Use .compute_config_late() to compute master
transcoder
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17014/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/execlists: Force single submission for sentinels
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Force single submission
for sentinels
URL : https://patchwork.freedesktop.org/series/74845/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8154 -> Patchwork_17013
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17013 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17013, 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_17013/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17013:
### IGT changes ###
Possible regressions
* igt@gem_exec_parallel@contexts:
- fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-skl-lmem/igt@gem_exec_paral...@contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-skl-lmem/igt@gem_exec_paral...@contexts.html
* igt@gem_exec_parallel@fds:
- fi-skl-guc: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-skl-guc/igt@gem_exec_paral...@fds.html
- fi-bdw-5557u: [PASS][4] -> [INCOMPLETE][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-bdw-5557u/igt@gem_exec_paral...@fds.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-bdw-5557u/igt@gem_exec_paral...@fds.html
- fi-kbl-8809g: [PASS][6] -> [INCOMPLETE][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-8809g/igt@gem_exec_paral...@fds.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-kbl-8809g/igt@gem_exec_paral...@fds.html
- fi-kbl-r: [PASS][8] -> [INCOMPLETE][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-r/igt@gem_exec_paral...@fds.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-kbl-r/igt@gem_exec_paral...@fds.html
- fi-kbl-guc: [PASS][10] -> [INCOMPLETE][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-guc/igt@gem_exec_paral...@fds.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-kbl-guc/igt@gem_exec_paral...@fds.html
- fi-kbl-7500u: [PASS][12] -> [INCOMPLETE][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-7500u/igt@gem_exec_paral...@fds.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-kbl-7500u/igt@gem_exec_paral...@fds.html
- fi-kbl-x1275: [PASS][14] -> [INCOMPLETE][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-x1275/igt@gem_exec_paral...@fds.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-kbl-x1275/igt@gem_exec_paral...@fds.html
- fi-skl-6700k2: [PASS][16] -> [INCOMPLETE][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-skl-6700k2/igt@gem_exec_paral...@fds.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-skl-6700k2/igt@gem_exec_paral...@fds.html
* igt@gem_sync@basic-each:
- fi-kbl-soraka: [PASS][18] -> [INCOMPLETE][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-soraka/igt@gem_s...@basic-each.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-kbl-soraka/igt@gem_s...@basic-each.html
* igt@i915_module_load@reload:
- fi-cfl-guc: [PASS][20] -> [INCOMPLETE][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-cfl-guc/igt@i915_module_l...@reload.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-cfl-guc/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gtt:
- fi-skl-6600u: [PASS][22] -> [INCOMPLETE][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-skl-6600u/igt@i915_selftest@l...@gtt.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-skl-6600u/igt@i915_selftest@l...@gtt.html
* igt@i915_selftest@live@workarounds:
- fi-cfl-8700k: [PASS][24] -> [INCOMPLETE][25]
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-cfl-8700k/igt@i915_selftest@l...@workarounds.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17013/fi-cfl-8700k/igt@i915_selftest@l...@workarounds.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_parallel@fds:
- {fi-kbl-7560u}: [PASS][26] -> [INCOMPLETE][27]
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8154/fi-kbl-7560u/igt@gem_exec_paral...@fds.html
[27]:
Re: [Intel-gfx] [PATCH v3] drm/i915/tgl: Add definitions for VRR registers and bits
Thanks for the revised patch, just one nitcpick below:
On Fri, Mar 06, 2020 at 07:42:38PM -0800, Aditya Swarup wrote:
> Add definitions for registers grouped under Transcoder VRR function
> with necessary bitfields.
>
> Bspec: 49268
>
> v2: Use REG_GENMASK, correct tabs/space indentation and move the
> definitions near the transcoder section.(Jani)
>
> v3: Remove unnecessary prefix from bit/mask definitions.(Manasi)
>
> Cc: Manasi Navare
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Matt Roper
> Signed-off-by: Aditya Swarup
> ---
> drivers/gpu/drm/i915/i915_reg.h | 90 +
> 1 file changed, 90 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 80cf02a6eec1..34bda79e8a62 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4321,6 +4321,96 @@ enum {
> #define EXITLINE_MASK REG_GENMASK(12, 0)
> #define EXITLINE_SHIFT 0
>
> +/* VRR registers */
> +#define _TRANS_VRR_CTL_A 0x60420
> +#define _TRANS_VRR_CTL_B 0x61420
> +#define _TRANS_VRR_CTL_C 0x62420
> +#define _TRANS_VRR_CTL_D 0x63420
> +#define TRANS_VRR_CTL(tran) _MMIO_TRANS2(tran, _TRANS_VRR_CTL_A)
For all the _MMIO_TRANS macros, the argument should be names trans like
everywhere else
instead of tran
Applies everywhere below. With that change you can consider:
Reviewed-by: Manasi Navare
Manasi
> +#define VRR_CTL_VRR_ENABLE REG_BIT(31)
> +#define VRR_CTL_IGN_MAX_SHIFT REG_BIT(30)
> +#define VRR_CTL_FLIP_LINE_EN REG_BIT(29)
> +#define VRR_CTL_LINE_COUNT_MASKREG_GENMASK(10, 3)
> +#define VRR_CTL_SW_FULLLINE_COUNT REG_BIT(0)
> +
> +#define _TRANS_VRR_VMAX_A0x60424
> +#define _TRANS_VRR_VMAX_B0x61424
> +#define _TRANS_VRR_VMAX_C0x62424
> +#define _TRANS_VRR_VMAX_D0x63424
> +#define TRANS_VRR_VMAX(tran) _MMIO_TRANS2(tran, _TRANS_VRR_VMAX_A)
> +#define VRR_VMAX_MASK REG_GENMASK(19, 0)
> +
> +#define _TRANS_VRR_VMIN_A0x60434
> +#define _TRANS_VRR_VMIN_B0x61434
> +#define _TRANS_VRR_VMIN_C0x62434
> +#define _TRANS_VRR_VMIN_D0x63434
> +#define TRANS_VRR_VMIN(tran) _MMIO_TRANS2(tran, _TRANS_VRR_VMIN_A)
> +#define VRR_VMIN_MASK REG_GENMASK(15, 0)
> +
> +#define _TRANS_VRR_VMAXSHIFT_A 0x60428
> +#define _TRANS_VRR_VMAXSHIFT_B 0x61428
> +#define _TRANS_VRR_VMAXSHIFT_C 0x62428
> +#define _TRANS_VRR_VMAXSHIFT_D 0x63428
> +#define TRANS_VRR_VMAXSHIFT(tran)_MMIO_TRANS2(tran, \
> + _TRANS_VRR_VMAXSHIFT_A)
> +#define VRR_VMAXSHIFT_DEC_MASK REG_GENMASK(29, 16)
> +#define VRR_VMAXSHIFT_DEC REG_BIT(16)
> +#define VRR_VMAXSHIFT_INC_MASK REG_GENMASK(12, 0)
> +
> +#define _TRANS_VRR_STATUS_A 0x6042C
> +#define _TRANS_VRR_STATUS_B 0x6142C
> +#define _TRANS_VRR_STATUS_C 0x6242C
> +#define _TRANS_VRR_STATUS_D 0x6342C
> +#define TRANS_VRR_STATUS(tran) _MMIO_TRANS2(tran,
> _TRANS_VRR_STATUS_A)
> +#define VRR_STATUS_VMAX_REACHEDREG_BIT(31)
> +#define VRR_STATUS_NOFLIP_TILL_BNDRREG_BIT(30)
> +#define VRR_STATUS_FLIP_BEF_BNDR REG_BIT(29)
> +#define VRR_STATUS_NO_FLIP_FRAME REG_BIT(28)
> +#define VRR_STATUS_VRR_EN_LIVE REG_BIT(27)
> +#define VRR_STATUS_FLIPS_SERVICED REG_BIT(26)
> +#define VRR_STATUS_VBLANK_MASK REG_GENMASK(22, 20)
> +#define STATUS_FSM_IDLEREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
> 0)
> +#define STATUS_FSM_WAIT_TILL_FDB REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
> 1)
> +#define STATUS_FSM_WAIT_TILL_FSREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
> 2)
> +#define STATUS_FSM_WAIT_TILL_FLIP REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
> 3)
> +#define STATUS_FSM_PIPELINE_FILL REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
> 4)
> +#define STATUS_FSM_ACTIVE REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
> 5)
> +#define STATUS_FSM_LEGACY_VBLANK REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
> 6)
> +
> +#define _TRANS_VRR_VTOTAL_PREV_A 0x60480
> +#define _TRANS_VRR_VTOTAL_PREV_B 0x61480
> +#define _TRANS_VRR_VTOTAL_PREV_C 0x62480
> +#define _TRANS_VRR_VTOTAL_PREV_D 0x63480
> +#define TRANS_VRR_VTOTAL_PREV(tran) _MMIO_TRANS2(tran, \
> + _TRANS_VRR_VTOTAL_PREV_A)
> +#define VRR_VTOTAL_FLIP_BEFR_BNDR REG_BIT(31)
> +#define VRR_VTOTAL_FLIP_AFTER_BNDR REG_BIT(30)
> +#define VRR_VTOTAL_FLIP_AFTER_DBLBUF REG_BIT(29)
> +#define VRR_VTOTAL_PREV_FRAME_MASK REG_GENMASK(19, 0)
> +
> +#define _TRANS_VRR_FLIPLINE_A0x60438
> +#define _TRANS_VRR_FLIPLINE_B0x61438
> +#define _TRANS_VRR_FLIPLINE_C0x62438
> +#define _TRANS_VRR_FLIPLINE_D
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Port sync for skl+ (rev3)
== Series Details ==
Series: drm/i915: Port sync for skl+ (rev3)
URL : https://patchwork.freedesktop.org/series/74691/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
72dac032db0d drm/i915/mst: Use .compute_config_late() to compute master
transcoder
0124ef44a60a drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it belongs
7200689fa007 drm/i915: Drop usless master_transcoder assignments
aebcfc348cec drm/i915: Move icl_get_trans_port_sync_config() into the DDI code
6f316fb900f8 drm/i915: Use REG_FIELD_PREP() & co. for TRANS_DDI_FUNC_CTL2
-:55: WARNING:LONG_LINE: line over 100 characters
#55: FILE: drivers/gpu/drm/i915/i915_reg.h:9734:
+#define PORT_SYNC_MODE_MASTER_SELECT(x)
REG_FIELD_PREP(PORT_SYNC_MODE_MASTER_SELECT_MASK, (x))
total: 0 errors, 1 warnings, 0 checks, 34 lines checked
e832ccd1183a drm/i915: Include port sync state in the state dump
248ad2bd291b drm/i915: Store cpu_transcoder_mask in device info
-:96: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#96: FILE: drivers/gpu/drm/i915/display/intel_display.h:323:
+#define for_each_cpu_transcoder(__dev_priv, __t) \
for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
+ for_each_if (INTEL_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
-:96: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible side-effects?
#96: FILE: drivers/gpu/drm/i915/display/intel_display.h:323:
+#define for_each_cpu_transcoder(__dev_priv, __t) \
for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
+ for_each_if (INTEL_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
-:99: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#99: FILE: drivers/gpu/drm/i915/display/intel_display.h:325:
+ for_each_if (INTEL_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
-:101: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#101: FILE: drivers/gpu/drm/i915/display/intel_display.h:327:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+ for_each_cpu_transcoder(__dev_priv, __t) \
+ for_each_if ((__mask) & BIT(__t))
-:101: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible
side-effects?
#101: FILE: drivers/gpu/drm/i915/display/intel_display.h:327:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+ for_each_cpu_transcoder(__dev_priv, __t) \
+ for_each_if ((__mask) & BIT(__t))
-:103: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#103: FILE: drivers/gpu/drm/i915/display/intel_display.h:329:
+ for_each_if ((__mask) & BIT(__t))
-:116: WARNING:LONG_LINE: line over 100 characters
#116: FILE: drivers/gpu/drm/i915/i915_drv.h:1605:
+#define HAS_TRANSCODER(dev_priv, trans)
((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0)
total: 2 errors, 3 warnings, 2 checks, 242 lines checked
2084e75f8c82 drm/i915: Implement port sync for SKL+
-:209: WARNING:LONG_LINE: line over 100 characters
#209: FILE: drivers/gpu/drm/i915/i915_reg.h:9704:
+#define TRANS_DDI_PORT_SYNC_MASTER_SELECT(x)
REG_FIELD_PREP(TRANS_DDI_PORT_SYNC_MASTER_SELECT_MASK, (x))
total: 0 errors, 1 warnings, 0 checks, 165 lines checked
ed313611cd9d drm/i915: Eliminate port sync copy pasta
a85031aa5231 drm/i915: Fix port sync code to work with >2 pipes
65906b744e8d drm/i915: Do pipe updates after enables for everyone
ba9ff9562959 drm/i915: Pass atomic state to encoder hooks
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_atomic_state *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_encoder *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'const struct
intel_crtc_state *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'const struct
drm_connector_state *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:563: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_atomic_state *' should also have an identifier name
#563: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:153:
+ void (*pre_enable)(struct intel_atomic_state *,
-:563: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_encoder *' should also have an identifier name
#563:
Re: [Intel-gfx] [PATCH] drm: Reject dumb buffers when driver/device doesn't support modesetting
On Wed, Mar 18, 2020 at 01:31:07PM -0700, Matt Roper wrote: > On Wed, Mar 18, 2020 at 05:49:59PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Currently a driver must not provide a .dumb_create() hook in the > > drm_driver structure if it wants to declare dumb buffers as not > > supported. So if the same driver wants to support both modeset > > and non-modeset devices it would require two distinct drm_driver > > structures in order to reject the dumb buffer operations on the > > non-modeset devices. That's rather tedious, so let's make life > > easier for such drivers by also checking for the DRIVER_MODESET > > flag before we declare dumb buffers as supported. Now all the > > driver has to do is clear the flag for any device that can't > > do modesetting. > > Will this be a problem for vgem? I thought it exposed dumb buffers > without modesetting support? Well that's disappointing. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Reject dumb buffers when driver/device doesn't support modesetting
On Wed, Mar 18, 2020 at 05:49:59PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently a driver must not provide a .dumb_create() hook in the
> drm_driver structure if it wants to declare dumb buffers as not
> supported. So if the same driver wants to support both modeset
> and non-modeset devices it would require two distinct drm_driver
> structures in order to reject the dumb buffer operations on the
> non-modeset devices. That's rather tedious, so let's make life
> easier for such drivers by also checking for the DRIVER_MODESET
> flag before we declare dumb buffers as supported. Now all the
> driver has to do is clear the flag for any device that can't
> do modesetting.
Will this be a problem for vgem? I thought it exposed dumb buffers
without modesetting support?
Matt
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_client.c| 2 +-
> drivers/gpu/drm/drm_crtc_internal.h | 1 +
> drivers/gpu/drm/drm_dumb_buffers.c | 12 +---
> drivers/gpu/drm/drm_ioctl.c | 2 +-
> 4 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 6b0c6ef8b9b3..cf61d87b434d 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -80,7 +80,7 @@ int drm_client_init(struct drm_device *dev, struct
> drm_client_dev *client,
> {
> int ret;
>
> - if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> !dev->driver->dumb_create)
> + if (!drm_has_dumb_buffers(dev))
> return -EOPNOTSUPP;
>
> if (funcs && !try_module_get(funcs->owner))
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 16f2413403aa..c08ff0b7a509 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -92,6 +92,7 @@ int drm_mode_getresources(struct drm_device *dev,
>
>
> /* drm_dumb_buffers.c */
> +bool drm_has_dumb_buffers(struct drm_device *dev);
> int drm_mode_create_dumb(struct drm_device *dev,
>struct drm_mode_create_dumb *args,
>struct drm_file *file_priv);
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> b/drivers/gpu/drm/drm_dumb_buffers.c
> index d18a740fe0f1..9859530362e2 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -55,13 +55,19 @@
> * a hardware-specific ioctl to allocate suitable buffer objects.
> */
>
> +bool drm_has_dumb_buffers(struct drm_device *dev)
> +{
> + return dev->driver->dumb_create &&
> + drm_core_check_feature(dev, DRIVER_MODESET);
> +}
> +
> int drm_mode_create_dumb(struct drm_device *dev,
>struct drm_mode_create_dumb *args,
>struct drm_file *file_priv)
> {
> u32 cpp, stride, size;
>
> - if (!dev->driver->dumb_create)
> + if (!drm_has_dumb_buffers(dev))
> return -ENOSYS;
> if (!args->width || !args->height || !args->bpp)
> return -EINVAL;
> @@ -119,7 +125,7 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
> {
> struct drm_mode_map_dumb *args = data;
>
> - if (!dev->driver->dumb_create)
> + if (!drm_has_dumb_buffers(dev))
> return -ENOSYS;
>
> if (dev->driver->dumb_map_offset)
> @@ -134,7 +140,7 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
> int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
> struct drm_file *file_priv)
> {
> - if (!dev->driver->dumb_create)
> + if (!drm_has_dumb_buffers(dev))
> return -ENOSYS;
>
> if (dev->driver->dumb_destroy)
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 9e41972c4bbc..437f1bee6869 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -262,7 +262,7 @@ static int drm_getcap(struct drm_device *dev, void *data,
> struct drm_file *file_
>
> switch (req->capability) {
> case DRM_CAP_DUMB_BUFFER:
> - if (dev->driver->dumb_create)
> + if (drm_has_dumb_buffers(dev))
> req->value = 1;
> break;
> case DRM_CAP_VBLANK_HIGH_CRTC:
> --
> 2.24.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add new PCI IDs to TGL
On Tue, Mar 17, 2020 at 01:12:04PM -0700, Swathi Dhanavanthri wrote: > Adding 4 new PCI IDs to TGL > Bspec: 44455 > > Signed-off-by: Swathi Dhanavanthri > --- > include/drm/i915_pciids.h | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index 1d2c12219f44..c299e26c99c5 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -599,6 +599,10 @@ > INTEL_VGA_DEVICE(0x9A60, info), \ > INTEL_VGA_DEVICE(0x9A68, info), \ > INTEL_VGA_DEVICE(0x9A70, info), \ > - INTEL_VGA_DEVICE(0x9A78, info) > + INTEL_VGA_DEVICE(0x9A78, info), \ > + INTEL_VGA_DEVICE(0x9AC9, info), \ > + INTEL_VGA_DEVICE(0x9AF8, info), \ > + INTEL_VGA_DEVICE(0x9AC0, info), \ > + INTEL_VGA_DEVICE(0x9AD9, info) I'd reorder these new ID's to keep the overall list sorted by ID, but aside from that, Reviewed-by: Matt Roper > > #endif /* _I915_PCIIDS_H */ > -- > 2.20.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] cpufreq: intel_pstate: Implement VLP controller for HWP parts.
"Pandruvada, Srinivas" writes:
> On Wed, 2020-03-18 at 12:51 -0700, Francisco Jerez wrote:
>> "Pandruvada, Srinivas" writes:
>>
>> > On Tue, 2020-03-10 at 14:42 -0700, Francisco Jerez wrote:
>> > > This implements a simple variably low-pass-filtering governor in
>> > > control of the HWP MIN/MAX PERF range based on the previously
>> > > introduced get_vlp_target_range(). See "cpufreq: intel_pstate:
>> > > Implement VLP controller target P-state range estimation." for
>> > > the
>> > > rationale.
>> >
>> > I just gave a try on a pretty idle system with just systemd
>> > processes
>> > and usual background tasks with nomodset.
>> >
>> > I see that there HWP min is getting changed between 4-8. Why are
>> > changing HWP dynamic range even on an idle system running no where
>> > close to TDP?
>> >
>>
>> The HWP request range is clamped to the frequency range specified by
>> the
>> CPUFREQ policy and to the cpu->pstate.min_pstate bound.
>>
>> If you see the HWP minimum fluctuating above that it's likely a sign
>> of
>> your system not being completely idle -- If that's the case it's
>> likely
>> to go away after you do:
>>
>> echo 0 > /sys/kernel/debug/pstate_snb/vlp_realtime_gain_pml
>>
> The objective which I though was to improve performance of GPU
> workloads limited by TDP because of P-states ramping up and resulting
> in less power to GPU to complete a task.
>
> HWP takes decision not on just load on a CPU but several other factors
> like total SoC power and scalability. We don't want to disturb HWP
> algorithms when there is no TDP limitations. If writing 0, causes this
> behavior then that should be the default.
>
The heuristic disabled by that debugfs file is there to avoid
regressions in latency-sensitive workloads as you can probably get from
the ecomments. However ISTR those regressions were specific to non-HWP
systems, so I wouldn't mind disabling it for the moment (or punting it
to the non-HWP series if you like)j. But first I need to verify that
there are no performance regressions on HWP systems after changing that.
Can you confirm that the debugfs write above prevents the behavior you'd
like to avoid?
> Thanks,
> Srinivas
>
>
>
>
>
>> > Thanks,
>> > Srinivas
>> >
>> >
>> > > Signed-off-by: Francisco Jerez
>> > > ---
>> > > drivers/cpufreq/intel_pstate.c | 79
>> > > +-
>> > > 1 file changed, 77 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/drivers/cpufreq/intel_pstate.c
>> > > b/drivers/cpufreq/intel_pstate.c
>> > > index cecadfec8bc1..a01eed40d897 100644
>> > > --- a/drivers/cpufreq/intel_pstate.c
>> > > +++ b/drivers/cpufreq/intel_pstate.c
>> > > @@ -1905,6 +1905,20 @@ static void intel_pstate_reset_vlp(struct
>> > > cpudata *cpu)
>> > > vlp->gain = max(1, div_fp(1000, vlp_params.setpoint_0_pml));
>> > > vlp->target.p_base = 0;
>> > > vlp->stats.last_response_frequency_hz = vlp_params.avg_hz;
>> > > +
>> > > +if (hwp_active) {
>> > > +const uint32_t p0 = max(cpu->pstate.min_pstate,
>> > > +cpu->min_perf_ratio);
>> > > +const uint32_t p1 = max_t(uint32_t, p0, cpu-
>> > > > max_perf_ratio);
>> > > +const uint64_t hwp_req = (READ_ONCE(cpu-
>> > > > hwp_req_cached) &
>> > > + ~(HWP_MAX_PERF(~0L) |
>> > > +HWP_MIN_PERF(~0L) |
>> > > +HWP_DESIRED_PERF(~0L))) |
>> > > + HWP_MIN_PERF(p0) |
>> > > HWP_MAX_PERF(p1);
>> > > +
>> > > +wrmsrl_on_cpu(cpu->cpu, MSR_HWP_REQUEST, hwp_req);
>> > > +cpu->hwp_req_cached = hwp_req;
>> > > +}
>> > > }
>> > >
>> > > /**
>> > > @@ -,6 +2236,46 @@ static void
>> > > intel_pstate_adjust_pstate(struct
>> > > cpudata *cpu)
>> > > fp_toint(cpu->iowait_boost * 100));
>> > > }
>> > >
>> > > +static void intel_pstate_adjust_pstate_range(struct cpudata
>> > > *cpu,
>> > > + const unsigned int
>> > > range[])
>> > > +{
>> > > +const int from = cpu->hwp_req_cached;
>> > > +unsigned int p0, p1, p_min, p_max;
>> > > +struct sample *sample;
>> > > +uint64_t hwp_req;
>> > > +
>> > > +update_turbo_state();
>> > > +
>> > > +p0 = max(cpu->pstate.min_pstate, cpu->min_perf_ratio);
>> > > +p1 = max_t(unsigned int, p0, cpu->max_perf_ratio);
>> > > +p_min = clamp_t(unsigned int, range[0], p0, p1);
>> > > +p_max = clamp_t(unsigned int, range[1], p0, p1);
>> > > +
>> > > +trace_cpu_frequency(p_max * cpu->pstate.scaling, cpu->cpu);
>> > > +
>> > > +hwp_req = (READ_ONCE(cpu->hwp_req_cached) &
>> > > + ~(HWP_MAX_PERF(~0L) | HWP_MIN_PERF(~0L) |
>> > > + HWP_DESIRED_PERF(~0L))) |
>> > > +
Re: [Intel-gfx] [PATCH 07/10] cpufreq: intel_pstate: Implement VLP controller for HWP parts.
On Wed, 2020-03-18 at 12:51 -0700, Francisco Jerez wrote:
> "Pandruvada, Srinivas" writes:
>
> > On Tue, 2020-03-10 at 14:42 -0700, Francisco Jerez wrote:
> > > This implements a simple variably low-pass-filtering governor in
> > > control of the HWP MIN/MAX PERF range based on the previously
> > > introduced get_vlp_target_range(). See "cpufreq: intel_pstate:
> > > Implement VLP controller target P-state range estimation." for
> > > the
> > > rationale.
> >
> > I just gave a try on a pretty idle system with just systemd
> > processes
> > and usual background tasks with nomodset.
> >
> > I see that there HWP min is getting changed between 4-8. Why are
> > changing HWP dynamic range even on an idle system running no where
> > close to TDP?
> >
>
> The HWP request range is clamped to the frequency range specified by
> the
> CPUFREQ policy and to the cpu->pstate.min_pstate bound.
>
> If you see the HWP minimum fluctuating above that it's likely a sign
> of
> your system not being completely idle -- If that's the case it's
> likely
> to go away after you do:
>
> echo 0 > /sys/kernel/debug/pstate_snb/vlp_realtime_gain_pml
>
The objective which I though was to improve performance of GPU
workloads limited by TDP because of P-states ramping up and resulting
in less power to GPU to complete a task.
HWP takes decision not on just load on a CPU but several other factors
like total SoC power and scalability. We don't want to disturb HWP
algorithms when there is no TDP limitations. If writing 0, causes this
behavior then that should be the default.
Thanks,
Srinivas
> > Thanks,
> > Srinivas
> >
> >
> > > Signed-off-by: Francisco Jerez
> > > ---
> > > drivers/cpufreq/intel_pstate.c | 79
> > > +-
> > > 1 file changed, 77 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/cpufreq/intel_pstate.c
> > > b/drivers/cpufreq/intel_pstate.c
> > > index cecadfec8bc1..a01eed40d897 100644
> > > --- a/drivers/cpufreq/intel_pstate.c
> > > +++ b/drivers/cpufreq/intel_pstate.c
> > > @@ -1905,6 +1905,20 @@ static void intel_pstate_reset_vlp(struct
> > > cpudata *cpu)
> > > vlp->gain = max(1, div_fp(1000, vlp_params.setpoint_0_pml));
> > > vlp->target.p_base = 0;
> > > vlp->stats.last_response_frequency_hz = vlp_params.avg_hz;
> > > +
> > > + if (hwp_active) {
> > > + const uint32_t p0 = max(cpu->pstate.min_pstate,
> > > + cpu->min_perf_ratio);
> > > + const uint32_t p1 = max_t(uint32_t, p0, cpu-
> > > > max_perf_ratio);
> > > + const uint64_t hwp_req = (READ_ONCE(cpu-
> > > > hwp_req_cached) &
> > > + ~(HWP_MAX_PERF(~0L) |
> > > + HWP_MIN_PERF(~0L) |
> > > + HWP_DESIRED_PERF(~0L))) |
> > > + HWP_MIN_PERF(p0) |
> > > HWP_MAX_PERF(p1);
> > > +
> > > + wrmsrl_on_cpu(cpu->cpu, MSR_HWP_REQUEST, hwp_req);
> > > + cpu->hwp_req_cached = hwp_req;
> > > + }
> > > }
> > >
> > > /**
> > > @@ -,6 +2236,46 @@ static void
> > > intel_pstate_adjust_pstate(struct
> > > cpudata *cpu)
> > > fp_toint(cpu->iowait_boost * 100));
> > > }
> > >
> > > +static void intel_pstate_adjust_pstate_range(struct cpudata
> > > *cpu,
> > > + const unsigned int
> > > range[])
> > > +{
> > > + const int from = cpu->hwp_req_cached;
> > > + unsigned int p0, p1, p_min, p_max;
> > > + struct sample *sample;
> > > + uint64_t hwp_req;
> > > +
> > > + update_turbo_state();
> > > +
> > > + p0 = max(cpu->pstate.min_pstate, cpu->min_perf_ratio);
> > > + p1 = max_t(unsigned int, p0, cpu->max_perf_ratio);
> > > + p_min = clamp_t(unsigned int, range[0], p0, p1);
> > > + p_max = clamp_t(unsigned int, range[1], p0, p1);
> > > +
> > > + trace_cpu_frequency(p_max * cpu->pstate.scaling, cpu->cpu);
> > > +
> > > + hwp_req = (READ_ONCE(cpu->hwp_req_cached) &
> > > +~(HWP_MAX_PERF(~0L) | HWP_MIN_PERF(~0L) |
> > > + HWP_DESIRED_PERF(~0L))) |
> > > + HWP_MIN_PERF(vlp_params.debug & 2 ? p0 : p_min) |
> > > + HWP_MAX_PERF(vlp_params.debug & 4 ? p1 : p_max);
> > > +
> > > + if (hwp_req != cpu->hwp_req_cached) {
> > > + wrmsrl(MSR_HWP_REQUEST, hwp_req);
> > > + cpu->hwp_req_cached = hwp_req;
> > > + }
> > > +
> > > + sample = >sample;
> > > + trace_pstate_sample(mul_ext_fp(100, sample->core_avg_perf),
> > > + fp_toint(sample->busy_scaled),
> > > + from,
> > > + hwp_req,
> > > + sample->mperf,
> > > + sample->aperf,
> > > + sample->tsc,
> > > + get_avg_frequency(cpu),
> > > + fp_toint(cpu->iowait_boost * 100));
> > > +}
> > > +
> > > static void intel_pstate_update_util(struct update_util_data
> > > *data,
> > > u64 time,
> > >
Re: [Intel-gfx] [PATCH v6 6/7] drm/i915/dp: Register definition for DP compliance register
On Wed, Mar 18, 2020 at 12:05:14PM +0530, Animesh Manna wrote:
> DP_COMP_CTL and DP_COMP_PAT register used to program DP
> compliance pattern.
>
> v1: Initial patch.
> v2: used pipe instead of port in macro definition. [Manasi]
> v3: used trans_offset for offset calculation. [Manasi]
>
> Reviewed-by: Manasi Navare
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/i915_reg.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 309cb7d96b35..8b6c9fbfe74b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9792,6 +9792,22 @@ enum skl_power_gate {
> #define DDI_BUF_BALANCE_LEG_ENABLE (1 << 31)
> #define DDI_BUF_TRANS_HI(port, i)_MMIO(_PORT(port, _DDI_BUF_TRANS_A,
> _DDI_BUF_TRANS_B) + (i) * 8 + 4)
>
> +/* DDI DP Compliance Control */
> +#define _DDI_DP_COMP_CTL_A 0x605F0
> +#define DDI_DP_COMP_CTL(pipe)_MMIO_TRANS2(pipe,
> _DDI_DP_COMP_CTL_A)
Any reason why you couldnt use _MMIO_PIPE2 ?
> +#define DDI_DP_COMP_CTL_ENABLE (1 << 31)
> +#define DDI_DP_COMP_CTL_D10_2 (0 << 28)
> +#define DDI_DP_COMP_CTL_SCRAMBLED_0(1 << 28)
> +#define DDI_DP_COMP_CTL_PRBS7 (2 << 28)
> +#define DDI_DP_COMP_CTL_CUSTOM80 (3 << 28)
> +#define DDI_DP_COMP_CTL_HBR2 (4 << 28)
> +#define DDI_DP_COMP_CTL_SCRAMBLED_1(5 << 28)
> +#define DDI_DP_COMP_CTL_HBR2_RESET (0xFC << 0)
> +
> +/* DDI DP Compliance Pattern */
> +#define _DDI_DP_COMP_PAT_A 0x605F4
> +#define DDI_DP_COMP_PAT(pipe, i) _MMIO(_TRANS2(pipe,
> _DDI_DP_COMP_PAT_A) + (i) * 4)
Why cant you use a simple _MMIO_PIPE2(pipe, _DDI_DP_COMP_PAT_A) ?
The offsets are same as the DP_COMP_CTL
Manasi
> +
> /* Sideband Interface (SBI) is programmed indirectly, via
> * SBI_ADDR, which contains the register offset; and SBI_DATA,
> * which contains the payload */
> --
> 2.24.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Skip drm_mode_config_validate() for !modeset
On Wed, Mar 18, 2020 at 06:31:16PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-03-18 18:25:18)
> > From: Ville Syrjälä
> >
> > drm_mode_config_init() may not have been called when the driver/device
> > doesn't support modeset. That will cause drm_mode_config_validate()
> > to oops. Skip the validation for !modeset.
> >
> > TODO: We may want to consider calling drm_mode_config_init()
> > unconditionally to avoid similar issues elsewhere...
> >
> > Fixes: 74d2aacbe840 ("drm: Validate encoder->possible_clones")
> > Signed-off-by: Ville Syrjälä
> Reviewed-by: Chris Wilson
Thanks. Looks like this gets BAT up and running again so pushing w/o
waiting for shards.
Sorry about the mess everyone. CI had turned a blind eye on the
regressing series and I didn't notice that fact. I need to adjust my
brain regex to look for *all* CI mails, not just the failures.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/10] cpufreq: intel_pstate: Implement VLP controller for HWP parts.
"Pandruvada, Srinivas" writes:
> On Tue, 2020-03-10 at 14:42 -0700, Francisco Jerez wrote:
>> This implements a simple variably low-pass-filtering governor in
>> control of the HWP MIN/MAX PERF range based on the previously
>> introduced get_vlp_target_range(). See "cpufreq: intel_pstate:
>> Implement VLP controller target P-state range estimation." for the
>> rationale.
>
> I just gave a try on a pretty idle system with just systemd processes
> and usual background tasks with nomodset.
>
> I see that there HWP min is getting changed between 4-8. Why are
> changing HWP dynamic range even on an idle system running no where
> close to TDP?
>
The HWP request range is clamped to the frequency range specified by the
CPUFREQ policy and to the cpu->pstate.min_pstate bound.
If you see the HWP minimum fluctuating above that it's likely a sign of
your system not being completely idle -- If that's the case it's likely
to go away after you do:
echo 0 > /sys/kernel/debug/pstate_snb/vlp_realtime_gain_pml
> Thanks,
> Srinivas
>
>
>>
>> Signed-off-by: Francisco Jerez
>> ---
>> drivers/cpufreq/intel_pstate.c | 79
>> +-
>> 1 file changed, 77 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/cpufreq/intel_pstate.c
>> b/drivers/cpufreq/intel_pstate.c
>> index cecadfec8bc1..a01eed40d897 100644
>> --- a/drivers/cpufreq/intel_pstate.c
>> +++ b/drivers/cpufreq/intel_pstate.c
>> @@ -1905,6 +1905,20 @@ static void intel_pstate_reset_vlp(struct
>> cpudata *cpu)
>> vlp->gain = max(1, div_fp(1000, vlp_params.setpoint_0_pml));
>> vlp->target.p_base = 0;
>> vlp->stats.last_response_frequency_hz = vlp_params.avg_hz;
>> +
>> +if (hwp_active) {
>> +const uint32_t p0 = max(cpu->pstate.min_pstate,
>> +cpu->min_perf_ratio);
>> +const uint32_t p1 = max_t(uint32_t, p0, cpu-
>> >max_perf_ratio);
>> +const uint64_t hwp_req = (READ_ONCE(cpu-
>> >hwp_req_cached) &
>> + ~(HWP_MAX_PERF(~0L) |
>> +HWP_MIN_PERF(~0L) |
>> +HWP_DESIRED_PERF(~0L))) |
>> + HWP_MIN_PERF(p0) |
>> HWP_MAX_PERF(p1);
>> +
>> +wrmsrl_on_cpu(cpu->cpu, MSR_HWP_REQUEST, hwp_req);
>> +cpu->hwp_req_cached = hwp_req;
>> +}
>> }
>>
>> /**
>> @@ -,6 +2236,46 @@ static void intel_pstate_adjust_pstate(struct
>> cpudata *cpu)
>> fp_toint(cpu->iowait_boost * 100));
>> }
>>
>> +static void intel_pstate_adjust_pstate_range(struct cpudata *cpu,
>> + const unsigned int
>> range[])
>> +{
>> +const int from = cpu->hwp_req_cached;
>> +unsigned int p0, p1, p_min, p_max;
>> +struct sample *sample;
>> +uint64_t hwp_req;
>> +
>> +update_turbo_state();
>> +
>> +p0 = max(cpu->pstate.min_pstate, cpu->min_perf_ratio);
>> +p1 = max_t(unsigned int, p0, cpu->max_perf_ratio);
>> +p_min = clamp_t(unsigned int, range[0], p0, p1);
>> +p_max = clamp_t(unsigned int, range[1], p0, p1);
>> +
>> +trace_cpu_frequency(p_max * cpu->pstate.scaling, cpu->cpu);
>> +
>> +hwp_req = (READ_ONCE(cpu->hwp_req_cached) &
>> + ~(HWP_MAX_PERF(~0L) | HWP_MIN_PERF(~0L) |
>> + HWP_DESIRED_PERF(~0L))) |
>> + HWP_MIN_PERF(vlp_params.debug & 2 ? p0 : p_min) |
>> + HWP_MAX_PERF(vlp_params.debug & 4 ? p1 : p_max);
>> +
>> +if (hwp_req != cpu->hwp_req_cached) {
>> +wrmsrl(MSR_HWP_REQUEST, hwp_req);
>> +cpu->hwp_req_cached = hwp_req;
>> +}
>> +
>> +sample = >sample;
>> +trace_pstate_sample(mul_ext_fp(100, sample->core_avg_perf),
>> +fp_toint(sample->busy_scaled),
>> +from,
>> +hwp_req,
>> +sample->mperf,
>> +sample->aperf,
>> +sample->tsc,
>> +get_avg_frequency(cpu),
>> +fp_toint(cpu->iowait_boost * 100));
>> +}
>> +
>> static void intel_pstate_update_util(struct update_util_data *data,
>> u64 time,
>> unsigned int flags)
>> {
>> @@ -2260,6 +2314,22 @@ static void intel_pstate_update_util(struct
>> update_util_data *data, u64 time,
>> intel_pstate_adjust_pstate(cpu);
>> }
>>
>> +/**
>> + * Implementation of the cpufreq update_util hook based on the VLP
>> + * controller (see get_vlp_target_range()).
>> + */
>> +static void intel_pstate_update_util_hwp_vlp(struct update_util_data
>> *data,
>> + u64 time, unsigned int
>> flags)
>> +{
>> +struct cpudata *cpu = container_of(data, struct cpudata,
>> update_util);
>> +
>> +if (update_vlp_sample(cpu, time, flags)) {
>> +const struct vlp_target_range *target =
>> +
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Adjust PM QoS response frequency based on GPU load.
Francisco Jerez writes:
> Chris Wilson writes:
>
>> Quoting Francisco Jerez (2020-03-10 21:41:55)
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> index b9b3f78f1324..a5d7a80b826d 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
>>> @@ -1577,6 +1577,11 @@ static void execlists_submit_ports(struct
>>> intel_engine_cs *engine)
>>> /* we need to manually load the submit queue */
>>> if (execlists->ctrl_reg)
>>> writel(EL_CTRL_LOAD, execlists->ctrl_reg);
>>> +
>>> + if (execlists_num_ports(execlists) > 1 &&
>> pending[1] is always defined, the minimum submission is one slot, with
>> pending[1] as the sentinel NULL.
>>
>>> + execlists->pending[1] &&
>>> + !atomic_xchg(>overload, 1))
>>> + intel_gt_pm_active_begin(>i915->gt);
>>
>> engine->gt
>>
>
> Applied your suggestions above locally, will probably wait to have a few
> more changes batched up before sending a v2.
>
>>> }
>>>
>>> static bool ctx_single_port_submission(const struct intel_context *ce)
>>> @@ -2213,6 +2218,12 @@ cancel_port_requests(struct intel_engine_execlists *
>>> const execlists)
>>> clear_ports(execlists->inflight, ARRAY_SIZE(execlists->inflight));
>>>
>>> WRITE_ONCE(execlists->active, execlists->inflight);
>>> +
>>> + if (atomic_xchg(>overload, 0)) {
>>> + struct intel_engine_cs *engine =
>>> + container_of(execlists, typeof(*engine), execlists);
>>> + intel_gt_pm_active_end(>i915->gt);
>>> + }
>>> }
>>>
>>> static inline void
>>> @@ -2386,6 +2397,9 @@ static void process_csb(struct intel_engine_cs
>>> *engine)
>>> /* port0 completed, advanced to port1 */
>>> trace_ports(execlists, "completed",
>>> execlists->active);
>>>
>>> + if (atomic_xchg(>overload, 0))
>>> + intel_gt_pm_active_end(>i915->gt);
>>
>> So this looses track if we preempt a dual-ELSP submission with a
>> single-ELSP submission (and never go back to dual).
>>
>
> Yes, good point. You're right that if a dual-ELSP submission gets
> preempted by a single-ELSP submission "overload" will remain signaled
> until the first completion interrupt arrives (e.g. from the preempting
> submission).
>
>> If you move this to the end of the loop and check
>>
>> if (!execlists->active[1] && atomic_xchg(>overload, 0))
>> intel_gt_pm_active_end(engine->gt);
>>
>> so that it covers both preemption/promotion and completion.
>>
>
> That sounds reasonable.
>
>> However, that will fluctuate quite rapidly. (And runs the risk of
>> exceeding the sentinel.)
>>
>> An alternative approach would be to couple along
>> schedule_in/schedule_out
>>
>> atomic_set(overload, -1);
>>
>> __execlists_schedule_in:
>> if (!atomic_fetch_inc(overload)
>> intel_gt_pm_active_begin(engine->gt);
>> __execlists_schedule_out:
>> if (!atomic_dec_return(overload)
>> intel_gt_pm_active_end(engine->gt);
>>
>> which would mean we are overloaded as soon as we try to submit an
>> overlapping ELSP.
>>
>
> That sounds good to me too, and AFAICT would have roughly the same
> behavior as this metric except for the preemption corner case you
> mention above. I'll try this and verify that I get approximately the
> same performance numbers.
>
This suggestion seems to lead to some minor regressions, I'm
investigating the issue. Will send a v2 as soon as I have something
along the lines of what you suggested running with equivalent
performance to v1.
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Skip drm_mode_config_validate() for !modeset
== Series Details ==
Series: drm: Skip drm_mode_config_validate() for !modeset
URL : https://patchwork.freedesktop.org/series/74843/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8152 -> Patchwork_17012
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17012 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17012, 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_17012/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17012:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_timelines:
- fi-bwr-2160:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-bwr-2160/igt@i915_selftest@live@gt_timelines.html
Known issues
Here are the changes found in Patchwork_17012 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_fence@basic-busy@rcs0:
- fi-blb-e6850: [DMESG-WARN][2] -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-blb-e6850/igt@gem_exec_fence@basic-b...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-blb-e6850/igt@gem_exec_fence@basic-b...@rcs0.html
- fi-pnv-d510:[DMESG-WARN][4] -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-pnv-d510/igt@gem_exec_fence@basic-b...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-pnv-d510/igt@gem_exec_fence@basic-b...@rcs0.html
* igt@gem_exec_fence@basic-busy@vcs0:
- fi-ivb-3770:[DMESG-WARN][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-ivb-3770/igt@gem_exec_fence@basic-b...@vcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-ivb-3770/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-elk-e7500: [DMESG-WARN][8] -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-elk-e7500/igt@gem_exec_fence@basic-b...@vcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-elk-e7500/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-ilk-650: [DMESG-WARN][10] -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-ilk-650/igt@gem_exec_fence@basic-b...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-ilk-650/igt@gem_exec_fence@basic-b...@vcs0.html
- fi-byt-j1900: [DMESG-WARN][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-byt-j1900/igt@gem_exec_fence@basic-b...@vcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-byt-j1900/igt@gem_exec_fence@basic-b...@vcs0.html
* igt@gem_exec_fence@basic-busy@vecs0:
- fi-apl-guc: [DMESG-WARN][14] -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-apl-guc/igt@gem_exec_fence@basic-b...@vecs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-apl-guc/igt@gem_exec_fence@basic-b...@vecs0.html
- {fi-tgl-u}: [DMESG-WARN][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-tgl-u/igt@gem_exec_fence@basic-b...@vecs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-tgl-u/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-bxt-dsi: [DMESG-WARN][18] -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-bxt-dsi/igt@gem_exec_fence@basic-b...@vecs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-bxt-dsi/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-skl-6700k2: [DMESG-WARN][20] -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-skl-6700k2/igt@gem_exec_fence@basic-b...@vecs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-skl-6700k2/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-cfl-8700k: [DMESG-WARN][22] -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-cfl-8700k/igt@gem_exec_fence@basic-b...@vecs0.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-cfl-8700k/igt@gem_exec_fence@basic-b...@vecs0.html
- fi-icl-guc: [DMESG-WARN][24] -> [PASS][25]
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8152/fi-icl-guc/igt@gem_exec_fence@basic-b...@vecs0.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17012/fi-icl-guc/igt@gem_exec_fence@basic-b...@vecs0.html
- {fi-ehl-1}: [DMESG-WARN][26] -> [PASS][27]
[26]:
Re: [Intel-gfx] [PATCH] drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v3)
On Mon, 16 Mar 2020, Mario Kleiner wrote:
> This fixes a problem found on the MacBookPro 2017 Retina panel.
>
> The panel reports 10 bpc color depth in its EDID, and the
> firmware chooses link settings at boot which support enough
> bandwidth for 10 bpc (324000 kbit/sec = multiplier 0xc),
> but the DP_MAX_LINK_RATE dpcd register only reports
> 2.7 Gbps (multiplier value 0xa) as possible, in direct
> contradiction of what the firmware successfully set up.
>
> This restricts the panel to 8 bpc, not providing the full
> color depth of the panel.
>
> This patch adds a quirk specific to the MBP 2017 15" Retina
> panel to add the additiional 324000 kbps link rate during
> edp setup.
>
> Link to previous discussion of a different attempted fix
> with Ville and Jani:
>
> https://patchwork.kernel.org/patch/11325935/
>
> v2: Follow Jani's proposal of defining quirk_rates[] instead
> of just appending 324000. This for better clarity.
>
> v3: Rebased onto current drm-tip, as of 16-March-2020. Adapt
> to new edid_quirks parameter of drm_dp_has_quirk().
>
> Signed-off-by: Mario Kleiner
> Tested-by: Mario Kleiner
> Cc: Jani Nikula
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
> include/drm/drm_dp_helper.h | 7 +++
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index c6fbe6e6bc9d..8ba4531e808d 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1238,6 +1238,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
> { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
> false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
> /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
> { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
> + /* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
> DP_MAX_LINK_RATE */
> + { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
> BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
> };
>
> #undef OUI
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0a417cd2af2b..ef2e06e292d5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -164,6 +164,17 @@ static void intel_dp_set_sink_rates(struct intel_dp
> *intel_dp)
> };
> int i, max_rate;
>
> + if (drm_dp_has_quirk(_dp->desc, 0,
> + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
> + /* Needed, e.g., for Apple MBP 2017, 15 inch eDP Retina panel */
> + static const int quirk_rates[] = { 162000, 27, 324000 };
> +
> + memcpy(intel_dp->sink_rates, quirk_rates, sizeof(quirk_rates));
> + intel_dp->num_sink_rates = ARRAY_SIZE(quirk_rates);
> +
> + return;
> + }
> +
> max_rate =
> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>
> for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c6119e4c169a..9d87cdf2740a 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1548,6 +1548,13 @@ enum drm_dp_quirk {
>* capabilities advertised.
>*/
> DP_QUIRK_FORCE_DPCD_BACKLIGHT,
> + /**
> + * @DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS:
> + *
> + * The device supports a link rate of 3.24 Gbps (multiplier 0xc) despite
> + * the DP_MAX_LINK_RATE register reporting a lower max multiplier.
> + */
> + DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
> };
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] drm/i915/display: conversion to drm_device based logging macros
On Wed, 11 Mar 2020, Wambui Karuga wrote: > On Wed, 11 Mar 2020, Jani Nikula wrote: > >> On Mon, 09 Mar 2020, Jani Nikula wrote: >>> Please ignore this, I seem to have some smtp trouble which fails some of >>> tha patches. This will be incomplete. >>> >>> Wambui, I'll resend this later. >> >> Okay, I sent them with the same message-ids, so the patches amended this >> beginning of the series. >> >> I pushed all the patches that I didn't change. Please double check the >> below patches that I adjusted, so I can push them. >> drm/i915/fbc: convert to drm_device based logging macros. drm/i915/fbdev: convert to drm_device based logging. drm/i915/hdcp: convert to struct drm_device based logging. >> > > Will do, thanks! Thanks for the reviews, I've pushed the remaining patches. BR, Jani. > wambui karuga >> Thanks, >> Jani. >> >> -- >> Jani Nikula, Intel Open Source Graphics Center >> -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Use 64-bit division macro
On Tue, 17 Mar 2020, Guru Das Srinagesh wrote: > Since the PWM framework is switching struct pwm_state.duty_cycle's > datatype to u64, prepare for this transition by using DIV_ROUND_UP_ULL > to handle a 64-bit dividend. > > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: David Airlie > Cc: Daniel Vetter > Cc: Chris Wilson > Cc: "Ville Syrjälä" > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: Rodrigo Vivi > Cc: Maarten Lankhorst > > Signed-off-by: Guru Das Srinagesh Reviewed-by: Jani Nikula Also ack for merging this via whichever tree you prefer; please let me know if you want me to take this via drm-intel. > --- > drivers/gpu/drm/i915/display/intel_panel.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_panel.c > b/drivers/gpu/drm/i915/display/intel_panel.c > index bc14e9c..843cac1 100644 > --- a/drivers/gpu/drm/i915/display/intel_panel.c > +++ b/drivers/gpu/drm/i915/display/intel_panel.c > @@ -1868,7 +1868,7 @@ static int pwm_setup_backlight(struct intel_connector > *connector, > > panel->backlight.min = 0; /* 0% */ > panel->backlight.max = 100; /* 100% */ > - panel->backlight.level = DIV_ROUND_UP( > + panel->backlight.level = DIV_ROUND_UP_ULL( >pwm_get_duty_cycle(panel->backlight.pwm) * 100, >CRC_PMIC_PWM_PERIOD_NS); > panel->backlight.enabled = panel->backlight.level != 0; -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Port sync for skl+ (rev2)
== Series Details == Series: drm/i915: Port sync for skl+ (rev2) URL : https://patchwork.freedesktop.org/series/74691/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8152 -> Patchwork_17011 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17011 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17011, 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_17011/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17011: ### IGT changes ### Possible regressions * igt@gem_exec_fence@basic-busy@vecs0: - fi-cml-u2: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17011/fi-cml-u2/igt@gem_exec_fence@basic-b...@vecs0.html - fi-skl-6600u: NOTRUN -> [DMESG-WARN][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17011/fi-skl-6600u/igt@gem_exec_fence@basic-b...@vecs0.html Participating hosts (44 -> 41) -- Additional (3): fi-cml-u2 fi-bwr-2160 fi-skl-6600u Missing(6): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus fi-skl-6700k2 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8152 -> Patchwork_17011 CI-20190529: 20190529 CI_DRM_8152: ce1895bf390da53060aa60a90367b706d92bf431 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17011: 02e6871f0ae39b3d02f496327a16d769b2647f4b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 02e6871f0ae3 drm/i915: Move the port sync DP_TP_CTL stuff to the encoder hook 50501c73ea1c drm/i915: Pass atomic state to encoder hooks f6dcd889212e drm/i915: Do pipe updates after enables for everyone 04906e4ea040 drm/i915: Fix port sync code to work with >2 pipes 66a94a458d39 drm/i915: Eliminate port sync copy pasta 6a7a32a49547 drm/i915: Implement port sync for SKL+ c806976a0077 drm/i915: Store cpu_transcoder_mask in device info 03e8d170af68 drm/i915: Include port sync state in the state dump ec27107db7e7 drm/i915: Use REG_FIELD_PREP() & co. for TRANS_DDI_FUNC_CTL2 61ac37e65386 drm/i915: Move icl_get_trans_port_sync_config() into the DDI code 632673745f50 drm/i915: Drop usless master_transcoder assignments 2c7d28920dca drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it belongs d2cdf91643a0 drm/i915/mst: Use .compute_config_late() to compute master transcoder == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17011/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Wait until the context is finally retired before releasing engines
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin.
To accommodate this, we need to be able to flush the i915_active's
barriers before awaiting on them. However, this also requires us to
ensure the context is unpinned *before* the barrier request can be
signaled, so mark it as a sentinel.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 17 --
drivers/gpu/drm/i915/i915_active.c | 37 -
drivers/gpu/drm/i915/i915_active.h | 3 +-
3 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c0e476fcd1fa..05fed8797d37 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,23 +570,20 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
engines->ctx = i915_gem_context_get(ctx);
for_each_gem_engine(ce, engines, it) {
- struct dma_fence *fence;
- int err = 0;
+ int err;
/* serialises with execbuf */
RCU_INIT_POINTER(ce->gem_context, NULL);
if (!intel_context_pin_if_active(ce))
continue;
- fence = i915_active_fence_get(>timeline->last_request);
- if (fence) {
- err = i915_sw_fence_await_dma_fence(>fence,
- fence, 0,
- GFP_KERNEL);
- dma_fence_put(fence);
- }
+ /* Wait until context is finally scheduled out and retired */
+ err = i915_sw_fence_await_active(>fence,
+>active,
+I915_ACTIVE_AWAIT_ACTIVE |
+I915_ACTIVE_AWAIT_BARRIER);
intel_context_unpin(ce);
- if (err < 0)
+ if (err)
goto kill;
}
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index c4048628188a..da7d35f66dd0 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -518,19 +518,18 @@ int i915_active_wait(struct i915_active *ref)
return 0;
}
-static int __await_active(struct i915_active_fence *active,
- int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+static int __await_fence(struct i915_active_fence *active,
+int (*fn)(void *arg, struct dma_fence *fence),
+void *arg)
{
struct dma_fence *fence;
+ int err;
- if (is_barrier(active)) /* XXX flush the barrier? */
+ if (is_barrier(active))
return 0;
fence = i915_active_fence_get(active);
if (fence) {
- int err;
-
err = fn(arg, fence);
dma_fence_put(fence);
if (err < 0)
@@ -540,6 +539,22 @@ static int __await_active(struct i915_active_fence *active,
return 0;
}
+static int __await_active(struct active_node *it,
+ unsigned int flags,
+ int (*fn)(void *arg, struct dma_fence *fence),
+ void *arg)
+{
+ int err;
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_barrier(it);
+ if (err)
+ return err;
+ }
+
+ return __await_fence(>base, fn, arg);
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
@@ -549,16 +564,17 @@ static int await_active(struct i915_active *ref,
/* We must always wait for the exclusive fence! */
if (rcu_access_pointer(ref->excl.fence)) {
- err = __await_active(>excl, fn, arg);
+ err = __await_fence(>excl, fn, arg);
if (err)
return err;
}
- if (flags & I915_ACTIVE_AWAIT_ALL && i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
+ i915_active_acquire_if_busy(ref)) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
- err = __await_active(>base, fn, arg);
+ err = __await_active(it, flags, fn, arg);
if (err)
break;
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Force single submission for sentinels
Currently, we only combine a sentinel request with a max-priority
barrier such that a sentinel request is always in ELSP[0] with nothing
following it. However, we will want to create similar ELSP[] submissions
providing a full-barrier in the submission queue, but without forcing
maximum priority. As such I915_FENCE_FLAG_SENTINEL takes on the
single-submission property and so we can remove the gvt special casing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context.h | 24 +++---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 33 +--
drivers/gpu/drm/i915/gvt/scheduler.c | 7 ++--
4 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 18efad255124..ee5d47165c12 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -198,18 +198,6 @@ static inline bool intel_context_set_banned(struct
intel_context *ce)
return test_and_set_bit(CONTEXT_BANNED, >flags);
}
-static inline bool
-intel_context_force_single_submission(const struct intel_context *ce)
-{
- return test_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
-}
-
-static inline void
-intel_context_set_single_submission(struct intel_context *ce)
-{
- __set_bit(CONTEXT_FORCE_SINGLE_SUBMISSION, >flags);
-}
-
static inline bool
intel_context_nopreempt(const struct intel_context *ce)
{
@@ -228,6 +216,18 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
}
+static inline bool
+intel_context_is_gvt(const struct intel_context *ce)
+{
+ return test_bit(CONTEXT_GVT, >flags);
+}
+
+static inline void
+intel_context_set_gvt(struct intel_context *ce)
+{
+ set_bit(CONTEXT_GVT, >flags);
+}
+
static inline u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
const u32 period =
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0f3b68b95c56..fd2703efc10c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -64,8 +64,8 @@ struct intel_context {
#define CONTEXT_VALID_BIT 2
#define CONTEXT_USE_SEMAPHORES 3
#define CONTEXT_BANNED 4
-#define CONTEXT_FORCE_SINGLE_SUBMISSION5
-#define CONTEXT_NOPREEMPT 6
+#define CONTEXT_NOPREEMPT 5
+#define CONTEXT_GVT6
u32 *lrc_reg_state;
u64 lrc_desc;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 112531b29f59..30a5b4049504 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1579,22 +1579,10 @@ static void execlists_submit_ports(struct
intel_engine_cs *engine)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
}
-static bool ctx_single_port_submission(const struct intel_context *ce)
-{
- return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
- intel_context_force_single_submission(ce));
-}
-
static bool can_merge_ctx(const struct intel_context *prev,
const struct intel_context *next)
{
- if (prev != next)
- return false;
-
- if (ctx_single_port_submission(prev))
- return false;
-
- return true;
+ return prev == next;
}
static unsigned long i915_request_flags(const struct i915_request *rq)
@@ -1844,6 +1832,12 @@ static inline void clear_ports(struct i915_request
**ports, int count)
memset_p((void **)ports, NULL, count);
}
+static bool has_sentinel(struct i915_request *prev, struct i915_request *next)
+{
+ return (i915_request_flags(prev) | i915_request_flags(next)) &
+ BIT(I915_FENCE_FLAG_NOPREEMPT);
+}
+
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
@@ -2125,18 +2119,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (last->context == rq->context)
goto done;
- if (i915_request_has_sentinel(last))
- goto done;
-
- /*
-* If GVT overrides us we only ever submit
-* port[0], leaving port[1] empty. Note that we
-* also have to be careful that we don't queue
-* the same context (even though a different
-* request) to the second port.
-*/
- if (ctx_single_port_submission(last->context) ||
-
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Port sync for skl+ (rev2)
== Series Details ==
Series: drm/i915: Port sync for skl+ (rev2)
URL : https://patchwork.freedesktop.org/series/74691/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d2cdf91643a0 drm/i915/mst: Use .compute_config_late() to compute master
transcoder
2c7d28920dca drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it belongs
632673745f50 drm/i915: Drop usless master_transcoder assignments
61ac37e65386 drm/i915: Move icl_get_trans_port_sync_config() into the DDI code
ec27107db7e7 drm/i915: Use REG_FIELD_PREP() & co. for TRANS_DDI_FUNC_CTL2
-:55: WARNING:LONG_LINE: line over 100 characters
#55: FILE: drivers/gpu/drm/i915/i915_reg.h:9734:
+#define PORT_SYNC_MODE_MASTER_SELECT(x)
REG_FIELD_PREP(PORT_SYNC_MODE_MASTER_SELECT_MASK, (x))
total: 0 errors, 1 warnings, 0 checks, 34 lines checked
03e8d170af68 drm/i915: Include port sync state in the state dump
c806976a0077 drm/i915: Store cpu_transcoder_mask in device info
-:96: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#96: FILE: drivers/gpu/drm/i915/display/intel_display.h:323:
+#define for_each_cpu_transcoder(__dev_priv, __t) \
for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
+ for_each_if (INTEL_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
-:96: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible side-effects?
#96: FILE: drivers/gpu/drm/i915/display/intel_display.h:323:
+#define for_each_cpu_transcoder(__dev_priv, __t) \
for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
+ for_each_if (INTEL_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
-:99: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#99: FILE: drivers/gpu/drm/i915/display/intel_display.h:325:
+ for_each_if (INTEL_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
-:101: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#101: FILE: drivers/gpu/drm/i915/display/intel_display.h:327:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+ for_each_cpu_transcoder(__dev_priv, __t) \
+ for_each_if ((__mask) & BIT(__t))
-:101: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible
side-effects?
#101: FILE: drivers/gpu/drm/i915/display/intel_display.h:327:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+ for_each_cpu_transcoder(__dev_priv, __t) \
+ for_each_if ((__mask) & BIT(__t))
-:103: WARNING:SPACING: space prohibited between function name and open
parenthesis '('
#103: FILE: drivers/gpu/drm/i915/display/intel_display.h:329:
+ for_each_if ((__mask) & BIT(__t))
-:116: WARNING:LONG_LINE: line over 100 characters
#116: FILE: drivers/gpu/drm/i915/i915_drv.h:1605:
+#define HAS_TRANSCODER(dev_priv, trans)
((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0)
total: 2 errors, 3 warnings, 2 checks, 242 lines checked
6a7a32a49547 drm/i915: Implement port sync for SKL+
-:209: WARNING:LONG_LINE: line over 100 characters
#209: FILE: drivers/gpu/drm/i915/i915_reg.h:9704:
+#define TRANS_DDI_PORT_SYNC_MASTER_SELECT(x)
REG_FIELD_PREP(TRANS_DDI_PORT_SYNC_MASTER_SELECT_MASK, (x))
total: 0 errors, 1 warnings, 0 checks, 165 lines checked
66a94a458d39 drm/i915: Eliminate port sync copy pasta
04906e4ea040 drm/i915: Fix port sync code to work with >2 pipes
f6dcd889212e drm/i915: Do pipe updates after enables for everyone
50501c73ea1c drm/i915: Pass atomic state to encoder hooks
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_atomic_state *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_encoder *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'const struct
intel_crtc_state *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:558: WARNING:FUNCTION_ARGUMENTS: function definition argument 'const struct
drm_connector_state *' should also have an identifier name
#558: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:149:
+ void (*pre_pll_enable)(struct intel_atomic_state *,
-:563: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_atomic_state *' should also have an identifier name
#563: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:153:
+ void (*pre_enable)(struct intel_atomic_state *,
-:563: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct
intel_encoder *' should also have an identifier name
#563:
Re: [Intel-gfx] [PATCH] drm: Skip drm_mode_config_validate() for !modeset
Quoting Ville Syrjala (2020-03-18 18:25:18)
> From: Ville Syrjälä
>
> drm_mode_config_init() may not have been called when the driver/device
> doesn't support modeset. That will cause drm_mode_config_validate()
> to oops. Skip the validation for !modeset.
>
> TODO: We may want to consider calling drm_mode_config_init()
> unconditionally to avoid similar issues elsewhere...
>
> Fixes: 74d2aacbe840 ("drm: Validate encoder->possible_clones")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Skip drm_mode_config_validate() for !modeset
From: Ville Syrjälä
drm_mode_config_init() may not have been called when the driver/device
doesn't support modeset. That will cause drm_mode_config_validate()
to oops. Skip the validation for !modeset.
TODO: We may want to consider calling drm_mode_config_init()
unconditionally to avoid similar issues elsewhere...
Fixes: 74d2aacbe840 ("drm: Validate encoder->possible_clones")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_mode_config.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 55322d7048f5..e1ec1bb7068d 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -608,6 +608,9 @@ void drm_mode_config_validate(struct drm_device *dev)
{
struct drm_encoder *encoder;
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
drm_for_each_encoder(encoder, dev)
fixup_encoder_possible_clones(encoder);
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Reject dumb buffers when driver/device doesn't support modesetting
== Series Details == Series: drm: Reject dumb buffers when driver/device doesn't support modesetting URL : https://patchwork.freedesktop.org/series/74841/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8151 -> Patchwork_17010 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17010 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17010, 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_17010/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17010: ### IGT changes ### Possible regressions * igt@gem_exec_fence@basic-busy@vcs0: - fi-elk-e7500: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/fi-elk-e7500/igt@gem_exec_fence@basic-b...@vcs0.html - fi-ilk-650: NOTRUN -> [DMESG-WARN][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/fi-ilk-650/igt@gem_exec_fence@basic-b...@vcs0.html * igt@gem_exec_fence@basic-busy@vecs0: - fi-hsw-peppy: NOTRUN -> [DMESG-WARN][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/fi-hsw-peppy/igt@gem_exec_fence@basic-b...@vecs0.html - fi-skl-guc: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/fi-skl-guc/igt@gem_exec_fence@basic-b...@vecs0.html * igt@runner@aborted: - fi-ilk-650: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/fi-ilk-650/igt@run...@aborted.html - fi-hsw-peppy: NOTRUN -> [FAIL][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/fi-hsw-peppy/igt@run...@aborted.html - fi-elk-e7500: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/fi-elk-e7500/igt@run...@aborted.html Participating hosts (41 -> 38) -- Additional (6): fi-hsw-peppy fi-skl-guc fi-bdw-gvtdvm fi-ilk-650 fi-elk-e7500 fi-snb-2600 Missing(9): fi-ilk-m540 fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-ivb-3770 fi-cfl-8109u fi-bsw-kefka fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8151 -> Patchwork_17010 CI-20190529: 20190529 CI_DRM_8151: 20887f81adb13a9ff582aa079bb5a7e7fc36b7f5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5522: bd2b01af69c9720d54e68a8702a23e4ff3637746 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17010: a77d1080eb589fe2a2178dbada738b8dcd4e9b57 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a77d1080eb58 drm: Reject dumb buffers when driver/device doesn't support modesetting == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17010/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off
On Wed, Mar 18, 2020 at 07:45:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We only consider crtc_state->enable when initially calculating plane
> visibility. Later on we try to override the plane's state to invisible
> if the crtc is in DPMS off state (crtc_state->active==false).
> Unfortunately the code doing that only updates the plane_state.visible
> flag and the crtc_state.active_planes bimask, but forgets to update
> some of the other plane bitmasks stored in the crtc_state. Namely
> crtc_state.nv12_planes is left set up based on the original visibility
> check which makes icl_check_nv12_planes() pick a slave plane for the
> flagged plane in the bitmask. Later on we hit the watermark code
> which sees a plane with a slave assigned and it then makes the
> logical assumption that the master plane must itself be visible.
> Since the master's plane_state.visible flag was already cleared
> we get a WARN.
>
> Fix the problem by clearing all the plane bitmasks for DPMS off.
> This is more or less the wrong approach and instead we should
> calculate all the plane related state purely based crtc_state->enable
> (to guarantee that the subsequent DPMS on can't fail). However in
> the past we definitely had some roadblocks to making that happen.
> Not sure how many are left these days, but let's stick to the current
> approach since it's a much simpler fix to the immediate problem
> (the WARN).
>
> v2: Keep the visible=false, it's important (Rodrigo)
>
> Cc: Rodrigo Vivi
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 21 +--
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 ++
> drivers/gpu/drm/i915/display/intel_display.c | 6 ++
> 3 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 457b258683d3..25dfeb3197aa 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -264,6 +264,20 @@ void intel_plane_copy_uapi_to_hw_state(struct
> intel_plane_state *plane_state,
> plane_state->hw.color_range = from_plane_state->uapi.color_range;
> }
>
> +void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
> +struct intel_plane_state *plane_state)
> +{
> + struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
> +
> + crtc_state->active_planes &= ~BIT(plane->id);
> + crtc_state->nv12_planes &= ~BIT(plane->id);
> + crtc_state->c8_planes &= ~BIT(plane->id);
> + crtc_state->data_rate[plane->id] = 0;
> + crtc_state->min_cdclk[plane->id] = 0;
> +
> + plane_state->uapi.visible = false;
> +}
> +
> int intel_plane_atomic_check_with_state(const struct intel_crtc_state
> *old_crtc_state,
> struct intel_crtc_state *new_crtc_state,
> const struct intel_plane_state
> *old_plane_state,
> @@ -273,12 +287,7 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> const struct drm_framebuffer *fb = new_plane_state->hw.fb;
> int ret;
>
> - new_crtc_state->active_planes &= ~BIT(plane->id);
> - new_crtc_state->nv12_planes &= ~BIT(plane->id);
> - new_crtc_state->c8_planes &= ~BIT(plane->id);
> - new_crtc_state->data_rate[plane->id] = 0;
> - new_crtc_state->min_cdclk[plane->id] = 0;
> - new_plane_state->uapi.visible = false;
> + intel_plane_set_invisible(new_crtc_state, new_plane_state);
>
> if (!new_plane_state->hw.crtc && !old_plane_state->hw.crtc)
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index a6bbf42bae1f..59dd1fbb02ea 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -52,5 +52,7 @@ int intel_plane_atomic_calc_changes(const struct
> intel_crtc_state *old_crtc_stat
> int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
> struct intel_plane *plane,
> bool *need_cdclk_calc);
> +void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
> +struct intel_plane_state *plane_state);
>
> #endif /* __INTEL_ATOMIC_PLANE_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f23c4d51c33..37bd7ce88ecd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -12377,10 +12377,8 @@ int intel_plane_atomic_calc_changes(const struct
> intel_crtc_state *old_crtc_stat
>* only combine the results from all planes in the current place?
>*/
> if (!is_crtc_enabled)
[Intel-gfx] [PATCH v2] drm/i915: Fix crtc nv12 etc. plane bitmasks for DPMS off
From: Ville Syrjälä
We only consider crtc_state->enable when initially calculating plane
visibility. Later on we try to override the plane's state to invisible
if the crtc is in DPMS off state (crtc_state->active==false).
Unfortunately the code doing that only updates the plane_state.visible
flag and the crtc_state.active_planes bimask, but forgets to update
some of the other plane bitmasks stored in the crtc_state. Namely
crtc_state.nv12_planes is left set up based on the original visibility
check which makes icl_check_nv12_planes() pick a slave plane for the
flagged plane in the bitmask. Later on we hit the watermark code
which sees a plane with a slave assigned and it then makes the
logical assumption that the master plane must itself be visible.
Since the master's plane_state.visible flag was already cleared
we get a WARN.
Fix the problem by clearing all the plane bitmasks for DPMS off.
This is more or less the wrong approach and instead we should
calculate all the plane related state purely based crtc_state->enable
(to guarantee that the subsequent DPMS on can't fail). However in
the past we definitely had some roadblocks to making that happen.
Not sure how many are left these days, but let's stick to the current
approach since it's a much simpler fix to the immediate problem
(the WARN).
v2: Keep the visible=false, it's important (Rodrigo)
Cc: Rodrigo Vivi
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 21 +--
.../gpu/drm/i915/display/intel_atomic_plane.h | 2 ++
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 457b258683d3..25dfeb3197aa 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -264,6 +264,20 @@ void intel_plane_copy_uapi_to_hw_state(struct
intel_plane_state *plane_state,
plane_state->hw.color_range = from_plane_state->uapi.color_range;
}
+void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state)
+{
+ struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
+
+ crtc_state->active_planes &= ~BIT(plane->id);
+ crtc_state->nv12_planes &= ~BIT(plane->id);
+ crtc_state->c8_planes &= ~BIT(plane->id);
+ crtc_state->data_rate[plane->id] = 0;
+ crtc_state->min_cdclk[plane->id] = 0;
+
+ plane_state->uapi.visible = false;
+}
+
int intel_plane_atomic_check_with_state(const struct intel_crtc_state
*old_crtc_state,
struct intel_crtc_state *new_crtc_state,
const struct intel_plane_state
*old_plane_state,
@@ -273,12 +287,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
const struct drm_framebuffer *fb = new_plane_state->hw.fb;
int ret;
- new_crtc_state->active_planes &= ~BIT(plane->id);
- new_crtc_state->nv12_planes &= ~BIT(plane->id);
- new_crtc_state->c8_planes &= ~BIT(plane->id);
- new_crtc_state->data_rate[plane->id] = 0;
- new_crtc_state->min_cdclk[plane->id] = 0;
- new_plane_state->uapi.visible = false;
+ intel_plane_set_invisible(new_crtc_state, new_plane_state);
if (!new_plane_state->hw.crtc && !old_plane_state->hw.crtc)
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
index a6bbf42bae1f..59dd1fbb02ea 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
@@ -52,5 +52,7 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
struct intel_plane *plane,
bool *need_cdclk_calc);
+void intel_plane_set_invisible(struct intel_crtc_state *crtc_state,
+ struct intel_plane_state *plane_state);
#endif /* __INTEL_ATOMIC_PLANE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f23c4d51c33..37bd7ce88ecd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12377,10 +12377,8 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
* only combine the results from all planes in the current place?
*/
if (!is_crtc_enabled) {
- plane_state->uapi.visible = visible = false;
- crtc_state->active_planes &= ~BIT(plane->id);
- crtc_state->data_rate[plane->id] = 0;
- crtc_state->min_cdclk[plane->id] = 0;
+
Re: [Intel-gfx] [PATCH v9] drm/i915/color: Extract icl_read_luts()
On Tue, Mar 17, 2020 at 07:27:36PM +0530, Swati Sharma wrote:
> For icl+, have hw read out to create hw blob of gamma
> lut values. icl+ platforms supports multi segmented gamma
> mode by default, add hw lut creation for this mode.
>
> This will be used to validate gamma programming using dsb
> (display state buffer) which is a tgl specific feature.
>
> v2: -readout code for multisegmented gamma has to come
> up with some intermediate entries that aren't preserved
> in hardware (Jani N)
> -linear interpolation (Ville)
> -moved common code to check gamma_enable to specific funcs,
> since icl doesn't support that
> v3: -use u16 instead of __u16 [Jani N]
> -used single lut [Jani N]
> -improved and more readable for loops [Jani N]
> -read values directly to actual locations and then fill gaps [Jani N]
> -moved cleaning to patch 1 [Jani N]
> -renamed icl_read_lut_multi_seg() to icl_read_lut_multi_segment to
> make it similar to icl_load_luts()
> -renamed icl_compute_interpolated_gamma_blob() to
> icl_compute_interpolated_gamma_lut_values() more sensible, I guess
> v4: -removed interpolated func for creating gamma lut values
> -removed readouts of fine and coarse segments, failure to read
> PAL_PREC_DATA
> correctly
> v5: -added gamma_enable check inside read_luts()
> v6: -renamed intel_color_lut_entry_equal() to intel_color_lut_entries_equal()
> [Ville]
> -changed if-else to switch [Ville]
> -removed intel_color_lut_entry_multi_equal() [Ville]
> v7: -checkpatch warnings
> v8: -rebased
> v9: -rebased, aligned with Ville's style of gamma cleanup
>
> Signed-off-by: Swati Sharma
> Reviewed-by: Mika Kahola
Hmm. Did I not send out the mail saying that I pushed this? Maybe not.
Well, doing that now. Pushed to dinq. Thanks for the patch and review.
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 121 ++---
> drivers/gpu/drm/i915/i915_reg.h| 6 +
> 2 files changed, 109 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index c1cce93a1c25..98ece9cd7cdd 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -460,6 +460,16 @@ static void ilk_lut_10_pack(struct drm_color_lut *entry,
> u32 val)
> entry->blue =
> intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_BLUE_MASK, val), 10);
> }
>
> +static void icl_lut_multi_seg_pack(struct drm_color_lut *entry, u32 ldw, u32
> udw)
> +{
> + entry->red = REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_UDW_MASK, udw) << 6 |
> +
> REG_FIELD_GET(PAL_PREC_MULTI_SEG_RED_LDW_MASK, ldw);
> + entry->green = REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_UDW_MASK, udw) <<
> 6 |
> +
> REG_FIELD_GET(PAL_PREC_MULTI_SEG_GREEN_LDW_MASK, ldw);
> + entry->blue = REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_UDW_MASK, udw) << 6
> |
> +
> REG_FIELD_GET(PAL_PREC_MULTI_SEG_BLUE_LDW_MASK, ldw);
> +}
> +
> static void i9xx_color_commit(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -893,7 +903,7 @@ icl_load_gcmax(const struct intel_crtc_state *crtc_state,
> struct intel_dsb *dsb = intel_dsb_get(crtc);
> enum pipe pipe = crtc->pipe;
>
> - /* Fixme: LUT entries are 16 bit only, so we can prog 0x max */
> + /* FIXME LUT entries are 16 bit only, so we can prog 0x max */
> intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 0), color->red);
> intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 1), color->green);
> intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 2), color->blue);
> @@ -1630,6 +1640,24 @@ static int glk_gamma_precision(const struct
> intel_crtc_state *crtc_state)
> }
> }
>
> +static int icl_gamma_precision(const struct intel_crtc_state *crtc_state)
> +{
> + if ((crtc_state->gamma_mode & POST_CSC_GAMMA_ENABLE) == 0)
> + return 0;
> +
> + switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) {
> + case GAMMA_MODE_MODE_8BIT:
> + return 8;
> + case GAMMA_MODE_MODE_10BIT:
> + return 10;
> + case GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED:
> + return 16;
> + default:
> + MISSING_CASE(crtc_state->gamma_mode);
> + return 0;
> + }
> +}
> +
> int intel_color_get_gamma_bit_precision(const struct intel_crtc_state
> *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -1641,7 +1669,9 @@ int intel_color_get_gamma_bit_precision(const struct
> intel_crtc_state *crtc_stat
> else
> return i9xx_gamma_precision(crtc_state);
> } else {
> - if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 11)
[Intel-gfx] [PATCH v2 07/13] drm/i915: Store cpu_transcoder_mask in device info
From: Ville Syrjälä
We have a bunch of code that would like to know which
CPU transcoders are actually present in the hardware. Rather than
use various ad-hoc methods let's just include a full bitmask in
the device info, alongside pipe_mask.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++--
drivers/gpu/drm/i915/display/intel_display.c | 13 ++---
drivers/gpu/drm/i915/display/intel_display.h | 8 --
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_pci.c | 23 +++-
drivers/gpu/drm/i915/intel_device_info.c | 29
drivers/gpu/drm/i915/intel_device_info.h | 1 +
7 files changed, 53 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 8bb6c583abb8..0fea2ec2cdd8 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1689,7 +1689,7 @@ bool intel_ddi_connector_get_hw_state(struct
intel_connector *intel_connector)
goto out;
}
- if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A)
+ if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A)
cpu_transcoder = TRANSCODER_EDP;
else
cpu_transcoder = (enum transcoder) pipe;
@@ -1751,7 +1751,7 @@ static void intel_ddi_get_encoder_pipes(struct
intel_encoder *encoder,
if (!(tmp & DDI_BUF_CTL_ENABLE))
goto out;
- if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A) {
+ if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A) {
tmp = intel_de_read(dev_priv,
TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
@@ -4076,7 +4076,7 @@ static int intel_ddi_compute_config(struct intel_encoder
*encoder,
enum port port = encoder->port;
int ret;
- if (HAS_TRANSCODER_EDP(dev_priv) && port == PORT_A)
+ if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP) && port == PORT_A)
pipe_config->cpu_transcoder = TRANSCODER_EDP;
if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_HDMI)) {
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 4840988dc58d..292cac64f1ac 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10855,7 +10855,7 @@ static bool hsw_get_transcoder_state(struct intel_crtc
*crtc,
panel_transcoder_mask |=
BIT(TRANSCODER_DSI_0) | BIT(TRANSCODER_DSI_1);
- if (HAS_TRANSCODER_EDP(dev_priv))
+ if (HAS_TRANSCODER(dev_priv, TRANSCODER_EDP))
panel_transcoder_mask |= BIT(TRANSCODER_EDP);
/*
@@ -18712,15 +18712,6 @@ void intel_modeset_driver_remove_noirq(struct
drm_i915_private *i915)
#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
-static bool
-has_transcoder(struct drm_i915_private *dev_priv, enum transcoder
cpu_transcoder)
-{
- if (cpu_transcoder == TRANSCODER_EDP)
- return HAS_TRANSCODER_EDP(dev_priv);
- else
- return INTEL_INFO(dev_priv)->pipe_mask & BIT(cpu_transcoder);
-}
-
struct intel_display_error_state {
u32 power_well_driver;
@@ -18829,7 +18820,7 @@ intel_display_capture_error_state(struct
drm_i915_private *dev_priv)
for (i = 0; i < ARRAY_SIZE(error->transcoder); i++) {
enum transcoder cpu_transcoder = transcoders[i];
- if (!has_transcoder(dev_priv, cpu_transcoder))
+ if (!HAS_TRANSCODER(dev_priv, cpu_transcoder))
continue;
error->transcoder[i].available = true;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index adb1225a3480..cc7f287804d7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -320,9 +320,13 @@ enum phy_fia {
for_each_pipe(__dev_priv, __p) \
for_each_if((__mask) & BIT(__p))
-#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+#define for_each_cpu_transcoder(__dev_priv, __t) \
for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++) \
- for_each_if ((__mask) & (1 << (__t)))
+ for_each_if (INTEL_INFO(__dev_priv)->cpu_transcoder_mask &
BIT(__t))
+
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+ for_each_cpu_transcoder(__dev_priv, __t) \
+ for_each_if ((__mask) & BIT(__t))
#define for_each_universal_plane(__dev_priv, __pipe, __p) \
for ((__p) = 0; \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a7ea1d855359..ea9170fd169b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/color: Extract icl_read_luts()
== Series Details == Series: drm/i915/color: Extract icl_read_luts() URL : https://patchwork.freedesktop.org/series/74777/ State : success == Summary == CI Bug Log - changes from CI_DRM_8142_full -> Patchwork_16995_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16995_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#1402]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-tglb8/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-tglb2/igt@gem_ctx_persiste...@close-replace-race.html - shard-kbl: [PASS][3] -> [INCOMPLETE][4] ([i915#1402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-kbl2/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-kbl4/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_persistence@legacy-engines-mixed@render: - shard-skl: [PASS][5] -> [FAIL][6] ([i915#679]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mi...@render.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mi...@render.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb2/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112080]) +13 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb2/igt@gem_exec_paral...@vcs1-fds.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb5/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb8/igt@gem_exec_sched...@implicit-both-bsd2.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112146]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb3/igt@gem_exec_sched...@preemptive-hang-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109276]) +23 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb4/igt@gem_exec_sched...@promotion-bsd1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb6/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#644]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-apl6/igt@gem_pp...@flink-and-close-vma-leak.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-kbl7/igt@gem_pp...@flink-and-close-vma-leak.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([i915#300]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][25] -> [FAIL][26] ([i915#79]) [25]:
Re: [Intel-gfx] [PATCH] drm/i915: Enable non-contiguous pipe fusing
On Fri, Mar 13, 2020 at 12:39:17AM -0700, Lucas De Marchi wrote: > On Wed, Mar 11, 2020 at 02:06:32PM +0530, Anshuman Gupta wrote: > >Allow 3-display pipes SKU system with any combination > >in INTEL_INFO pipe mask. > >B.Spec:50075 > > > >changes since RFC: > >- using intel_pipe_mask_is_valid() function to check integrity of > > pipe_mask. [Ville] > >v2: > >- simplify condition in intel_pipe_mask_is_valid(). [Ville] > >v3: > >- removed non-contiguous pipe fusing check. [Lucas] > > I'd also say in the commit message that the support for non-contiguous > pipe fusing is *already* supported in the driver. So this check here > doesn't make sense anymore and since it's an unlike condition we > can just stop checking. BTW I think we still have those crtc index==pipe asserts in the code somewhere. Now that all the (known) assumptions have been fixed we can remove the WARNs. > > Aside from commit message update, > > Reviewed-by: Lucas De Marchi > > Lucas De Marchi > > > > >Cc: Ville Syrjälä > >Cc: Lucas De Marchi > >Signed-off-by: Anshuman Gupta > >--- > > drivers/gpu/drm/i915/intel_device_info.c | 12 +--- > > 1 file changed, 1 insertion(+), 11 deletions(-) > > > >diff --git a/drivers/gpu/drm/i915/intel_device_info.c > >b/drivers/gpu/drm/i915/intel_device_info.c > >index d7fe12734db8..9ff89e142ff1 100644 > >--- a/drivers/gpu/drm/i915/intel_device_info.c > >+++ b/drivers/gpu/drm/i915/intel_device_info.c > >@@ -998,17 +998,7 @@ void intel_device_info_runtime_init(struct > >drm_i915_private *dev_priv) > > (dfsm & TGL_DFSM_PIPE_D_DISABLE)) > > enabled_mask &= ~BIT(PIPE_D); > > > >-/* > >- * At least one pipe should be enabled and if there are > >- * disabled pipes, they should be the last ones, with no holes > >- * in the mask. > >- */ > >-if (enabled_mask == 0 || !is_power_of_2(enabled_mask + 1)) > >-drm_err(_priv->drm, > >-"invalid pipe fuse configuration: > >enabled_mask=0x%x\n", > >-enabled_mask); > >-else > >-info->pipe_mask = enabled_mask; > >+info->pipe_mask = enabled_mask; > > > > if (dfsm & SKL_DFSM_DISPLAY_HDCP_DISABLE) > > info->display.has_hdcp = 0; > >-- > >2.25.1 > > -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 7/7] drm: Allow drivers to leave encoder->possible_crtcs==0
On Wed, Feb 12, 2020 at 10:08:49AM +0100, Daniel Vetter wrote:
> On Wed, Feb 12, 2020 at 10:07:55AM +0100, Daniel Vetter wrote:
> > On Tue, Feb 11, 2020 at 07:14:51PM +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 11, 2020 at 06:05:45PM +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 11, 2020 at 06:22:08PM +0200, Ville Syrjala wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > Let's simplify life of driver by allowing them to leave
> > > > > encoder->possible_crtcs unset if they have no restrictions
> > > > > in crtc<->encoder linkage. We'll just populate possible_crtcs
> > > > > with the full crtc mask when registering the encoder so that
> > > > > userspace doesn't have to deal with drivers not populating
> > > > > this correctly.
> > > > >
> > > > > Cc: Thomas Zimmermann
> > > > > Cc: Daniel Vetter
> > > > > Signed-off-by: Ville Syrjälä
> > > > > ---
> > > > > We might not actually need/want this, but included it here for
> > > > > future reference if that assumption turns out to be wrong.
> > > >
> > > > I think this one is most definitely needed. _Lots_ of drivers get this
> > > > toally wrong and just leave the value blank. It's encoded as official
> > > > fallback in most userspace compositors.
> > >
> > > OK. It's been a while since I dug around so can't really remmber how
> > > this was being handled. I'll reorder before pushing.
> >
> > Hm otoh having "works with all crtcs" as default is a bit dangerous,
> > whereas the "cannot be cloned" default for possible_clones is perfectly
> > safe.
> >
> > So now I'm kinda not sure whether this is a bright idea, and we shouldn't
> > just eat the cost of fixing up all the various WARNING backtraces your
> > previous patch triggers. I've done a full review and the following look
> > suspect:
> >
> > - tegara/sor.c Strangely it's the only one, the other output drivers do
> > seem to set the possible_crtcs mask to something useful.
>
> Strike that, it sets it using tegra_output_find_possible_crtcs().
>
> I think everything is good and we really don't need this patch here to fix
> up possible_crtcs.
Finally pushed the other patches from the series to drm-misc-next.
Thanks for the reviews.
Should the new possible_{crtcs,clones} WARNs start to trigger for
anyone despite our best efforts, please holler and I'll look into
what needs fixing.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/color: Extract icl_read_luts()
== Series Details == Series: drm/i915/color: Extract icl_read_luts() URL : https://patchwork.freedesktop.org/series/74777/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8142_full -> Patchwork_16995_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16995_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16995_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_16995_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@legacy-engines-mixed@render: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mi...@render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mi...@render.html Known issues Here are the changes found in Patchwork_16995_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#1402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-tglb8/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-tglb2/igt@gem_ctx_persiste...@close-replace-race.html - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#1402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-kbl2/igt@gem_ctx_persiste...@close-replace-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-kbl4/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb2/igt@gem_exec_balan...@smoke.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb5/igt@gem_exec_balan...@smoke.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#112080]) +13 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb2/igt@gem_exec_paral...@vcs1-fds.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb5/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@implicit-both-bsd2: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109276] / [i915#677]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb4/igt@gem_exec_sched...@implicit-both-bsd2.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb8/igt@gem_exec_sched...@implicit-both-bsd2.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#677]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb6/igt@gem_exec_sched...@pi-shared-iova-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#112146]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb3/igt@gem_exec_sched...@preemptive-hang-bsd.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_exec_schedule@promotion-bsd1: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109276]) +23 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-iclb4/igt@gem_exec_sched...@promotion-bsd1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-iclb6/igt@gem_exec_sched...@promotion-bsd1.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#644]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-apl6/igt@gem_pp...@flink-and-close-vma-leak.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-apl7/igt@gem_pp...@flink-and-close-vma-leak.html - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#644]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8142/shard-kbl1/igt@gem_pp...@flink-and-close-vma-leak.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16995/shard-kbl7/igt@gem_pp...@flink-and-close-vma-leak.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([i915#300]) [23]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Prefer '%ps' for printing function symbol names
== Series Details == Series: drm/i915: Prefer '%ps' for printing function symbol names URL : https://patchwork.freedesktop.org/series/74831/ State : success == Summary == CI Bug Log - changes from CI_DRM_8147_full -> Patchwork_17007_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17007_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-hsw: [PASS][1] -> [TIMEOUT][2] ([i915#1358]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-hsw2/igt@gem_cre...@create-clear.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-hsw5/igt@gem_cre...@create-clear.html * igt@gem_ctx_persistence@close-replace-race: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#1402]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-skl2/igt@gem_ctx_persiste...@close-replace-race.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-skl3/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#1197] / [i915#1239]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#679]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#1277]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-tglb7/igt@gem_exec_balan...@hang.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-tglb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([i915#677]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-iclb3/igt@gem_exec_sched...@pi-common-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-iclb2/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#112146]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-iclb7/igt@gem_exec_sched...@preempt-bsd.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-iclb1/igt@gem_exec_sched...@preempt-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109276]) +16 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#644]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-glk1/igt@gem_pp...@flink-and-close-vma-leak.html - shard-apl: [PASS][19] -> [FAIL][20] ([i915#644]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-apl2/igt@gem_pp...@flink-and-close-vma-leak.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-apl1/igt@gem_pp...@flink-and-close-vma-leak.html * igt@kms_color@pipe-a-ctm-red-to-blue: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#129]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-skl2/igt@kms_co...@pipe-a-ctm-red-to-blue.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-skl3/igt@kms_co...@pipe-a-ctm-red-to-blue.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#79]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/shard-glk3/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][25] -> [DMESG-WARN][26] ([i915#180]) +1 similar issue [25]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Wait until the context is finally retired before releasing engines (rev2)
== Series Details ==
Series: drm/i915/gem: Wait until the context is finally retired before
releasing engines (rev2)
URL : https://patchwork.freedesktop.org/series/74836/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8148 -> Patchwork_17009
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17009 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17009, 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_17009/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17009:
### IGT changes ###
Possible regressions
* igt@gem_exec_parallel@fds:
- fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-skl-lmem/igt@gem_exec_paral...@fds.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-skl-lmem/igt@gem_exec_paral...@fds.html
- fi-kbl-r: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-kbl-r/igt@gem_exec_paral...@fds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-kbl-r/igt@gem_exec_paral...@fds.html
- fi-kbl-7500u: NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-kbl-7500u/igt@gem_exec_paral...@fds.html
- fi-kbl-x1275: [PASS][6] -> [INCOMPLETE][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-kbl-x1275/igt@gem_exec_paral...@fds.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-kbl-x1275/igt@gem_exec_paral...@fds.html
- fi-skl-6600u: NOTRUN -> [INCOMPLETE][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-skl-6600u/igt@gem_exec_paral...@fds.html
- fi-skl-6700k2: [PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-skl-6700k2/igt@gem_exec_paral...@fds.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-skl-6700k2/igt@gem_exec_paral...@fds.html
Known issues
Here are the changes found in Patchwork_17009 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-cml-s: [PASS][11] -> [INCOMPLETE][12] ([i915#283])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-cml-s/igt@gem_close_r...@basic-threads.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-cml-s/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_parallel@contexts:
- fi-bxt-dsi: [PASS][13] -> [INCOMPLETE][14] ([fdo#103927])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-bxt-dsi/igt@gem_exec_paral...@contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-bxt-dsi/igt@gem_exec_paral...@contexts.html
* igt@gem_exec_parallel@fds:
- fi-cml-u2: [PASS][15] -> [INCOMPLETE][16] ([i915#283])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-cml-u2/igt@gem_exec_paral...@fds.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-cml-u2/igt@gem_exec_paral...@fds.html
- fi-icl-y: [PASS][17] -> [INCOMPLETE][18] ([i915#1147])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-icl-y/igt@gem_exec_paral...@fds.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-icl-y/igt@gem_exec_paral...@fds.html
Possible fixes
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-bwr-2160:[FAIL][19] -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8148/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17009/fi-bwr-2160/igt@kms_flip@basic-flip-vs-wf_vblank.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[i915#1147]: https://gitlab.freedesktop.org/drm/intel/issues/1147
[i915#283]: https://gitlab.freedesktop.org/drm/intel/issues/283
[i915#470]: https://gitlab.freedesktop.org/drm/intel/issues/470
Participating hosts (36 -> 40)
--
Additional (7): fi-glk-dsi fi-kbl-7500u fi-cfl-8109u fi-elk-e7500
fi-kbl-7560u fi-skl-6600u fi-snb-2600
Missing(3): fi-ctg-p8600 fi-byt-clapper fi-bsw-cyan
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8148 -> Patchwork_17009
CI-20190529: 20190529
CI_DRM_8148: 461a6f2c7c0296c282114ac8c0e63536e9f7d095 @
Re: [Intel-gfx] [PATCH 1/9] drm: Constify topology id
On Fri, Mar 13, 2020 at 04:05:00PM -0400, Alex Deucher wrote:
> On Fri, Mar 13, 2020 at 12:21 PM Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Make the topology id const since we don't want to change it.
> >
> > Signed-off-by: Ville Syrjälä
>
> Series is:
> Reviewed-by: Alex Deucher
Thanks. Series pushed to drm-misc-next.
>
> > ---
> > drivers/gpu/drm/drm_connector.c | 4 ++--
> > include/drm/drm_connector.h | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c
> > b/drivers/gpu/drm/drm_connector.c
> > index 644f0ad10671..462d8caa6e72 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -2392,7 +2392,7 @@ EXPORT_SYMBOL(drm_mode_put_tile_group);
> > * tile group or NULL if not found.
> > */
> > struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
> > - char topology[8])
> > + const char topology[8])
> > {
> > struct drm_tile_group *tg;
> > int id;
> > @@ -2422,7 +2422,7 @@ EXPORT_SYMBOL(drm_mode_get_tile_group);
> > * new tile group or NULL.
> > */
> > struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
> > - char topology[8])
> > + const char topology[8])
> > {
> > struct drm_tile_group *tg;
> > int ret;
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index 19ae6bb5c85b..fd543d1db9b2 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -1617,9 +1617,9 @@ struct drm_tile_group {
> > };
> >
> > struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
> > - char topology[8]);
> > + const char topology[8]);
> > struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
> > - char topology[8]);
> > + const char topology[8]);
> > void drm_mode_put_tile_group(struct drm_device *dev,
> > struct drm_tile_group *tg);
> >
> > --
> > 2.24.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm: Create a drm_connector_helper_funcs hook for Adaptive Sync support
On 2020-03-18 2:35 a.m., Manasi Navare wrote:
> This patch adds a hook in drm_connector_helper_funcs to get the
> support of the driver for adaptive sync functionality.
>
> This can be called in the connector probe helper function after
> the connector detect() and get_modes() hooks to also
> query the adaptive sync support of the driver.
>
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Nicholas Kazlauskas
> Signed-off-by: Manasi Navare
Patches 1 and 2 are
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_probe_helper.c | 4
> include/drm/drm_modeset_helper_vtables.h | 16
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 576b4b7dcd89..4403817bfb02 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -482,6 +482,10 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
>
> count = (*connector_funcs->get_modes)(connector);
>
> + /* Get the Adaptive Sync Support if helper exists */
> + if (*connector_funcs->get_adaptive_sync_support)
> + (**connector_funcs->get_adaptive_sync_support)(connector);
> +
> /*
>* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
>* override/firmware EDID.
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index 7c20b1c8b6a7..0b203fdd25df 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1079,6 +1079,22 @@ struct drm_connector_helper_funcs {
>struct drm_writeback_job *job);
> void (*cleanup_writeback_job)(struct drm_writeback_connector *connector,
> struct drm_writeback_job *job);
> +
> + /**
> + * @get_adaptive_sync_support:
> + *
> + * This hook is used by the probe helper to get the driver's support
> + * for adaptive sync or variable refresh rate.
> + * This is called from drm_helper_probe_single_connector_modes()
> + * This is called after the @get_modes hook so that the connector modes
> + * are already obtained and EDID is parsed to obtain the monitor
> + * range descriptor information.
> + *
> + * This hook is optional and defined only for the drivers and on
> + * connectors that advertise adaptive sync support.
> + *
> + */
> + void (*get_adaptive_sync_support)(struct drm_connector *connector);
> };
>
> /**
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Reject dumb buffers when driver/device doesn't support modesetting
From: Ville Syrjälä
Currently a driver must not provide a .dumb_create() hook in the
drm_driver structure if it wants to declare dumb buffers as not
supported. So if the same driver wants to support both modeset
and non-modeset devices it would require two distinct drm_driver
structures in order to reject the dumb buffer operations on the
non-modeset devices. That's rather tedious, so let's make life
easier for such drivers by also checking for the DRIVER_MODESET
flag before we declare dumb buffers as supported. Now all the
driver has to do is clear the flag for any device that can't
do modesetting.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client.c| 2 +-
drivers/gpu/drm/drm_crtc_internal.h | 1 +
drivers/gpu/drm/drm_dumb_buffers.c | 12 +---
drivers/gpu/drm/drm_ioctl.c | 2 +-
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 6b0c6ef8b9b3..cf61d87b434d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -80,7 +80,7 @@ int drm_client_init(struct drm_device *dev, struct
drm_client_dev *client,
{
int ret;
- if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
!dev->driver->dumb_create)
+ if (!drm_has_dumb_buffers(dev))
return -EOPNOTSUPP;
if (funcs && !try_module_get(funcs->owner))
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 16f2413403aa..c08ff0b7a509 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -92,6 +92,7 @@ int drm_mode_getresources(struct drm_device *dev,
/* drm_dumb_buffers.c */
+bool drm_has_dumb_buffers(struct drm_device *dev);
int drm_mode_create_dumb(struct drm_device *dev,
struct drm_mode_create_dumb *args,
struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
b/drivers/gpu/drm/drm_dumb_buffers.c
index d18a740fe0f1..9859530362e2 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -55,13 +55,19 @@
* a hardware-specific ioctl to allocate suitable buffer objects.
*/
+bool drm_has_dumb_buffers(struct drm_device *dev)
+{
+ return dev->driver->dumb_create &&
+ drm_core_check_feature(dev, DRIVER_MODESET);
+}
+
int drm_mode_create_dumb(struct drm_device *dev,
struct drm_mode_create_dumb *args,
struct drm_file *file_priv)
{
u32 cpp, stride, size;
- if (!dev->driver->dumb_create)
+ if (!drm_has_dumb_buffers(dev))
return -ENOSYS;
if (!args->width || !args->height || !args->bpp)
return -EINVAL;
@@ -119,7 +125,7 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
{
struct drm_mode_map_dumb *args = data;
- if (!dev->driver->dumb_create)
+ if (!drm_has_dumb_buffers(dev))
return -ENOSYS;
if (dev->driver->dumb_map_offset)
@@ -134,7 +140,7 @@ int drm_mode_mmap_dumb_ioctl(struct drm_device *dev,
int drm_mode_destroy_dumb(struct drm_device *dev, u32 handle,
struct drm_file *file_priv)
{
- if (!dev->driver->dumb_create)
+ if (!drm_has_dumb_buffers(dev))
return -ENOSYS;
if (dev->driver->dumb_destroy)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 9e41972c4bbc..437f1bee6869 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -262,7 +262,7 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
switch (req->capability) {
case DRM_CAP_DUMB_BUFFER:
- if (dev->driver->dumb_create)
+ if (drm_has_dumb_buffers(dev))
req->value = 1;
break;
case DRM_CAP_VBLANK_HIGH_CRTC:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: move files more files into debugfs
== Series Details == Series: drm/i915/gt: move files more files into debugfs URL : https://patchwork.freedesktop.org/series/74834/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gt/debugfs_gt.o drivers/gpu/drm/i915/gt/debugfs_gt.c:16:10: fatal error: uc/debugfs_uc.h: No such file or directory #include "uc/debugfs_uc.h" ^ compilation terminated. scripts/Makefile.build:267: recipe for target 'drivers/gpu/drm/i915/gt/debugfs_gt.o' failed make[4]: *** [drivers/gpu/drm/i915/gt/debugfs_gt.o] Error 1 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:505: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1683: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Wait until the context is finally retired before releasing engines
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin.
To accommodate this, we need to be able to flush the i915_active's
barriers before awaiting on them. However, this also requires us to
ensure the context is unpinned *before* the barrier request can be
signaled, so mark it as a sentinel.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 17 --
drivers/gpu/drm/i915/i915_active.c | 37 -
drivers/gpu/drm/i915/i915_active.h | 3 +-
3 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c0e476fcd1fa..05fed8797d37 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,23 +570,20 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
engines->ctx = i915_gem_context_get(ctx);
for_each_gem_engine(ce, engines, it) {
- struct dma_fence *fence;
- int err = 0;
+ int err;
/* serialises with execbuf */
RCU_INIT_POINTER(ce->gem_context, NULL);
if (!intel_context_pin_if_active(ce))
continue;
- fence = i915_active_fence_get(>timeline->last_request);
- if (fence) {
- err = i915_sw_fence_await_dma_fence(>fence,
- fence, 0,
- GFP_KERNEL);
- dma_fence_put(fence);
- }
+ /* Wait until context is finally scheduled out and retired */
+ err = i915_sw_fence_await_active(>fence,
+>active,
+I915_ACTIVE_AWAIT_ACTIVE |
+I915_ACTIVE_AWAIT_BARRIER);
intel_context_unpin(ce);
- if (err < 0)
+ if (err)
goto kill;
}
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index c4048628188a..da7d35f66dd0 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -518,19 +518,18 @@ int i915_active_wait(struct i915_active *ref)
return 0;
}
-static int __await_active(struct i915_active_fence *active,
- int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+static int __await_fence(struct i915_active_fence *active,
+int (*fn)(void *arg, struct dma_fence *fence),
+void *arg)
{
struct dma_fence *fence;
+ int err;
- if (is_barrier(active)) /* XXX flush the barrier? */
+ if (is_barrier(active))
return 0;
fence = i915_active_fence_get(active);
if (fence) {
- int err;
-
err = fn(arg, fence);
dma_fence_put(fence);
if (err < 0)
@@ -540,6 +539,22 @@ static int __await_active(struct i915_active_fence *active,
return 0;
}
+static int __await_active(struct active_node *it,
+ unsigned int flags,
+ int (*fn)(void *arg, struct dma_fence *fence),
+ void *arg)
+{
+ int err;
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_barrier(it);
+ if (err)
+ return err;
+ }
+
+ return __await_fence(>base, fn, arg);
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
@@ -549,16 +564,17 @@ static int await_active(struct i915_active *ref,
/* We must always wait for the exclusive fence! */
if (rcu_access_pointer(ref->excl.fence)) {
- err = __await_active(>excl, fn, arg);
+ err = __await_fence(>excl, fn, arg);
if (err)
return err;
}
- if (flags & I915_ACTIVE_AWAIT_ALL && i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
+ i915_active_acquire_if_busy(ref)) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
- err = __await_active(>base, fn, arg);
+ err = __await_active(it, flags, fn, arg);
if (err)
break;
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Track runtime spent in unreachable intel_contexts
Quoting Chris Wilson (2020-03-18 14:48:05) > We do have a notification here for the context_retire we could listen to > instead of listening to the request idling. If we use > > i915_sw_fence_await_active(>fence, >>active, >I915_ACTIVE_AWAIT_ALL); > > instead, then the fence will not fire until the final barrier has > executed. > > Tada! It's close. It's still strictly firing on the pulse request signaling, which is currently not guaranteed to be after after the context_out. Although we can arrange that with a sentinel. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Wait until the context is finally retired before releasing engines
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin.
To accommodate this, we need to be able to flush the i915_active's
barriers before awaiting on them.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 17 +--
drivers/gpu/drm/i915/i915_active.c | 34 +++--
drivers/gpu/drm/i915/i915_active.h | 3 +-
3 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c0e476fcd1fa..05fed8797d37 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,23 +570,20 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
engines->ctx = i915_gem_context_get(ctx);
for_each_gem_engine(ce, engines, it) {
- struct dma_fence *fence;
- int err = 0;
+ int err;
/* serialises with execbuf */
RCU_INIT_POINTER(ce->gem_context, NULL);
if (!intel_context_pin_if_active(ce))
continue;
- fence = i915_active_fence_get(>timeline->last_request);
- if (fence) {
- err = i915_sw_fence_await_dma_fence(>fence,
- fence, 0,
- GFP_KERNEL);
- dma_fence_put(fence);
- }
+ /* Wait until context is finally scheduled out and retired */
+ err = i915_sw_fence_await_active(>fence,
+>active,
+I915_ACTIVE_AWAIT_ACTIVE |
+I915_ACTIVE_AWAIT_BARRIER);
intel_context_unpin(ce);
- if (err < 0)
+ if (err)
goto kill;
}
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index c4048628188a..400362912386 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -518,19 +518,18 @@ int i915_active_wait(struct i915_active *ref)
return 0;
}
-static int __await_active(struct i915_active_fence *active,
- int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+static int __await_fence(struct i915_active_fence *active,
+int (*fn)(void *arg, struct dma_fence *fence),
+void *arg)
{
struct dma_fence *fence;
+ int err;
- if (is_barrier(active)) /* XXX flush the barrier? */
+ if (is_barrier(active))
return 0;
fence = i915_active_fence_get(active);
if (fence) {
- int err;
-
err = fn(arg, fence);
dma_fence_put(fence);
if (err < 0)
@@ -540,6 +539,22 @@ static int __await_active(struct i915_active_fence *active,
return 0;
}
+static int __await_active(struct active_node *it,
+ unsigned int flags,
+ int (*fn)(void *arg, struct dma_fence *fence),
+ void *arg)
+{
+ int err;
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_barrier(it);
+ if (err)
+ return err;
+ }
+
+ return __await_fence(>base, fn, arg);
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
@@ -549,16 +564,17 @@ static int await_active(struct i915_active *ref,
/* We must always wait for the exclusive fence! */
if (rcu_access_pointer(ref->excl.fence)) {
- err = __await_active(>excl, fn, arg);
+ err = __await_fence(>excl, fn, arg);
if (err)
return err;
}
- if (flags & I915_ACTIVE_AWAIT_ALL && i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
+ i915_active_acquire_if_busy(ref)) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
- err = __await_active(>base, fn, arg);
+ err = __await_active(it, flags, fn, arg);
if (err)
break;
}
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index b3282ae7913c..9697592235fa 100644
---
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Track runtime spent in unreachable intel_contexts
Quoting Tvrtko Ursulin (2020-03-18 14:38:53)
>
> On 18/03/2020 14:32, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-03-18 14:13:14)
> >>
> >> On 18/03/2020 13:55, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2020-03-18 12:11:34)
> From: Tvrtko Ursulin
>
> As contexts are abandoned we want to remember how much GPU time they used
> (per class) so later we can used it for smarter purposes.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
> drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
> 2 files changed, 17 insertions(+), 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 7c119a3a2cbd..5edf79ed6247 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -257,7 +257,19 @@ static void free_engines_rcu(struct rcu_head *rcu)
> {
> struct i915_gem_engines *engines =
> container_of(rcu, struct i915_gem_engines, rcu);
> + struct i915_gem_context *ctx = engines->ctx;
> + struct i915_gem_engines_iter it;
> + struct intel_context *ce;
> +
> + /* Transfer accumulated runtime to the parent GEM context. */
> + for_each_gem_engine(ce, engines, it) {
> + unsigned int class = ce->engine->uabi_class;
>
> + GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
> + atomic64_add(ce->runtime.total,
> >past_runtime[class]);
> >>>
> >>> Hmm, there's an odd situation where the free_engines_rcu could fire
> >>> before we do the final schedule_out of the context.
> >>>
> >>> GEM_BUG_ON(intel_context_inflight(ce)) to see if that's being too
> >>> paranoid.
> >>
> >> Deja vu.. have I forgotten to move this into intel_context_free while
> >> the purpose of keeping ce->gem_context valid was exactly to enable that.
> >
> > I would rather not have it in gt/ if possible. The delay should be
> > nominal at worst.
>
> But I thought your concern was this can miss the accumulation of the
> last active period due active tracker triggering the rcu cleanup before
> last context save. What do you then recommend?
That is the concern, but it's not a huge concern for me :)
I was tempted just to put a busywait here, rather than couple up a
notification scheme. Although...
We do have a notification here for the context_retire we could listen to
instead of listening to the request idling. If we use
i915_sw_fence_await_active(>fence,
>active,
I915_ACTIVE_AWAIT_ALL);
instead, then the fence will not fire until the final barrier has
executed.
Tada!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/10] drm/i915/hdcp: convert to struct drm_device based logging.
On Tue, 10 Mar 2020, Jani Nikula wrote:
From: Wambui Karuga
Converts various instances of the printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_hdcp.c.
This also involves extracting the drm_i915_private device from the
intel_connector type for use in the macros.
v2 by Jani:
- rebase
Signed-off-by: Wambui Karuga
Signed-off-by: Jani Nikula
Reviewed-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ee0f27ea2810..cd3b686980b2 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1391,6 +1391,7 @@ static
int hdcp2_propagate_stream_management_info(struct intel_connector *connector)
{
struct intel_digital_port *intel_dig_port =
intel_attached_dig_port(connector);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
union {
struct hdcp2_rep_stream_manage stream_manage;
@@ -1431,7 +1432,7 @@ int hdcp2_propagate_stream_management_info(struct
intel_connector *connector)
hdcp->seq_num_m++;
if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
- DRM_DEBUG_KMS("seq_num_m roll over.\n");
+ drm_dbg_kms(>drm, "seq_num_m roll over.\n");
return -1;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915/fbdev: convert to drm_device based logging.
On Tue, 10 Mar 2020, Jani Nikula wrote:
From: Wambui Karuga
Convert various instances of printk based drm logging macros to the
struct drm_device based logging macros in i915/display/intel_fbdev.c.
This also involves extracting the drm_i915_private device from various
intel types.
v2 by Jani:
- fix the final one too
Signed-off-by: Wambui Karuga
Signed-off-by: Jani Nikula
Reviewed-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 96 +-
1 file changed, 55 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 3bc804212a99..bd39eb6a21b8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -146,7 +146,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
if (IS_ERR(obj))
obj = i915_gem_object_create_shmem(dev_priv, size);
if (IS_ERR(obj)) {
- DRM_ERROR("failed to allocate framebuffer\n");
+ drm_err(_priv->drm, "failed to allocate framebuffer\n");
return PTR_ERR(obj);
}
@@ -183,21 +183,23 @@ static int intelfb_create(struct drm_fb_helper *helper,
if (intel_fb &&
(sizes->fb_width > intel_fb->base.width ||
sizes->fb_height > intel_fb->base.height)) {
- DRM_DEBUG_KMS("BIOS fb too small (%dx%d), we require (%dx%d),"
- " releasing it\n",
- intel_fb->base.width, intel_fb->base.height,
- sizes->fb_width, sizes->fb_height);
+ drm_dbg_kms(_priv->drm,
+ "BIOS fb too small (%dx%d), we require (%dx%d),"
+ " releasing it\n",
+ intel_fb->base.width, intel_fb->base.height,
+ sizes->fb_width, sizes->fb_height);
drm_framebuffer_put(_fb->base);
intel_fb = ifbdev->fb = NULL;
}
if (!intel_fb || drm_WARN_ON(dev, !intel_fb_obj(_fb->base))) {
- DRM_DEBUG_KMS("no BIOS fb, allocating a new one\n");
+ drm_dbg_kms(_priv->drm,
+ "no BIOS fb, allocating a new one\n");
ret = intelfb_alloc(helper, sizes);
if (ret)
return ret;
intel_fb = ifbdev->fb;
} else {
- DRM_DEBUG_KMS("re-using BIOS fb\n");
+ drm_dbg_kms(_priv->drm, "re-using BIOS fb\n");
prealloc = true;
sizes->fb_width = intel_fb->base.width;
sizes->fb_height = intel_fb->base.height;
@@ -220,7 +222,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
- DRM_ERROR("Failed to allocate fb_info\n");
+ drm_err(_priv->drm, "Failed to allocate fb_info\n");
ret = PTR_ERR(info);
goto out_unpin;
}
@@ -240,7 +242,8 @@ static int intelfb_create(struct drm_fb_helper *helper,
vaddr = i915_vma_pin_iomap(vma);
if (IS_ERR(vaddr)) {
- DRM_ERROR("Failed to remap framebuffer into virtual memory\n");
+ drm_err(_priv->drm,
+ "Failed to remap framebuffer into virtual memory\n");
ret = PTR_ERR(vaddr);
goto out_unpin;
}
@@ -258,9 +261,9 @@ static int intelfb_create(struct drm_fb_helper *helper,
/* Use default scratch pixmap (info->pixmap.flags = FB_PIXMAP_SYSTEM) */
- DRM_DEBUG_KMS("allocated %dx%d fb: 0x%08x\n",
- ifbdev->fb->base.width, ifbdev->fb->base.height,
- i915_ggtt_offset(vma));
+ drm_dbg_kms(_priv->drm, "allocated %dx%d fb: 0x%08x\n",
+ ifbdev->fb->base.width, ifbdev->fb->base.height,
+ i915_ggtt_offset(vma));
ifbdev->vma = vma;
ifbdev->vma_flags = flags;
@@ -309,6 +312,7 @@ static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
static bool intel_fbdev_init_bios(struct drm_device *dev,
struct intel_fbdev *ifbdev)
{
+ struct drm_i915_private *i915 = to_i915(dev);
struct intel_framebuffer *fb = NULL;
struct drm_crtc *crtc;
struct intel_crtc *intel_crtc;
@@ -321,21 +325,24 @@ static bool intel_fbdev_init_bios(struct drm_device *dev,
intel_crtc = to_intel_crtc(crtc);
if (!crtc->state->active || !obj) {
- DRM_DEBUG_KMS("pipe %c not active or no fb, skipping\n",
- pipe_name(intel_crtc->pipe));
+ drm_dbg_kms(>drm,
+ "pipe %c not active or no fb, skipping\n",
+ pipe_name(intel_crtc->pipe));
Re: [Intel-gfx] [PATCH 02/10] drm/i915/fbc: convert to drm_device based logging macros.
On Tue, 10 Mar 2020, Jani Nikula wrote:
From: Wambui Karuga
This replaces the uses of the printk based drm logging macros with the
struct drm_device based logging macros in i915/display/intel_fbc.c.
This transformation was done using the following coccinelle semantic
patch that matches based on the existence of a drm_i915_private device
pointer:
@@
identifier fn, T;
@@
fn(...,struct drm_i915_private *T,...) {
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
@@
identifier fn, T;
@@
fn(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-DRM_INFO(
+drm_info(>drm,
...)
|
-DRM_ERROR(
+drm_err(>drm,
...)
|
-DRM_WARN(
+drm_warn(>drm,
...)
|
-DRM_DEBUG(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_KMS(
+drm_dbg_kms(>drm,
...)
|
-DRM_DEBUG_DRIVER(
+drm_dbg(>drm,
...)
|
-DRM_DEBUG_ATOMIC(
+drm_dbg_atomic(>drm,
...)
)
...+>
}
New checkpatch warnings were addressed manually.
v2 by Jani:
- also convert pr_info_once to drm based logging
Signed-off-by: Wambui Karuga
Signed-off-by: Jani Nikula
Reviewed-by: Wambui Karuga
---
drivers/gpu/drm/i915/display/intel_fbc.c | 30 ++--
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2d982c322be9..ea0c3ecf7230 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -104,7 +104,7 @@ static void i8xx_fbc_deactivate(struct drm_i915_private
*dev_priv)
/* Wait for compressing bit to clear */
if (intel_de_wait_for_clear(dev_priv, FBC_STATUS,
FBC_STAT_COMPRESSING, 10)) {
- DRM_DEBUG_KMS("FBC idle timed out\n");
+ drm_dbg_kms(_priv->drm, "FBC idle timed out\n");
return;
}
}
@@ -485,7 +485,8 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private
*dev_priv,
if (!ret)
goto err_llb;
else if (ret > 1) {
- DRM_INFO("Reducing the compressed framebuffer size. This may lead to
less power savings than a non-reduced-size. Try to increase stolen memory size if
available in BIOS.\n");
+ drm_info(_priv->drm,
+"Reducing the compressed framebuffer size. This may lead to
less power savings than a non-reduced-size. Try to increase stolen memory size if
available in BIOS.\n");
}
@@ -521,8 +522,9 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private
*dev_priv,
dev_priv->dsm.start + compressed_llb->start);
}
- DRM_DEBUG_KMS("reserved %llu bytes of contiguous stolen space for FBC,
threshold: %d\n",
- fbc->compressed_fb.size, fbc->threshold);
+ drm_dbg_kms(_priv->drm,
+ "reserved %llu bytes of contiguous stolen space for FBC,
threshold: %d\n",
+ fbc->compressed_fb.size, fbc->threshold);
return 0;
@@ -531,7 +533,7 @@ static int intel_fbc_alloc_cfb(struct drm_i915_private
*dev_priv,
i915_gem_stolen_remove_node(dev_priv, >compressed_fb);
err_llb:
if (drm_mm_initialized(_priv->mm.stolen))
- pr_info_once("drm: not enough stolen space for compressed buffer
(need %d more bytes), disabling. Hint: you may be able to increase stolen memory size in
the BIOS to avoid this.\n", size);
+ drm_info_once(_priv->drm, "not enough stolen space for
compressed buffer (need %d more bytes), disabling. Hint: you may be able to increase stolen
memory size in the BIOS to avoid this.\n", size);
return -ENOSPC;
}
@@ -945,7 +947,8 @@ static void __intel_fbc_disable(struct drm_i915_private
*dev_priv)
drm_WARN_ON(_priv->drm, !fbc->crtc);
drm_WARN_ON(_priv->drm, fbc->active);
- DRM_DEBUG_KMS("Disabling FBC on pipe %c\n", pipe_name(crtc->pipe));
+ drm_dbg_kms(_priv->drm, "Disabling FBC on pipe %c\n",
+ pipe_name(crtc->pipe));
__intel_fbc_cleanup_cfb(dev_priv);
@@ -1173,7 +1176,8 @@ void intel_fbc_enable(struct intel_atomic_state *state,
else
cache->gen9_wa_cfb_stride = 0;
- DRM_DEBUG_KMS("Enabling FBC on pipe %c\n", pipe_name(crtc->pipe));
+ drm_dbg_kms(_priv->drm, "Enabling FBC on pipe %c\n",
+ pipe_name(crtc->pipe));
fbc->no_fbc_reason = "FBC enabled but not active yet\n";
fbc->crtc = crtc;
@@ -1235,7 +1239,7 @@ static void intel_fbc_underrun_work_fn(struct work_struct
*work)
if (fbc->underrun_detected || !fbc->crtc)
goto out;
- DRM_DEBUG_KMS("Disabling FBC due to FIFO underrun.\n");
+ drm_dbg_kms(_priv->drm, "Disabling FBC due to FIFO underrun.\n");
fbc->underrun_detected =
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Track runtime spent in unreachable intel_contexts
On 18/03/2020 14:32, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-18 14:13:14)
On 18/03/2020 13:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-18 12:11:34)
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
2 files changed, 17 insertions(+), 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 7c119a3a2cbd..5edf79ed6247 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -257,7 +257,19 @@ static void free_engines_rcu(struct rcu_head *rcu)
{
struct i915_gem_engines *engines =
container_of(rcu, struct i915_gem_engines, rcu);
+ struct i915_gem_context *ctx = engines->ctx;
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ /* Transfer accumulated runtime to the parent GEM context. */
+ for_each_gem_engine(ce, engines, it) {
+ unsigned int class = ce->engine->uabi_class;
+ GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
+ atomic64_add(ce->runtime.total, >past_runtime[class]);
Hmm, there's an odd situation where the free_engines_rcu could fire
before we do the final schedule_out of the context.
GEM_BUG_ON(intel_context_inflight(ce)) to see if that's being too
paranoid.
Deja vu.. have I forgotten to move this into intel_context_free while
the purpose of keeping ce->gem_context valid was exactly to enable that.
I would rather not have it in gt/ if possible. The delay should be
nominal at worst.
But I thought your concern was this can miss the accumulation of the
last active period due active tracker triggering the rcu cleanup before
last context save. What do you then recommend?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
> -Original Message-
> From: Maarten Lankhorst
> Sent: Wednesday, March 18, 2020 5:46 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä ; Kai Vehmanen
> ; Khor, Swee Aun
> Subject: Re: [PATCH] drm/i915/display: Trigger Modeset at boot for audio
> codec init
>
> Op 18-03-2020 om 12:30 schreef Uma Shankar:
> > If external monitors are connected during boot up, driver uses the
> > same mode programmed by BIOS and avoids a full modeset.
> > This results in display audio codec left uninitialized and display
> > audio fails to work till user triggers a modeset.
> >
> > This patch fixes the same by triggering a modeset at boot.
> >
> > Cc: Ville Syrjälä
> > Cc: Maarten Lankhorst
> > Cc: Kai Vehmanen
> > Signed-off-by: Uma Shankar
> > Signed-off-by: SweeAun Khor
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 4
> > drivers/gpu/drm/i915/display/intel_display.c | 8
> > drivers/gpu/drm/i915/i915_drv.h | 3 +++
> > 3 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 73d0f4648c06..ba380afa73a6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3704,6 +3704,10 @@ static void intel_ddi_update_pipe(struct
> > intel_encoder
> *encoder,
> > const struct intel_crtc_state *crtc_state,
> > const struct drm_connector_state *conn_state)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +
> > + /* Clear the bootflag */
> > + dev_priv->bootflag = false;
> >
> > if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state); diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8f23c4d51c33..a1487539495f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -14751,6 +14751,10 @@ static int intel_atomic_check(struct drm_device
> *dev,
> > if (new_crtc_state->hw.mode.private_flags !=
> > old_crtc_state->hw.mode.private_flags)
> > new_crtc_state->uapi.mode_changed = true;
> > +
> > + /* Set mode_change to init audio code once at boot */
> > + if (dev_priv->bootflag && new_crtc_state->hw.active)
> > + new_crtc_state->uapi.mode_changed = true;
> > }
> >
> > ret = drm_atomic_helper_check_modeset(dev, >base); @@
> > -17655,11 +17659,15 @@ static void intel_update_fdi_pll_freq(struct
> > drm_i915_private *dev_priv)
> >
> > static int intel_initial_commit(struct drm_device *dev) {
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > struct drm_atomic_state *state = NULL;
> > struct drm_modeset_acquire_ctx ctx;
> > struct intel_crtc *crtc;
> > int ret = 0;
> >
> > + /* Set Flag to trigger modeset for audio codec init */
> > + dev_priv->bootflag = true;
> > +
> > state = drm_atomic_state_alloc(dev);
> > if (!state)
> > return -ENOMEM;
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index a7ea1d855359..207196f9632b
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1210,6 +1210,9 @@ struct drm_i915_private {
> > * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > * will be rejected. Instead look for a better place.
> > */
> > +
> > + /* Flag to trigger modeset for Audio codec init once during boot */
> > + bool bootflag;
> > };
> >
> > static inline struct drm_i915_private *to_i915(const struct
> > drm_device *dev)
>
> This is not going to help. We read out the has_audio flag now, the only thing
> we miss
> is to enable the audio codec. This should be done after the first detect(),
> in the
> manner which I described to get the correct eld values.
Hi Maarten,
At the time of sanitize, we don't have edid so has_audio flag will not be set.
Also codec_enable
needs encoder, crtc_state, conn_state. All these are not there as part of
detect callbacks.
With current approach, we force a modeset just during boot and then reset the
flag so that normal
operations don't get affected.
Regards,
Uma Shankar
> ~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: move files more files into debugfs
Quoting Andi Shyti (2020-03-18 14:13:13) > Hi Chris, > > On Wed, Mar 18, 2020 at 02:06:07PM +, Chris Wilson wrote: > > Quoting Andi Shyti (2020-03-18 13:58:37) > > > From: Andi Shyti > > > > > > The following interfaces: > > > > > > i915_wedged > > > i915_forcewake_user > > > > Ok. > > > > > i915_gem_interrupt > > > > More display really, not actually the primary info dump for GEM or GT. > > s/gem/ or just delete it, if we're not using, and display isn't, it's > > pretty pointless. > > The original is left in the main directory, I isolated the engine > related information and printed just them withot any display > information. Boooring. :) We put the interrupt state in with the various features we want to debug. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Expose per-engine client busyness
Quoting Tvrtko Ursulin (2020-03-18 14:15:31)
>
> On 18/03/2020 14:00, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-03-18 12:11:37)
> >> +static u64
> >> +pphwsp_busy_add(struct i915_gem_context *ctx, unsigned int class)
> >> +{
> >> + struct i915_gem_engines *engines = rcu_dereference(ctx->engines);
> >> + struct i915_gem_engines_iter it;
> >> + struct intel_context *ce;
> >> + u64 total = 0;
> >> +
> >> + for_each_gem_engine(ce, engines, it) {
> >> + if (ce->engine->uabi_class == class)
> >> + total += ce->runtime.total;
> >> + }
> >> +
> >> + return total;
> >> +}
> >> +
> >> +static ssize_t
> >> +show_client_busy(struct device *kdev, struct device_attribute *attr, char
> >> *buf)
> >> +{
> >> + struct i915_engine_busy_attribute *i915_attr =
> >> + container_of(attr, typeof(*i915_attr), attr);
> >> + unsigned int class = i915_attr->engine_class;
> >> + struct i915_drm_client *client = i915_attr->client;
> >> + u64 total = atomic64_read(>past_runtime[class]);
> >> + struct list_head *list = >ctx_list;
> >> + struct i915_gem_context *ctx;
> >> +
> >> + rcu_read_lock();
> >> + list_for_each_entry_rcu(ctx, list, client_link) {
> >> + total += atomic64_read(>past_runtime[class]);
> >> + total += pphwsp_busy_add(ctx, class);
> >
> > Hmm. I would like to have some GEM context agnosticism here. At the
> > moment, all I have to offer is
> >
> > struct client_runtime {
> > struct list_head client_link;
> > atomic64_t past_runtime;
> > u64 (*cur_runtime)(struct client_runtime *);
> > };
>
> What exactly do you mean here? Who keeps a list and of what and what
> does the vfunc do?
This is what you've added to GEM context. Here in i915/i915_drm_client.c
we shouldn't have to know about i915/gem/i915_gem_context internals. So
the GEM context registers its client_runtime (by coupling that into the
list).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Track runtime spent in unreachable intel_contexts
Quoting Tvrtko Ursulin (2020-03-18 14:13:14)
>
> On 18/03/2020 13:55, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-03-18 12:11:34)
> >> From: Tvrtko Ursulin
> >>
> >> As contexts are abandoned we want to remember how much GPU time they used
> >> (per class) so later we can used it for smarter purposes.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
> >> drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
> >> 2 files changed, 17 insertions(+), 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 7c119a3a2cbd..5edf79ed6247 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> @@ -257,7 +257,19 @@ static void free_engines_rcu(struct rcu_head *rcu)
> >> {
> >> struct i915_gem_engines *engines =
> >> container_of(rcu, struct i915_gem_engines, rcu);
> >> + struct i915_gem_context *ctx = engines->ctx;
> >> + struct i915_gem_engines_iter it;
> >> + struct intel_context *ce;
> >> +
> >> + /* Transfer accumulated runtime to the parent GEM context. */
> >> + for_each_gem_engine(ce, engines, it) {
> >> + unsigned int class = ce->engine->uabi_class;
> >>
> >> + GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
> >> + atomic64_add(ce->runtime.total, >past_runtime[class]);
> >
> > Hmm, there's an odd situation where the free_engines_rcu could fire
> > before we do the final schedule_out of the context.
> >
> > GEM_BUG_ON(intel_context_inflight(ce)) to see if that's being too
> > paranoid.
>
> Deja vu.. have I forgotten to move this into intel_context_free while
> the purpose of keeping ce->gem_context valid was exactly to enable that.
I would rather not have it in gt/ if possible. The delay should be
nominal at worst.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: move files more files into debugfs
Hi Chris, On Wed, Mar 18, 2020 at 02:06:07PM +, Chris Wilson wrote: > Quoting Andi Shyti (2020-03-18 13:58:37) > > From: Andi Shyti > > > > The following interfaces: > > > > i915_wedged > > i915_forcewake_user > > Ok. > > > i915_gem_interrupt > > More display really, not actually the primary info dump for GEM or GT. > s/gem/ or just delete it, if we're not using, and display isn't, it's > pretty pointless. The original is left in the main directory, I isolated the engine related information and printed just them withot any display information. > > i915_gem_drop_caches > > This is definitely an outer layer only debug iface. I don't think we > really want this to proliferate. true, there were a few pm operations that's why I thought that it might fit, we can remove it Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prefer '%ps' for printing function symbol names
== Series Details == Series: drm/i915: Prefer '%ps' for printing function symbol names URL : https://patchwork.freedesktop.org/series/74831/ State : success == Summary == CI Bug Log - changes from CI_DRM_8147 -> Patchwork_17007 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/index.html Known issues Here are the changes found in Patchwork_17007 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#189]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/fi-icl-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/fi-icl-dsi/igt@i915_pm_...@module-reload.html Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][3] ([i915#323]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8147/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 Participating hosts (43 -> 42) -- Additional (4): fi-skl-lmem fi-cfl-8109u fi-bwr-2160 fi-snb-2600 Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8147 -> Patchwork_17007 CI-20190529: 20190529 CI_DRM_8147: cb6e45333c342a56b74e6b935ee47ee55a28d53e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5521: 9c74586ea8e051d074864bce72baf5a688a0a437 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17007: 2761ea5b840e6f033e9a36541b5b378f0c7e5099 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2761ea5b840e drm/i915: Prefer '%ps' for printing function symbol names == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17007/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Expose per-engine client busyness
On 18/03/2020 14:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-18 12:11:37)
+static u64
+pphwsp_busy_add(struct i915_gem_context *ctx, unsigned int class)
+{
+ struct i915_gem_engines *engines = rcu_dereference(ctx->engines);
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+ u64 total = 0;
+
+ for_each_gem_engine(ce, engines, it) {
+ if (ce->engine->uabi_class == class)
+ total += ce->runtime.total;
+ }
+
+ return total;
+}
+
+static ssize_t
+show_client_busy(struct device *kdev, struct device_attribute *attr, char *buf)
+{
+ struct i915_engine_busy_attribute *i915_attr =
+ container_of(attr, typeof(*i915_attr), attr);
+ unsigned int class = i915_attr->engine_class;
+ struct i915_drm_client *client = i915_attr->client;
+ u64 total = atomic64_read(>past_runtime[class]);
+ struct list_head *list = >ctx_list;
+ struct i915_gem_context *ctx;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ctx, list, client_link) {
+ total += atomic64_read(>past_runtime[class]);
+ total += pphwsp_busy_add(ctx, class);
Hmm. I would like to have some GEM context agnosticism here. At the
moment, all I have to offer is
struct client_runtime {
struct list_head client_link;
atomic64_t past_runtime;
u64 (*cur_runtime)(struct client_runtime *);
};
What exactly do you mean here? Who keeps a list and of what and what
does the vfunc do?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: move files more files into debugfs
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
i915_gem_drop_caches
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
gt
|
+-- drop_caches
|
+-- forcewake_user
|
+-- interrupt_info_show
|
+-- wedge
Signed-off-by: Andi Shyti
---
Hi,
this patch is the first of a series that aims to refactor the
debugfs structure in the i915. Some changes will affect the
debugfs framework as well.
Andi
drivers/gpu/drm/i915/gt/debugfs_engines.c | 54 +
drivers/gpu/drm/i915/gt/debugfs_gt.c | 140 +-
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 32 +
3 files changed, 225 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_engines.c
b/drivers/gpu/drm/i915/gt/debugfs_engines.c
index 5e3725e62241..0d0fee1a166d 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_engines.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_engines.c
@@ -11,6 +11,59 @@
#include "i915_drv.h" /* for_each_engine! */
#include "intel_engine.h"
+static int interrupt_info_show(struct seq_file *m, void *data)
+{
+ struct intel_gt *gt = m->private;
+ struct intel_uncore *uncore = gt->uncore;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ intel_wakeref_t wakeref;
+
+ wakeref = intel_runtime_pm_get(uncore->rpm);
+
+ if (INTEL_GEN(gt->i915) >= 11) {
+ seq_printf(m, "RCS Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_RCS0_RSVD_INTR_MASK));
+ seq_printf(m, "BCS Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_BCS_RSVD_INTR_MASK));
+ seq_printf(m, "VCS0/VCS1 Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_VCS0_VCS1_INTR_MASK));
+ seq_printf(m, "VCS2/VCS3 Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_VCS2_VCS3_INTR_MASK));
+ seq_printf(m, "VECS0/VECS1 Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_VECS0_VECS1_INTR_MASK));
+ seq_printf(m, "GUC/SG Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_GUC_SG_INTR_MASK));
+ seq_printf(m, "GPM/WGBOXPERF Intr Mask: %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_GPM_WGBOXPERF_INTR_MASK));
+ seq_printf(m, "Crypto Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_CRYPTO_RSVD_INTR_MASK));
+ seq_printf(m, "Gunit/CSME Intr Mask:\t %08x\n",
+ intel_uncore_read(gt->uncore,
+GEN11_GUNIT_CSME_INTR_MASK));
+
+ } else if (INTEL_GEN(gt->i915) >= 6) {
+ for_each_engine(engine, gt, id) {
+ seq_printf(m,
+ "Graphics Interrupt mask (%s): %08x\n",
+ engine->name, ENGINE_READ(engine, RING_IMR));
+ }
+ }
+
+ intel_runtime_pm_put(uncore->rpm, wakeref);
+
+ return 0;
+}
+DEFINE_GT_DEBUGFS_ATTRIBUTE(interrupt_info);
+
static int engines_show(struct seq_file *m, void *data)
{
struct intel_gt *gt = m->private;
@@ -29,6 +82,7 @@ DEFINE_GT_DEBUGFS_ATTRIBUTE(engines);
void debugfs_engines_register(struct intel_gt *gt, struct dentry *root)
{
static const struct debugfs_gt_file files[] = {
+ { "interrupt_info_show", _info_fops, NULL },
{ "engines", _fops },
};
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt.c
b/drivers/gpu/drm/i915/gt/debugfs_gt.c
index fcbc57e226c3..1fc960ebba06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt.c
@@ -5,12 +5,148 @@
*/
#include
+#include
#include "debugfs_engines.h"
#include "debugfs_gt.h"
#include "debugfs_gt_pm.h"
-#include "uc/debugfs_uc.h"
#include "i915_drv.h"
+#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
+#include "uc/debugfs_uc.h"
+
+#define DROP_UNBOUND BIT(0)
+#define DROP_BOUND BIT(1)
+#define DROP_RETIREBIT(2)
+#define DROP_ACTIVEBIT(3)
+#define DROP_FREED BIT(4)
+#define DROP_SHRINK_ALLBIT(5)
+#define DROP_IDLE BIT(6)
+#define DROP_RESET_ACTIVE BIT(7)
+#define DROP_RESET_SEQNO BIT(8)
+#define DROP_RCU BIT(9)
+#define DROP_ALL (DROP_UNBOUND | \
+ DROP_BOUND| \
+ DROP_RETIRE | \
+
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Track runtime spent in unreachable intel_contexts
On 18/03/2020 13:55, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-18 12:11:34)
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
2 files changed, 17 insertions(+), 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 7c119a3a2cbd..5edf79ed6247 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -257,7 +257,19 @@ static void free_engines_rcu(struct rcu_head *rcu)
{
struct i915_gem_engines *engines =
container_of(rcu, struct i915_gem_engines, rcu);
+ struct i915_gem_context *ctx = engines->ctx;
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ /* Transfer accumulated runtime to the parent GEM context. */
+ for_each_gem_engine(ce, engines, it) {
+ unsigned int class = ce->engine->uabi_class;
+ GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
+ atomic64_add(ce->runtime.total, >past_runtime[class]);
Hmm, there's an odd situation where the free_engines_rcu could fire
before we do the final schedule_out of the context.
GEM_BUG_ON(intel_context_inflight(ce)) to see if that's being too
paranoid.
Deja vu.. have I forgotten to move this into intel_context_free while
the purpose of keeping ce->gem_context valid was exactly to enable that.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
drm-misc-fixes-2020-03-18-1: One more fix for v5.6: - drm/lease: fix WARNING in idr_destroy The following changes since commit 1b79cfd99ff5127e6a143767b51694a527b3ea38: drm: kirin: Revert "Fix for hikey620 display offset problem" (2020-03-04 13:29:05 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-03-18-1 for you to fetch changes up to b216a8e7908cd750550c0480cf7d2b3a37f06954: drm/lease: fix WARNING in idr_destroy (2020-03-18 14:42:18 +0100) One more fix for v5.6: - drm/lease: fix WARNING in idr_destroy Arnd Bergmann (1): drm/komeda: mark PM functions as __maybe_unused Gerd Hoffmann (1): drm/bochs: downgrade pci_request_region failure from error to warning Jernej Skrabec (1): drm/bridge: dw-hdmi: fix AVI frame colorimetry Qiujun Huang (1): drm/lease: fix WARNING in idr_destroy drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 4 +-- drivers/gpu/drm/bochs/bochs_hw.c| 6 ++-- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 46 ++--- drivers/gpu/drm/drm_lease.c | 3 +- 4 files changed, 32 insertions(+), 27 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: move files more files into debugfs
Quoting Andi Shyti (2020-03-18 13:58:37) > From: Andi Shyti > > The following interfaces: > > i915_wedged > i915_forcewake_user Ok. > i915_gem_interrupt More display really, not actually the primary info dump for GEM or GT. s/gem/ or just delete it, if we're not using, and display isn't, it's pretty pointless. > i915_gem_drop_caches This is definitely an outer layer only debug iface. I don't think we really want this to proliferate. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
> -Original Message-
> From: Gupta, Anshuman
> Sent: Wednesday, March 18, 2020 5:37 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; Khor, Swee Aun
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot
> for audio
> codec init
>
> On 2020-03-18 at 17:00:09 +0530, Uma Shankar wrote:
> > If external monitors are connected during boot up, driver uses the
> > same mode programmed by BIOS and avoids a full modeset.
> > This results in display audio codec left uninitialized and display
> > audio fails to work till user triggers a modeset.
> >
> > This patch fixes the same by triggering a modeset at boot.
> >
> > Cc: Ville Syrjälä
> > Cc: Maarten Lankhorst
> > Cc: Kai Vehmanen
> > Signed-off-by: Uma Shankar
> > Signed-off-by: SweeAun Khor
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 4
> > drivers/gpu/drm/i915/display/intel_display.c | 8
> > drivers/gpu/drm/i915/i915_drv.h | 3 +++
> > 3 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 73d0f4648c06..ba380afa73a6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3704,6 +3704,10 @@ static void intel_ddi_update_pipe(struct
> > intel_encoder
> *encoder,
> > const struct intel_crtc_state *crtc_state,
> > const struct drm_connector_state *conn_state)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +
> > + /* Clear the bootflag */
> > + dev_priv->bootflag = false;
> >
> > if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> > intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state); diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8f23c4d51c33..a1487539495f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -14751,6 +14751,10 @@ static int intel_atomic_check(struct drm_device
> *dev,
> > if (new_crtc_state->hw.mode.private_flags !=
> > old_crtc_state->hw.mode.private_flags)
> > new_crtc_state->uapi.mode_changed = true;
> > +
> > + /* Set mode_change to init audio code once at boot */
> > + if (dev_priv->bootflag && new_crtc_state->hw.active)
> > + new_crtc_state->uapi.mode_changed = true;
> I would prefer to compute crtc_state->has_audio in compute_config at boot up
> and
> then force a full modeset in intel_pipe_config_compare(), this way atomically
> we
> can force the full modeset on boot up.
Unfortunately the audio state is not yet detected here at bootup (read of EDID
not yet done),
hence EDID data is not available. We tried to explore this path but this didn't
worked out. We
forced modeset at intel_initial_commit but due to the above reason, things
didn't worked out.
Regards,
Uma Shankar
> Thanks,
> Anshuman Gupta.
> > }
> >
> > ret = drm_atomic_helper_check_modeset(dev, >base); @@
> > -17655,11 +17659,15 @@ static void intel_update_fdi_pll_freq(struct
> > drm_i915_private *dev_priv)
> >
> > static int intel_initial_commit(struct drm_device *dev) {
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > struct drm_atomic_state *state = NULL;
> > struct drm_modeset_acquire_ctx ctx;
> > struct intel_crtc *crtc;
> > int ret = 0;
> >
> > + /* Set Flag to trigger modeset for audio codec init */
> > + dev_priv->bootflag = true;
> > +
> > state = drm_atomic_state_alloc(dev);
> > if (!state)
> > return -ENOMEM;
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index a7ea1d855359..207196f9632b
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1210,6 +1210,9 @@ struct drm_i915_private {
> > * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
> > * will be rejected. Instead look for a better place.
> > */
> > +
> > + /* Flag to trigger modeset for Audio codec init once during boot */
> > + bool bootflag;
> > };
> >
> > static inline struct drm_i915_private *to_i915(const struct
> > drm_device *dev)
> > --
> > 2.22.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/10] drm/i915: Expose per-engine client busyness
Quoting Tvrtko Ursulin (2020-03-18 12:11:37)
> +static u64
> +pphwsp_busy_add(struct i915_gem_context *ctx, unsigned int class)
> +{
> + struct i915_gem_engines *engines = rcu_dereference(ctx->engines);
> + struct i915_gem_engines_iter it;
> + struct intel_context *ce;
> + u64 total = 0;
> +
> + for_each_gem_engine(ce, engines, it) {
> + if (ce->engine->uabi_class == class)
> + total += ce->runtime.total;
> + }
> +
> + return total;
> +}
> +
> +static ssize_t
> +show_client_busy(struct device *kdev, struct device_attribute *attr, char
> *buf)
> +{
> + struct i915_engine_busy_attribute *i915_attr =
> + container_of(attr, typeof(*i915_attr), attr);
> + unsigned int class = i915_attr->engine_class;
> + struct i915_drm_client *client = i915_attr->client;
> + u64 total = atomic64_read(>past_runtime[class]);
> + struct list_head *list = >ctx_list;
> + struct i915_gem_context *ctx;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(ctx, list, client_link) {
> + total += atomic64_read(>past_runtime[class]);
> + total += pphwsp_busy_add(ctx, class);
Hmm. I would like to have some GEM context agnosticism here. At the
moment, all I have to offer is
struct client_runtime {
struct list_head client_link;
atomic64_t past_runtime;
u64 (*cur_runtime)(struct client_runtime *);
};
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/10] drm/i915: Track runtime spent in closed GEM contexts
Quoting Tvrtko Ursulin (2020-03-18 12:11:35)
> From: Tvrtko Ursulin
>
> As GEM contexts are closed we want to have the DRM client remember how
> much GPU time they used (per class) so later we can used it for smarter
> purposes.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 12 +++-
> drivers/gpu/drm/i915/i915_drm_client.h | 7 +++
> 2 files changed, 18 insertions(+), 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 5edf79ed6247..912375fb8a3b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -355,8 +355,18 @@ static void i915_gem_context_free(struct
> i915_gem_context *ctx)
>
> GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
>
> - if (client)
> + if (client) {
> + unsigned int i;
> +
> + /* Transfer accumulated runtime to the parent drm client. */
> + BUILD_BUG_ON(ARRAY_SIZE(client->past_runtime) !=
> +ARRAY_SIZE(ctx->past_runtime));
> + for (i = 0; i < ARRAY_SIZE(client->past_runtime); i++)
> + atomic64_add(atomic64_read(>past_runtime[i]),
> +>past_runtime[i]);
> +
> i915_drm_client_put(client);
> + }
Ok, order looks good.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Track runtime spent in unreachable intel_contexts
Quoting Tvrtko Ursulin (2020-03-18 12:11:34)
> From: Tvrtko Ursulin
>
> As contexts are abandoned we want to remember how much GPU time they used
> (per class) so later we can used it for smarter purposes.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
> drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
> 2 files changed, 17 insertions(+), 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 7c119a3a2cbd..5edf79ed6247 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -257,7 +257,19 @@ static void free_engines_rcu(struct rcu_head *rcu)
> {
> struct i915_gem_engines *engines =
> container_of(rcu, struct i915_gem_engines, rcu);
> + struct i915_gem_context *ctx = engines->ctx;
> + struct i915_gem_engines_iter it;
> + struct intel_context *ce;
> +
> + /* Transfer accumulated runtime to the parent GEM context. */
> + for_each_gem_engine(ce, engines, it) {
> + unsigned int class = ce->engine->uabi_class;
>
> + GEM_BUG_ON(class >= ARRAY_SIZE(ctx->past_runtime));
> + atomic64_add(ce->runtime.total, >past_runtime[class]);
Hmm, there's an odd situation where the free_engines_rcu could fire
before we do the final schedule_out of the context.
GEM_BUG_ON(intel_context_inflight(ce)) to see if that's being too
paranoid.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm/i915: Use explicit flag to mark unreachable intel_context
On 18/03/2020 13:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-03-18 12:11:33)
From: Tvrtko Ursulin
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9afc60ab95e0..7c119a3a2cbd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -579,7 +579,8 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
int err = 0;
/* serialises with execbuf */
- RCU_INIT_POINTER(ce->gem_context, NULL);
+ set_bit(INTEL_CONTEXT_CLOSED, >flags);
+
if (!intel_context_pin_if_active(ce))
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..875da020d6c8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2316,7 +2316,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
prev = __i915_request_commit(rq);
/* Check that the context wasn't destroyed before submission */
- if (likely(rcu_access_pointer(eb->context->gem_context))) {
+ if (likely(!test_bit(INTEL_CONTEXT_CLOSED, >context->flags))) {
attr = eb->gem_context->sched;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0f3b68b95c56..d5925c25f109 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -66,6 +66,7 @@ struct intel_context {
#define CONTEXT_BANNED 4
#define CONTEXT_FORCE_SINGLE_SUBMISSION5
#define CONTEXT_NOPREEMPT 6
+#define INTEL_CONTEXT_CLOSED 7
Trying to start a flame war? :)
No, but CONTEXT_ namespace is overloaded between here and GEM context. I
propose we prefix one of them all with something.
Reviewed-by: Chris Wilson
With this flag, we can start banning contexts after a GPU hang on a
closed context _again_. That might justify applying immediately.
Hm okay.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/10] drm/i915: Use explicit flag to mark unreachable intel_context
Quoting Tvrtko Ursulin (2020-03-18 12:11:33)
> From: Tvrtko Ursulin
>
> I need to keep the GEM context around a bit longer so adding an explicit
> flag for syncing execbuf with closed/abandonded contexts.
>
> v2:
> * Use already available context flags. (Chris)
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c| 3 ++-
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 9afc60ab95e0..7c119a3a2cbd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -579,7 +579,8 @@ static void engines_idle_release(struct i915_gem_context
> *ctx,
> int err = 0;
>
> /* serialises with execbuf */
> - RCU_INIT_POINTER(ce->gem_context, NULL);
> + set_bit(INTEL_CONTEXT_CLOSED, >flags);
> +
> if (!intel_context_pin_if_active(ce))
> continue;
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d3f4f28e9468..875da020d6c8 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2316,7 +2316,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
> prev = __i915_request_commit(rq);
>
> /* Check that the context wasn't destroyed before submission */
> - if (likely(rcu_access_pointer(eb->context->gem_context))) {
> + if (likely(!test_bit(INTEL_CONTEXT_CLOSED, >context->flags))) {
> attr = eb->gem_context->sched;
>
> /*
> diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> b/drivers/gpu/drm/i915/gt/intel_context_types.h
> index 0f3b68b95c56..d5925c25f109 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> @@ -66,6 +66,7 @@ struct intel_context {
> #define CONTEXT_BANNED 4
> #define CONTEXT_FORCE_SINGLE_SUBMISSION5
> #define CONTEXT_NOPREEMPT 6
> +#define INTEL_CONTEXT_CLOSED 7
Trying to start a flame war? :)
Reviewed-by: Chris Wilson
With this flag, we can start banning contexts after a GPU hang on a
closed context _again_. That might justify applying immediately.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Make GEM contexts track DRM clients
Quoting Tvrtko Ursulin (2020-03-18 12:11:32) > From: Tvrtko Ursulin > > If we make GEM contexts keep a reference to i915_drm_client for the whole > of their lifetime, we can consolidate the current task pid and name usage > by getting it from the client. > > v2: > * Don't bother supporting selftests contexts from debugfs. (Chris) > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Prefer '%ps' for printing function symbol names
%pS includes the offset, which is useful for return addresses but noise
when we are pretty printing a known (and expected) function entry point.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index a3d38e089b6e..7daf81f55c90 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -421,7 +421,7 @@ static void timer_i915_sw_fence_wake(struct timer_list *t)
if (!fence)
return;
- pr_notice("Asynchronous wait on fence %s:%s:%llx timed out
(hint:%pS)\n",
+ pr_notice("Asynchronous wait on fence %s:%s:%llx timed out
(hint:%ps)\n",
cb->dma->ops->get_driver_name(cb->dma),
cb->dma->ops->get_timeline_name(cb->dma),
cb->dma->seqno,
diff --git a/drivers/gpu/drm/i915/selftests/i915_active.c
b/drivers/gpu/drm/i915/selftests/i915_active.c
index 68bbb1580162..54080fb4af4b 100644
--- a/drivers/gpu/drm/i915/selftests/i915_active.c
+++ b/drivers/gpu/drm/i915/selftests/i915_active.c
@@ -277,7 +277,7 @@ static struct intel_engine_cs *node_to_barrier(struct
active_node *it)
void i915_active_print(struct i915_active *ref, struct drm_printer *m)
{
- drm_printf(m, "active %pS:%pS\n", ref->active, ref->retire);
+ drm_printf(m, "active %ps:%ps\n", ref->active, ref->retire);
drm_printf(m, "\tcount: %d\n", atomic_read(>count));
drm_printf(m, "\tpreallocated barriers? %s\n",
yesno(!llist_empty(>preallocated_barriers)));
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index f89d9c42f1fa..7ac9616de9d8 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -1233,7 +1233,7 @@ static int live_parallel_engines(void *arg)
struct igt_live_test t;
unsigned int idx;
- snprintf(name, sizeof(name), "%pS", fn);
+ snprintf(name, sizeof(name), "%ps", fn);
err = igt_live_test_begin(, i915, __func__, name);
if (err)
break;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
On Fri, Mar 06, 2020 at 01:32:12AM +, Souza, Jose wrote:
> On Thu, 2020-02-20 at 19:26 +0200, Ville Syrjälä wrote:
> > On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza
> > wrote:
> > > dGFX have local memory so it do not have aperture and do not
> > > support
> > > CPU fences but even for iGFX it have a small number of fences.
> > >
> > > As replacement for fences to track frontbuffer modifications by CPU
> > > we have a software tracking that is already in used by FBC and PSR.
> > > PSR don't support fences so it shows that this tracking is
> > > reliable.
> > >
> > > So lets make fences a nice-to-have to activate FBC for GEN9+, this
> > > will allow us to enable FBC for dGFXs and iGFXs even when there is
> > > no
> > > available fence.
> > >
> > > We do not set fences to rotated planes but FBC only have
> > > restrictions
> > > against 16bpp, so adding it here.
> > >
> > > Also adding a new check for the tiling format, fences are only set
> > > to X and Y tiled planes but again FBC don't have any restrictions
> > > against tiling so adding linear as supported as well, other formats
> > > should be added after tested but IGT only supports drawing in thse
> > > 3 formats.
> > >
> > > intel_fbc_hw_tracking_covers_screen() maybe can also have the same
> > > treatment as fences but BSpec is not clear if the size limitation
> > > is
> > > for hardware tracking or general use of FBC and I don't have a 5K
> > > display to test it, so keeping as is for safety.
> > >
> > > v2:
> > > - Added tiling and pixel format rotation checks
> > > - Changed the GEN version not requiring fences to 11 from 9, DDX
> > > needs some changes but it don't have support for GEN11+
> > >
> > > v3:
> > > - Changed back to GEN9+
> > > - Moved GEN test to inside of tiling_is_valid()
> > >
> > > Cc: Daniel Vetter
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Ville Syrjälä
> > > Signed-off-by: José Roberto de Souza
> > > ---
> > > drivers/gpu/drm/i915/display/intel_fbc.c | 45
> > >
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > 2 files changed, 39 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > index 1d76e3646a25..a0d1d661a006 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > @@ -585,7 +585,7 @@ static bool stride_is_valid(struct
> > > drm_i915_private *dev_priv,
> > > }
> > >
> > > static bool pixel_format_is_valid(struct drm_i915_private
> > > *dev_priv,
> > > - u32 pixel_format)
> > > + u32 pixel_format, unsigned int
> > > rotation)
> > > {
> > > switch (pixel_format) {
> > > case DRM_FORMAT_XRGB:
> > > @@ -599,6 +599,9 @@ static bool pixel_format_is_valid(struct
> > > drm_i915_private *dev_priv,
> > > /* WaFbcOnly1to1Ratio:ctg */
> > > if (IS_G4X(dev_priv))
> > > return false;
> > > + if ((rotation & (DRM_MODE_ROTATE_90 |
> > > DRM_MODE_ROTATE_270)) &&
> > > + INTEL_GEN(dev_priv) >= 9)
> > > + return false;
> >
> > Would still would prefer a rotations_is_valid() or some such thing.
>
> Like this?
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 5e35c894bdf9..692edd45b769 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -600,15 +600,21 @@ static bool pixel_format_is_valid(struct
> drm_i915_private *dev_priv,
> /* WaFbcOnly1to1Ratio:ctg */
> if (IS_G4X(dev_priv))
> return false;
> - if ((rotation & (DRM_MODE_ROTATE_90 |
> DRM_MODE_ROTATE_270)) &&
> - INTEL_GEN(dev_priv) >= 9)
> - return false;
> return true;
> default:
> return false;
> }
> }
>
> +static bool rotations_is_valid(struct drm_i915_private *dev_priv,
> + u32 pixel_format, unsigned int rotation)
> +{
> + if (INTEL_GEN(dev_priv) >= 9 && pixel_format ==
> DRM_FORMAT_RGB565 &&
> + rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270))
drm_rotation_90_or_270()
> + return false;
> + return true;
> +}
> +
> /*
> * For some reason, the hardware tracking starts looking at whatever
> we
> * programmed as the display plane base address register. It does not
> look at
> @@ -810,6 +816,12 @@ static bool intel_fbc_can_activate(struct
> intel_crtc *crtc)
> return false;
> }
>
> + if (!rotations_is_valid(dev_priv, cache->fb.format->format,
> + cache->plane.rotation)) {
> + fbc->no_fbc_reason = "plane rotation is invalid";
> + return false;
> + }
s/rotations/rotation/ + I'd
Re: [Intel-gfx] [PATCH v19 4/8] drm/i915: Refactor intel_can_enable_sagv
On Wed, Mar 18, 2020 at 11:52:13AM +, Lisovskiy, Stanislav wrote: > >> @@ -5829,6 +6068,10 @@ skl_compute_wm(struct intel_atomic_state *state) > >>return ret; > >>} > >> > >> + ret = intel_compute_sagv_mask(state); > >> + if (ret) > >> + return ret; > > > This seems too early. We haven't even computed the ddb yet. > > > I was thinking about our discussion last week and actually I think there are > simply two ways how > > to do it. > > > 1) What I do here is: calculate minimum amount required to fit SAGV wm levels > into ddb and > > based on that do the ddb allocation accordingly. I.e it is not to early > because actually we have > > already wm levels for sagv and non-sagv calculated - we already can check if > it can fit into L0 > > and then act accordingly. > > However one thing to consider here: as you said besides the minimal > requirements for each plane > > (with or without sagv) there is an extra space being allocated in proportion > to plane data rate, > > however here we are actually hitting the prioritization issue - i.e we need > to decide whether > > it is more important to have SAGV or to have more extra space allocated to > different planes > > proportionally to their needs. > > So in this first approach we always first determine if we fit into minimum > SAGV reqs, turn it > > on if we do and then rest of extra space is allocated among the planes in > proportion to data rate. > > So that way we would be more often power efficient but but planes get less > extra ddb space. > > > 2) In your approach we should calculate ddb first, allocate extra space > proportionally to plane > > data rate needs and only then check if all planes got enough space for L0 > SAGV wm after that. > > Then we actually don't even need skl_plane_wm_level accessor, because we > first would be allocating > > using normal wm levels + extra ddb and only then check if all planes fit into > SAGV requirement - > > because that extra space is not actually distributed evenly but in proportion > to data rate of each > > plane, which means that some planes might lack space for SAGV theoretically, > because some might be > > getting more or less depending on the data_rate/total_data_rate ratio. > > > My position is such that I'm really not like "my approach should always win" > here, but more searching for > > solution which is more correct from product point of view. > > > Also could be that it doesn't really matter which approach we do take now,, > but matter more like > > that how fast we deliver. Because the actual outcome difference between two > > might be minor, while time overhead for changing the approach could be major. Pls fix your MUA. Really hard to read this. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/display/fbc: Make fences a nice-to-have for GEN9+
On Thu, Mar 12, 2020 at 12:35:56AM +, Souza, Jose wrote:
> On Thu, 2020-03-05 at 17:33 -0800, José Roberto de Souza wrote:
> > On Thu, 2020-02-20 at 19:26 +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza
> > > wrote:
> > > > dGFX have local memory so it do not have aperture and do not
> > > > support
> > > > CPU fences but even for iGFX it have a small number of fences.
> > > >
> > > > As replacement for fences to track frontbuffer modifications by
> > > > CPU
> > > > we have a software tracking that is already in used by FBC and
> > > > PSR.
> > > > PSR don't support fences so it shows that this tracking is
> > > > reliable.
> > > >
> > > > So lets make fences a nice-to-have to activate FBC for GEN9+,
> > > > this
> > > > will allow us to enable FBC for dGFXs and iGFXs even when there
> > > > is
> > > > no
> > > > available fence.
> > > >
> > > > We do not set fences to rotated planes but FBC only have
> > > > restrictions
> > > > against 16bpp, so adding it here.
> > > >
> > > > Also adding a new check for the tiling format, fences are only
> > > > set
> > > > to X and Y tiled planes but again FBC don't have any restrictions
> > > > against tiling so adding linear as supported as well, other
> > > > formats
> > > > should be added after tested but IGT only supports drawing in
> > > > thse
> > > > 3 formats.
> > > >
> > > > intel_fbc_hw_tracking_covers_screen() maybe can also have the
> > > > same
> > > > treatment as fences but BSpec is not clear if the size limitation
> > > > is
> > > > for hardware tracking or general use of FBC and I don't have a 5K
> > > > display to test it, so keeping as is for safety.
> > > >
> > > > v2:
> > > > - Added tiling and pixel format rotation checks
> > > > - Changed the GEN version not requiring fences to 11 from 9, DDX
> > > > needs some changes but it don't have support for GEN11+
> > > >
> > > > v3:
> > > > - Changed back to GEN9+
> > > > - Moved GEN test to inside of tiling_is_valid()
> > > >
> > > > Cc: Daniel Vetter
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Ville Syrjälä
> > > > Signed-off-by: José Roberto de Souza
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_fbc.c | 45
> > > >
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > 2 files changed, 39 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > index 1d76e3646a25..a0d1d661a006 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > @@ -585,7 +585,7 @@ static bool stride_is_valid(struct
> > > > drm_i915_private *dev_priv,
> > > > }
> > > >
> > > > static bool pixel_format_is_valid(struct drm_i915_private
> > > > *dev_priv,
> > > > - u32 pixel_format)
> > > > + u32 pixel_format, unsigned int
> > > > rotation)
> > > > {
> > > > switch (pixel_format) {
> > > > case DRM_FORMAT_XRGB:
> > > > @@ -599,6 +599,9 @@ static bool pixel_format_is_valid(struct
> > > > drm_i915_private *dev_priv,
> > > > /* WaFbcOnly1to1Ratio:ctg */
> > > > if (IS_G4X(dev_priv))
> > > > return false;
> > > > + if ((rotation & (DRM_MODE_ROTATE_90 |
> > > > DRM_MODE_ROTATE_270)) &&
> > > > + INTEL_GEN(dev_priv) >= 9)
> > > > + return false;
> > >
> > > Would still would prefer a rotations_is_valid() or some such thing.
> >
> > Like this?
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > index 5e35c894bdf9..692edd45b769 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > @@ -600,15 +600,21 @@ static bool pixel_format_is_valid(struct
> > drm_i915_private *dev_priv,
> > /* WaFbcOnly1to1Ratio:ctg */
> > if (IS_G4X(dev_priv))
> > return false;
> > - if ((rotation & (DRM_MODE_ROTATE_90 |
> > DRM_MODE_ROTATE_270)) &&
> > - INTEL_GEN(dev_priv) >= 9)
> > - return false;
> > return true;
> > default:
> > return false;
> > }
> > }
> >
> > +static bool rotations_is_valid(struct drm_i915_private *dev_priv,
> > + u32 pixel_format, unsigned int
> > rotation)
> > +{
> > + if (INTEL_GEN(dev_priv) >= 9 && pixel_format ==
> > DRM_FORMAT_RGB565 &&
> > + rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270))
> > + return false;
> > + return true;
> > +}
> > +
> > /*
> > * For some reason, the hardware tracking starts looking at whatever
> > we
> > * programmed as the display plane base address register. It does
> > not
> > look
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Trigger Modeset at boot for audio codec init
== Series Details == Series: drm/i915/display: Trigger Modeset at boot for audio codec init URL : https://patchwork.freedesktop.org/series/74828/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8146 -> Patchwork_17006 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17006 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17006, 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_17006/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17006: ### IGT changes ### Possible regressions * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-ilk-650: NOTRUN -> [FAIL][1] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-ilk-650/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-ivb-3770:NOTRUN -> [FAIL][2] +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-ivb-3770/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-glk-dsi: [PASS][3] -> [FAIL][4] +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-glk-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-glk-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-bsw-n3050: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-bsw-n3050/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-bsw-n3050/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic: - fi-hsw-4770:[PASS][7] -> [FAIL][8] +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-hsw-4770/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-hsw-4770/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html - fi-bxt-dsi: [PASS][9] -> [FAIL][10] +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-bxt-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-bxt-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html - fi-snb-2520m: [PASS][11] -> [FAIL][12] +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-snb-2520m/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-snb-2520m/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy: - fi-pnv-d510:[PASS][13] -> [FAIL][14] +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-pnv-d510/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-pnv-d510/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html - fi-icl-dsi: [PASS][15] -> [FAIL][16] +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-icl-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-icl-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html - fi-elk-e7500: [PASS][17] -> [FAIL][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-elk-e7500/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-elk-e7500/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html - fi-snb-2600:[PASS][19] -> [FAIL][20] +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8146/fi-snb-2600/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-snb-2600/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html - fi-blb-e6850: NOTRUN -> [FAIL][21] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17006/fi-blb-e6850/igt@kms_cursor_leg...@basic-flip-before-cursor-legacy.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-gdg-551: [PASS][22]
Re: [Intel-gfx] [PATCH 0/9] Per client engine busyness
On 18/03/2020 11:01, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Another re-spin of the per-client engine busyness series. Highlights from this version: Broken version with one patch missing, apologies for the spam. Regards, Tvrtko * Checkpatch cleanup and bits of review feedback only. Internally we track time spent on engines for each struct intel_context. This can serve as a building block for several features from the want list: smarter scheduler decisions, getrusage(2)-like per-GEM-context functionality wanted by some customers, cgroups controller, dynamic SSEU tuning,... Externally, in sysfs, we expose time spent on GPU per client and per engine class. Sysfs interface enables us to implement a "top-like" tool for GPU tasks. Or with a "screenshot": intel-gpu-top - 906/ 955 MHz;0% RC6; 5.30 Watts; 933 irqs/s IMC reads: 4414 MiB/s IMC writes: 3805 MiB/s ENGINE BUSY MI_SEMA MI_WAIT Render/3D/0 93.46% |▋ | 0% 0% Blitter/00.00% | | 0% 0% Video/00.00% | | 0% 0% VideoEnhance/00.00% | | 0% 0% PIDNAME Render/3D BlitterVideo VideoEnhance 2733 neverball |██▌ ||||||| 2047Xorg |███▊||||||| 2737glxgears |█▍ ||||||| 2128 xfwm4 |||||||| 2047Xorg |||||||| Implementation wise we add a a bunch of files in sysfs like: # cd /sys/class/drm/card0/clients/ # tree . ├── 7 │ ├── busy │ │ ├── 0 │ │ ├── 1 │ │ ├── 2 │ │ └── 3 │ ├── name │ └── pid ├── 8 │ ├── busy │ │ ├── 0 │ │ ├── 1 │ │ ├── 2 │ │ └── 3 │ ├── name │ └── pid └── 9 ├── busy │ ├── 0 │ ├── 1 │ ├── 2 │ └── 3 ├── name └── pid Files in 'busy' directories are numbered using the engine class ABI values and they contain accumulated nanoseconds each client spent on engines of a respective class. It is stil a RFC since it misses dedicated test cases to ensure things really work as advertised. Tvrtko Ursulin (9): drm/i915: Update client name on context create drm/i915: Make GEM contexts track DRM clients drm/i915: Use explicit flag to mark unreachable intel_context drm/i915: Track runtime spent in unreachable intel_contexts drm/i915: Track runtime spent in closed GEM contexts drm/i915: Track all user contexts per client drm/i915: Expose per-engine client busyness drm/i915: Track context current active time drm/i915: Prefer software tracked context busyness drivers/gpu/drm/i915/gem/i915_gem_context.c | 63 +++- .../gpu/drm/i915/gem/i915_gem_context_types.h | 21 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- drivers/gpu/drm/i915/gt/intel_context.c | 18 +- drivers/gpu/drm/i915/gt/intel_context.h | 6 +- drivers/gpu/drm/i915/gt/intel_context_types.h | 25 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 55 +++- drivers/gpu/drm/i915/gt/selftest_lrc.c| 10 +- drivers/gpu/drm/i915/i915_debugfs.c | 29 +- drivers/gpu/drm/i915/i915_drm_client.c| 274 +- drivers/gpu/drm/i915/i915_drm_client.h| 33 ++- drivers/gpu/drm/i915/i915_gpu_error.c | 25 +- 12 files changed, 473 insertions(+), 88 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
On 2020-03-18 at 17:00:09 +0530, Uma Shankar wrote:
> If external monitors are connected during boot up, driver
> uses the same mode programmed by BIOS and avoids a full modeset.
> This results in display audio codec left uninitialized and
> display audio fails to work till user triggers a modeset.
>
> This patch fixes the same by triggering a modeset at boot.
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Kai Vehmanen
> Signed-off-by: Uma Shankar
> Signed-off-by: SweeAun Khor
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4
> drivers/gpu/drm/i915/display/intel_display.c | 8
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 73d0f4648c06..ba380afa73a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3704,6 +3704,10 @@ static void intel_ddi_update_pipe(struct intel_encoder
> *encoder,
> const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + /* Clear the bootflag */
> + dev_priv->bootflag = false;
>
> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f23c4d51c33..a1487539495f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14751,6 +14751,10 @@ static int intel_atomic_check(struct drm_device *dev,
> if (new_crtc_state->hw.mode.private_flags !=
> old_crtc_state->hw.mode.private_flags)
> new_crtc_state->uapi.mode_changed = true;
> +
> + /* Set mode_change to init audio code once at boot */
> + if (dev_priv->bootflag && new_crtc_state->hw.active)
> + new_crtc_state->uapi.mode_changed = true;
I would prefer to compute crtc_state->has_audio in compute_config at boot up
and then force a full modeset in intel_pipe_config_compare(), this way
atomically we can force the
full modeset on boot up.
Thanks,
Anshuman Gupta.
> }
>
> ret = drm_atomic_helper_check_modeset(dev, >base);
> @@ -17655,11 +17659,15 @@ static void intel_update_fdi_pll_freq(struct
> drm_i915_private *dev_priv)
>
> static int intel_initial_commit(struct drm_device *dev)
> {
> + struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_atomic_state *state = NULL;
> struct drm_modeset_acquire_ctx ctx;
> struct intel_crtc *crtc;
> int ret = 0;
>
> + /* Set Flag to trigger modeset for audio codec init */
> + dev_priv->bootflag = true;
> +
> state = drm_atomic_state_alloc(dev);
> if (!state)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a7ea1d855359..207196f9632b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1210,6 +1210,9 @@ struct drm_i915_private {
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
>*/
> +
> + /* Flag to trigger modeset for Audio codec init once during boot */
> + bool bootflag;
> };
>
> static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot for audio codec init
Op 18-03-2020 om 12:30 schreef Uma Shankar:
> If external monitors are connected during boot up, driver
> uses the same mode programmed by BIOS and avoids a full modeset.
> This results in display audio codec left uninitialized and
> display audio fails to work till user triggers a modeset.
>
> This patch fixes the same by triggering a modeset at boot.
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Kai Vehmanen
> Signed-off-by: Uma Shankar
> Signed-off-by: SweeAun Khor
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4
> drivers/gpu/drm/i915/display/intel_display.c | 8
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> 3 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 73d0f4648c06..ba380afa73a6 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3704,6 +3704,10 @@ static void intel_ddi_update_pipe(struct intel_encoder
> *encoder,
> const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + /* Clear the bootflag */
> + dev_priv->bootflag = false;
>
> if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8f23c4d51c33..a1487539495f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14751,6 +14751,10 @@ static int intel_atomic_check(struct drm_device *dev,
> if (new_crtc_state->hw.mode.private_flags !=
> old_crtc_state->hw.mode.private_flags)
> new_crtc_state->uapi.mode_changed = true;
> +
> + /* Set mode_change to init audio code once at boot */
> + if (dev_priv->bootflag && new_crtc_state->hw.active)
> + new_crtc_state->uapi.mode_changed = true;
> }
>
> ret = drm_atomic_helper_check_modeset(dev, >base);
> @@ -17655,11 +17659,15 @@ static void intel_update_fdi_pll_freq(struct
> drm_i915_private *dev_priv)
>
> static int intel_initial_commit(struct drm_device *dev)
> {
> + struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_atomic_state *state = NULL;
> struct drm_modeset_acquire_ctx ctx;
> struct intel_crtc *crtc;
> int ret = 0;
>
> + /* Set Flag to trigger modeset for audio codec init */
> + dev_priv->bootflag = true;
> +
> state = drm_atomic_state_alloc(dev);
> if (!state)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a7ea1d855359..207196f9632b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1210,6 +1210,9 @@ struct drm_i915_private {
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
>*/
> +
> + /* Flag to trigger modeset for Audio codec init once during boot */
> + bool bootflag;
> };
>
> static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
This is not going to help. We read out the has_audio flag now, the only thing
we miss is to enable the audio codec. This should be done after the first
detect(), in the manner which I described to get the correct eld values.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Use explicit flag to mark unreachable intel_context
From: Tvrtko Ursulin
I need to keep the GEM context around a bit longer so adding an explicit
flag for syncing execbuf with closed/abandonded contexts.
v2:
* Use already available context flags. (Chris)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 3 ++-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 9afc60ab95e0..7c119a3a2cbd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -579,7 +579,8 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
int err = 0;
/* serialises with execbuf */
- RCU_INIT_POINTER(ce->gem_context, NULL);
+ set_bit(INTEL_CONTEXT_CLOSED, >flags);
+
if (!intel_context_pin_if_active(ce))
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..875da020d6c8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2316,7 +2316,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
prev = __i915_request_commit(rq);
/* Check that the context wasn't destroyed before submission */
- if (likely(rcu_access_pointer(eb->context->gem_context))) {
+ if (likely(!test_bit(INTEL_CONTEXT_CLOSED, >context->flags))) {
attr = eb->gem_context->sched;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0f3b68b95c56..d5925c25f109 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -66,6 +66,7 @@ struct intel_context {
#define CONTEXT_BANNED 4
#define CONTEXT_FORCE_SINGLE_SUBMISSION5
#define CONTEXT_NOPREEMPT 6
+#define INTEL_CONTEXT_CLOSED 7
u32 *lrc_reg_state;
u64 lrc_desc;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
