Re: [Intel-gfx] [PATCH 8/8] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().
On 2021-10-05 21:16:17 [+0200], Peter Zijlstra wrote:
> > -static inline void intel_context_mark_active(struct intel_context *ce)
> > +static inline void intel_context_mark_active(struct intel_context *ce,
> > +bool timeline_mutex_needed)
> > {
> > - lockdep_assert_held(&ce->timeline->mutex);
> > + if (timeline_mutex_needed)
> > + lockdep_assert_held(&ce->timeline->mutex);
> > ++ce->active_count;
> > }
>
> Chris, might it be possible to write that something like:
>
> lockdep_assert(lockdep_is_held(&ce->timeline->mutex) ||
> engine_is_parked(ce));
>
> instead?
This looks indeed way better given Torvald's yelling in similar cases.
> Otherwise,
>
> Acked-by: Peter Zijlstra (Intel)
Sebastian
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3)
== Series Details == Series: drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3) URL : https://patchwork.freedesktop.org/series/95309/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21259_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21259_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21259_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_21259_full: ### IGT changes ### Possible regressions * igt@i915_pm_dc@dc9-dpms: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb6/igt@i915_pm...@dc9-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-iclb8/igt@i915_pm...@dc9-dpms.html Known issues Here are the changes found in Patchwork_21259_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#1839]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-tglb6/igt@feature_discov...@display-2x.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#2481] / [i915#3070]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb6/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-iclb3/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-apl8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-apl: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-apl2/igt@gem_exec_fair@basic-n...@vcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-apl3/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: NOTRUN -> [FAIL][16] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][17] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-apl3/igt@gem_workarou...@suspend-resume-context.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: NOTRUN -> [DMESG-WARN][20] ([i915#180]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html * igt@gen3_render_tiledy_blits: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109289]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/shard-tglb6/igt@
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Add privacy-screen class and connector properties (rev6)
== Series Details == Series: drm: Add privacy-screen class and connector properties (rev6) URL : https://patchwork.freedesktop.org/series/79259/ State : success == Summary == CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21258_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21258_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-tglb5/igt@feature_discov...@display-2x.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-glk9/igt@gem_exec_f...@basic-deadline.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-glk1/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][5] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-apl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-apl7/igt@gem_huc_c...@huc-copy.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][10] -> [INCOMPLETE][11] ([i915#198]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-skl1/igt@gem_soft...@noreloc-s3.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-skl1/igt@gem_soft...@noreloc-s3.html * igt@gem_sync@basic-all: - shard-glk: [PASS][12] -> [DMESG-WARN][13] ([i915#118] / [i915#95]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-glk9/igt@gem_s...@basic-all.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-glk1/igt@gem_s...@basic-all.html * igt@gem_userptr_blits@vma-merge: - shard-snb: NOTRUN -> [FAIL][14] ([i915#2724]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-snb2/igt@gem_userptr_bl...@vma-merge.html * igt@gen3_render_tiledy_blits: - shard-tglb: NOTRUN -> [SKIP][15] ([fdo#109289]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-tglb5/igt@gen3_render_tiledy_blits.html * igt@gen9_exec_parse@bb-secure: - shard-tglb: NOTRUN -> [SKIP][16] ([i915#2856]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-tglb2/igt@gen9_exec_pa...@bb-secure.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#454]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb4/igt@i915_pm...@dc6-psr.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-iclb3/igt@i915_pm...@dc6-psr.html * igt@i915_pm_lpsp@screens-disabled: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#1902]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-tglb2/igt@i915_pm_l...@screens-disabled.html * igt@i915_pm_rc6_residency@media-rc6-accuracy: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289] / [fdo#111719]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-tglb5/igt@i915_pm_rc6_reside...@media-rc6-accuracy.html * igt@i915_pm_rpm@pc8-residency: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109506] / [i915#2411]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-tglb2/igt@i915_pm_...@pc8-residency.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][22] -> [DMESG-WARN][23] ([i915#180]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-apl8/igt@i915_susp...@sysfs-reader.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/shard-apl8/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@linear-64b
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95476/ State : success == Summary == CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21257_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21257_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-tglb5/igt@feature_discov...@display-2x.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@unwedge-stress: - shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#2481] / [i915#3070]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb6/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-iclb1/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][5] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-apl1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-iclb8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-kbl2/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_schedule@semaphore-power: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-skl6/igt@gem_exec_sched...@semaphore-power.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-skl2/igt@gem_exec_sched...@semaphore-power.html * igt@gem_exec_suspend@basic-s0: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#165] / [i915#180] / [i915#262] / [i915#62] / [i915#92]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-kbl2/igt@gem_exec_susp...@basic-s0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-kbl6/igt@gem_exec_susp...@basic-s0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-apl2/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][16] ([i915#768]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-iclb7/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@gem_userptr_blits@readonly-pwrite-unsync: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#3297]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-iclb7/igt@gem_userptr_bl...@readonly-pwrite-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-snb: NOTRUN -> [FAIL][18] ([i915#2724]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-snb7/igt@gem_userptr_bl...@vma-merge.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@gen3_render_tiledy_blits: - shard-tglb: NOTRUN -> [SKIP][21] ([fdo#109289]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-tglb5/igt@gen3_render_tiledy_blits.html * igt@gen9_exec_parse@bb-secure: - shard-tglb: NOTRUN -> [SKIP][22] ([i915#2856]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/shard-tglb2/igt@gen9_exec_pa...@bb-secure.h
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/irq: don't use gt ptr for no reason.
== Series Details == Series: drm/i915/irq: don't use gt ptr for no reason. URL : https://patchwork.freedesktop.org/series/95492/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10686 -> Patchwork_21261 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21261 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21261, 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_21261/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21261: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_21261 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-skl-6700k2: NOTRUN -> [SKIP][3] ([fdo#109271]) +33 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271]) +21 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][5] -> [FAIL][6] ([i915#1888]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html - fi-skl-6700k2: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6700k2/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [PASS][10] -> [FAIL][11] ([i915#4165]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [PASS][12] -> [FAIL][13] ([i915#2546]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-skl-6700k2: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6700k2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-rkl-guc: NOTRUN -> [FAIL][16] ([i915#3928]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-rkl-guc/igt@run...@aborted.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-tgl-u2: [INCOMPLETE][17] -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s3: - fi-skl-6600u: [INCOMPLETE][19] ([i915#146] / [i915#198]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21261/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/bios: gracefully disable dual eDP for now
== Series Details == Series: drm/i915/bios: gracefully disable dual eDP for now URL : https://patchwork.freedesktop.org/series/95475/ State : success == Summary == CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21255_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21255_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-tglb5/igt@feature_discov...@display-2x.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#180]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-apl8/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271]) +373 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-snb2/igt@gem_ctx_sha...@q-in-order.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-glk9/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-tglb8/igt@gem_huc_c...@huc-copy.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@y-tiled-ccs-to-yf-tiled-mc-ccs: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#768]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-iclb3/igt@gem_render_c...@y-tiled-ccs-to-yf-tiled-mc-ccs.html * igt@gem_userptr_blits@readonly-pwrite-unsync: - shard-iclb: NOTRUN -> [SKIP][15] ([i915#3297]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-iclb3/igt@gem_userptr_bl...@readonly-pwrite-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-snb: NOTRUN -> [FAIL][16] ([i915#2724]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-snb2/igt@gem_userptr_bl...@vma-merge.html * igt@gen3_render_tiledy_blits: - shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109289]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-tglb5/igt@gen3_render_tiledy_blits.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1436] / [i915#716]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-skl5/igt@gen9_exec_pa...@allowed-single.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-skl10/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@batch-zero-length: - shard-tglb: NOTRUN -> [SKIP][20] ([i915#2856]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-tglb5/igt@gen9_exec_pa...@batch-zero-length.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][21] -> [FAIL][22] ([i915#454]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/shard-iclb4/igt@i915_pm...@dc6-psr.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/shard-iclb3/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rc6_residency@media-rc6-accuracy: - shard-tglb: NOTRUN -> [SKIP][23] ([fdo#109289] / [fdo#111719]) [23]: https://i
[Intel-gfx] [PATCH] drm/i915/irq: don't use gt ptr for no reason.
From: Dave Airlie
Neither of these functions want the gt at all, just pass regs
and i915.
Just noticed in passing.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_irq.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 77680bca46ee..67e3ac07f07d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2652,9 +2652,8 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
}
static u32
-gen11_gu_misc_irq_ack(struct intel_gt *gt, const u32 master_ctl)
+gen11_gu_misc_irq_ack(void __iomem * const regs, const u32 master_ctl)
{
- void __iomem * const regs = gt->uncore->regs;
u32 iir;
if (!(master_ctl & GEN11_GU_MISC_IRQ))
@@ -2668,10 +2667,10 @@ gen11_gu_misc_irq_ack(struct intel_gt *gt, const u32
master_ctl)
}
static void
-gen11_gu_misc_irq_handler(struct intel_gt *gt, const u32 iir)
+gen11_gu_misc_irq_handler(struct drm_i915_private *i915, const u32 iir)
{
if (iir & GEN11_GU_MISC_GSE)
- intel_opregion_asle_intr(gt->i915);
+ intel_opregion_asle_intr(i915);
}
static inline u32 gen11_master_intr_disable(void __iomem * const regs)
@@ -2715,7 +2714,6 @@ static irqreturn_t gen11_irq_handler(int irq, void *arg)
{
struct drm_i915_private *i915 = arg;
void __iomem * const regs = i915->uncore.regs;
- struct intel_gt *gt = &i915->gt;
u32 master_ctl;
u32 gu_misc_iir;
@@ -2729,17 +2727,17 @@ static irqreturn_t gen11_irq_handler(int irq, void *arg)
}
/* Find, queue (onto bottom-halves), then clear each source */
- gen11_gt_irq_handler(gt, master_ctl);
+ gen11_gt_irq_handler(&i915->gt, master_ctl);
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
if (master_ctl & GEN11_DISPLAY_IRQ)
gen11_display_irq_handler(i915);
- gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
+ gu_misc_iir = gen11_gu_misc_irq_ack(regs, master_ctl);
gen11_master_intr_enable(regs);
- gen11_gu_misc_irq_handler(gt, gu_misc_iir);
+ gen11_gu_misc_irq_handler(i915, gu_misc_iir);
pmu_irq_stats(i915, IRQ_HANDLED);
@@ -2771,7 +2769,6 @@ static inline void dg1_master_intr_enable(void __iomem *
const regs)
static irqreturn_t dg1_irq_handler(int irq, void *arg)
{
struct drm_i915_private * const i915 = arg;
- struct intel_gt *gt = &i915->gt;
void __iomem * const regs = i915->uncore.regs;
u32 master_tile_ctl, master_ctl;
u32 gu_misc_iir;
@@ -2795,16 +2792,16 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
return IRQ_NONE;
}
- gen11_gt_irq_handler(gt, master_ctl);
+ gen11_gt_irq_handler(&i915->gt, master_ctl);
if (master_ctl & GEN11_DISPLAY_IRQ)
gen11_display_irq_handler(i915);
- gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
+ gu_misc_iir = gen11_gu_misc_irq_ack(regs, master_ctl);
dg1_master_intr_enable(regs);
- gen11_gu_misc_irq_handler(gt, gu_misc_iir);
+ gen11_gu_misc_irq_handler(i915, gu_misc_iir);
pmu_irq_stats(i915, IRQ_HANDLED);
--
2.25.4
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev4)
== Series Details == Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev4) URL : https://patchwork.freedesktop.org/series/95127/ State : success == Summary == CI Bug Log - changes from CI_DRM_10686 -> Patchwork_21260 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/index.html Known issues Here are the changes found in Patchwork_21260 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-skl-6600u: NOTRUN -> [SKIP][1] ([fdo#109271]) +21 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][3] -> [INCOMPLETE][4] ([i915#2940]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [PASS][6] -> [FAIL][7] ([i915#4165]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [PASS][8] -> [DMESG-WARN][9] ([i915#95]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#295]) +18 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#1436] / [i915#3428]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-bsw-nick/igt@run...@aborted.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-skl-6600u: [INCOMPLETE][14] ([i915#146] / [i915#198]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10686/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21260/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428 [i915#4165]: https://gitlab.freedesktop.org/drm/intel/issues/4165 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (44 -> 35) -- Missing(9): fi-ilk-m540 bat-dg1-6 fi-tgl-u2 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 bat-jsl-1 fi-kbl-r Build changes - * Linux: CI_DRM_10686 -> Patchwork_21260 CI-20190529: 20190529 CI_DRM_10686: 6821b7d32c6f41fdbfad6b0ea444d697c7e115f2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6232: effad6af5678be711a2c3e58e182319de784de54 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21260: 8debc6e1d97e17968781187f5d
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev4)
== Series Details == Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers (rev4) URL : https://patchwork.freedesktop.org/series/95127/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[Intel-gfx] [PATCH v3 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs()
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixed all of the problematic brightness controls laptop panels that
we've hit so far.
So, let's actually document this instead of just calling the laptop panels
liars. As well, I would like to formally apologize to all of the laptop
panels I called liars. I'm sorry laptop panels, hopefully you can all
forgive me and we can move past this~
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c| 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 91daf9ab50e8..04a52d6a74ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -455,11 +455,17 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
}
/*
-* A lot of eDP panels in the wild will report supporting both the
-* Intel proprietary backlight control interface, and the VESA
-* backlight control interface. Many of these panels are liars though,
-* and will only work with the Intel interface. So, always probe for
-* that first.
+* Since Intel has their own backlight control interface, the majority
of machines out there
+* using DPCD backlight controls with Intel GPUs will be using this
interface as opposed to
+* the VESA interface. However, other GPUs (such as Nvidia's) will
always use the VESA
+* interface. This means that there's quite a number of panels out
there that will advertise
+* support for both interfaces, primarily systems with Intel/Nvidia
hybrid GPU setups.
+*
+* There's a catch to this though: on many panels that advertise
support for both
+* interfaces, the VESA backlight interface will stop working once
we've programmed the
+* panel with Intel's OUI - which is also required for us to be able to
detect Intel's
+* backlight interface at all. This means that the only sensible way
for us to detect both
+* interfaces is to probe for Intel's first, and VESA's second.
*/
if (try_intel_interface &&
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight
controls\n");
--
2.31.1
[Intel-gfx] [PATCH v3 4/5] drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
which would allow us to finally start trusting the DPCD again.
Note however that we still don't enable using this by default on i915 when
it's not needed, primarily because I haven't yet had a chance to confirm if
it's safe to do this on the one machine in Intel's CI that had an issue
with this: samus-fi-bdw. I have done basic testing of this on other
machines though, by manually patching i915 to force it into PWM-only mode
on some of my laptops.
v2:
* Correct documentation (thanks Doug!)
* Get rid of backlight caps
Signed-off-by: Lyude Paul
Cc: Rajeev Nandan
Cc: Doug Anderson
Cc: Satadru Pramanik
---
drivers/gpu/drm/drm_dp_helper.c | 76 +--
.../drm/i915/display/intel_dp_aux_backlight.c | 48 +---
include/drm/drm_dp_helper.h | 7 +-
3 files changed, 94 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index d9a7f07f42fd..9bef21613370 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3173,6 +3173,10 @@ int drm_edp_backlight_set_level(struct drm_dp_aux *aux,
const struct drm_edp_bac
int ret;
u8 buf[2] = { 0 };
+ /* The panel uses the PWM for controlling brightness levels */
+ if (!bl->aux_set)
+ return 0;
+
if (bl->lsb_reg_used) {
buf[0] = (level & 0xff00) >> 8;
buf[1] = (level & 0x00ff);
@@ -3199,7 +3203,7 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
int ret;
u8 buf;
- /* The panel uses something other then DPCD for enabling its backlight
*/
+ /* This panel uses the EDP_BL_PWR GPIO for enablement */
if (!bl->aux_enable)
return 0;
@@ -3234,11 +3238,11 @@ drm_edp_backlight_set_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
* restoring any important backlight state such as the given backlight level,
the brightness byte
* count, backlight frequency, etc.
*
- * Note that certain panels, while supporting brightness level controls over
DPCD, may not support
- * having their backlights enabled via the standard
%DP_EDP_DISPLAY_CONTROL_REGISTER. On such panels
- * &drm_edp_backlight_info.aux_enable will be set to %false, this function
will skip the step of
- * programming the %DP_EDP_DISPLAY_CONTROL_REGISTER, and the driver must
perform the required
- * implementation specific step for enabling the backlight after calling this
function.
+ * Note that certain panels do not support being enabled or disabled via DPCD,
but instead require
+ * that the driver handle enabling/disabling the panel through
implementation-specific means using
+ * the EDP_BL_PWR GPIO. For such panels, &drm_edp_backlight_info.aux_enable
will be set to %false,
+ * this function becomes a no-op, and the driver is expected to handle
powering the panel on using
+ * the EDP_BL_PWR GPIO.
*
* Returns: %0 on success, negative error code on failure.
*/
@@ -3246,7 +3250,7 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
const u16 level)
{
int ret;
- u8 dpcd_buf, new_dpcd_buf;
+ u8 dpcd_buf, new_dpcd_buf, new_mode;
ret = drm_dp_dpcd_readb(aux, DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
&dpcd_buf);
if (ret != 1) {
@@ -3259,9 +3263,14 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
- if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
+ if (bl->aux_set)
+ new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+ else
+ new_mode = DP_EDP_BACKLIGHT_CONTROL_MODE_PWM;
+
+ if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) != new_mode) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
- new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+ new_dpcd_buf |= new_mode;
if (bl->pwmgen_bit_count) {
ret = drm_dp_dpcd_writeb(aux, DP_EDP_PWMGEN_BIT_COUNT,
bl->pwmgen_bit_count);
@@ -3308,12 +3317,13 @@ EXPORT_SYMBOL(drm_edp_backlight_enable);
* @aux: The DP AUX channel to use
* @bl: Backlight capability info from drm_edp_backlight_init()
*
- * This function handles disabling DPCD backlight controls on a panel over
AUX. Note that some
- * panels have backlights that are enabled/disabled by other means, despite
having their brightness
- * values con
[Intel-gfx] [PATCH v3 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER
As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking behavior when adjusting the backlight.
So, let's fix this by ensuring we only keep supported features enabled for
panel backlights - which should fix some of the issues we were seeing from
this on fi-bdw-samus.
Signed-off-by: Lyude Paul
Fixes: 867cf9cd73c3 ("drm/dp: Extract i915's eDP backlight code into DRM
helpers")
---
drivers/gpu/drm/drm_dp_helper.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 4d0d1e8e51fa..d9a7f07f42fd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -3255,7 +3255,9 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
return ret < 0 ? ret : -EIO;
}
- new_dpcd_buf = dpcd_buf;
+ /* Disable any backlight functionality we don't support that might be
on */
+ new_dpcd_buf = dpcd_buf & (DP_EDP_BACKLIGHT_CONTROL_MODE_MASK |
+ DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE);
if ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
@@ -3277,6 +3279,8 @@ int drm_edp_backlight_enable(struct drm_dp_aux *aux,
const struct drm_edp_backli
aux->name, ret);
else
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+ } else {
+ new_dpcd_buf &= ~DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
}
if (new_dpcd_buf != dpcd_buf) {
--
2.31.1
[Intel-gfx] [PATCH v3 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 1cbd71abc80a..ae2f2abc8f5a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -308,7 +308,10 @@ nv50_backlight_init(struct nouveau_backlight *bl,
if (ret < 0)
return ret;
- if (drm_edp_backlight_supported(edp_dpcd)) {
+ /* TODO: Add support for hybrid PWM/DPCD panels */
+ if (drm_edp_backlight_supported(edp_dpcd) &&
+ (edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+ (edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
NV_DEBUG(drm, "DPCD backlight controls supported on
%s\n",
nv_conn->base.name);
--
2.31.1
[Intel-gfx] [PATCH v3 1/5] drm/i915: Add support for panels with VESA backlights with PWM enable/disable
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that were broken by not having this enabled.
For reference, backlights that require this and use VESA's backlight
interface tend to be laptops with hybrid GPUs, but this very well may
change in the future.
Signed-off-by: Lyude Paul
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/3680
Fixes: fe7d52bccab6 ("drm/i915/dp: Don't use DPCD backlights that need PWM
enable/disable")
Cc: # v5.12+
---
.../drm/i915/display/intel_dp_aux_backlight.c | 24 ++-
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 569d17b4d00f..594fdc7453ca 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -293,6 +293,10 @@ intel_dp_aux_vesa_enable_backlight(const struct
intel_crtc_state *crtc_state,
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
+ if (!panel->backlight.edp.vesa.info.aux_enable)
+ panel->backlight.pwm_funcs->enable(crtc_state, conn_state,
+
panel->backlight.pwm_level_max);
+
drm_edp_backlight_enable(&intel_dp->aux,
&panel->backlight.edp.vesa.info, level);
}
@@ -304,6 +308,10 @@ static void intel_dp_aux_vesa_disable_backlight(const
struct drm_connector_state
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
drm_edp_backlight_disable(&intel_dp->aux,
&panel->backlight.edp.vesa.info);
+
+ if (!panel->backlight.edp.vesa.info.aux_enable)
+ panel->backlight.pwm_funcs->disable(old_conn_state,
+
intel_backlight_invert_pwm_level(connector, 0));
}
static int intel_dp_aux_vesa_setup_backlight(struct intel_connector
*connector, enum pipe pipe)
@@ -321,6 +329,15 @@ static int intel_dp_aux_vesa_setup_backlight(struct
intel_connector *connector,
if (ret < 0)
return ret;
+ if (!panel->backlight.edp.vesa.info.aux_enable) {
+ ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+ if (ret < 0) {
+ drm_err(&i915->drm,
+ "Failed to setup PWM backlight controls for eDP
backlight: %d\n",
+ ret);
+ return ret;
+ }
+ }
panel->backlight.max = panel->backlight.edp.vesa.info.max;
panel->backlight.min = 0;
if (current_mode == DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
@@ -340,12 +357,7 @@ intel_dp_aux_supports_vesa_backlight(struct
intel_connector *connector)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
- /* TODO: We currently only support AUX only backlight configurations,
not backlights which
-* require a mix of PWM and AUX controls to work. In the mean time,
these machines typically
-* work just fine using normal PWM controls anyway.
-*/
- if ((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
- drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
+ if (drm_edp_backlight_supported(intel_dp->edp_dpcd)) {
drm_dbg_kms(&i915->drm, "AUX Backlight Control Supported!\n");
return true;
}
--
2.31.1
[Intel-gfx] [PATCH v3 0/5] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
When I originally moved all of the VESA backlight code in i915 into DRM helpers, one of the things I didn't have the hardware or time for testing was machines that used a combination of PWM and DPCD in order to control their backlights. This has since then caused some breakages and resulted in us disabling DPCD backlight support on such machines. This works fine, unless you have a machine that actually needs this functionality for backlight controls to work at all. Additionally, we will need to support PWM for when we start adding support for VESA's product (as in the product of multiplication) control mode for better brightness ranges. So - let's finally finish up implementing basic support for these types of backlights to solve these problems in our DP helpers, along with implementing support for this in i915. And since digging into this issue solved the last questions we really had about probing backlights in i915 for the most part, let's update some of the comments around that as well! Changes (v3): * Add likely fix for weird backlight scaling issues on samus-fi-bdw in intel's CI, which pointed out we've been leaving some (currently) unsupported backlight features on by mistake which certainly have the potential to cause problems. Changes (v2): * Fixup docs * Add patch to stop us from breaking nouveau Lyude Paul (5): drm/i915: Add support for panels with VESA backlights with PWM enable/disable drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER drm/dp, drm/i915: Add support for VESA backlights using PWM for brightness control drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs() drivers/gpu/drm/drm_dp_helper.c | 82 +-- .../drm/i915/display/intel_dp_aux_backlight.c | 80 ++ drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +- include/drm/drm_dp_helper.h | 7 +- 4 files changed, 128 insertions(+), 46 deletions(-) -- 2.31.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3)
== Series Details == Series: drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3) URL : https://patchwork.freedesktop.org/series/95309/ State : success == Summary == CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21259 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/index.html Known issues Here are the changes found in Patchwork_21259 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +13 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][3] ([i915#1886] / [i915#2291]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#533]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-kbl-soraka: [INCOMPLETE][6] ([i915#155]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][8] ([i915#1888]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [FAIL][10] ([i915#4165]) -> [PASS][11] +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [FAIL][12] ([i915#2546]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2546]: https://gitlab.freedesktop.org/drm/intel/issues/2546 [i915#4165]: https://gitlab.freedesktop.org/drm/intel/issues/4165 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (41 -> 34) -- Missing(7): fi-ilk-m540 bat-dg1-6 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 bat-jsl-1 Build changes - * Linux: CI_DRM_10685 -> Patchwork_21259 CI-20190529: 20190529 CI_DRM_10685: 36c3656c997b07f326d6b967efb1b75e01713773 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6232: effad6af5678be711a2c3e58e182319de784de54 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21259: ed22a0b168e23011e41b5ed4a46a81053813b464 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ed22a0b168e2 drm/i915/display: Wait PSR2 get out of deep sleep to update pipe == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21259/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add privacy-screen class and connector properties (rev6)
== Series Details == Series: drm: Add privacy-screen class and connector properties (rev6) URL : https://patchwork.freedesktop.org/series/79259/ State : success == Summary == CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21258 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/index.html Known issues Here are the changes found in Patchwork_21258 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +12 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-1115g4: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886] / [i915#2291]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-kbl-soraka: [INCOMPLETE][9] ([i915#155]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][11] ([i915#3921]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [FAIL][13] ([i915#4165]) -> [PASS][14] +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][15] ([i915#95]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html - fi-cfl-8109u: [FAIL][17] ([i915#2546]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21258/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2546]: https://gitlab.freedesktop.org/drm/intel/issues/2546 [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921 [i915#4165]: https://gitlab.freedesktop.org/drm/intel/issues/4165 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (41 -> 33) -- Missing(8): f
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Add privacy-screen class and connector properties (rev6)
== Series Details == Series: drm: Add privacy-screen class and connector properties (rev6) URL : https://patchwork.freedesktop.org/series/79259/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add privacy-screen class and connector properties (rev6)
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev6)
URL : https://patchwork.freedesktop.org/series/79259/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
81c0ef8541bc drm/connector: Add support for privacy-screen properties (v4)
-:151: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#151: FILE: drivers/gpu/drm/drm_connector.c:2408:
+ drm_property_create_enum(connector->dev, DRM_MODE_PROP_ENUM,
+ "privacy-screen sw-state",
-:156: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#156: FILE: drivers/gpu/drm/drm_connector.c:2413:
+ drm_property_create_enum(connector->dev,
+ DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_ENUM,
total: 0 errors, 0 warnings, 2 checks, 205 lines checked
ef63d9d95cb2 drm: Add privacy-screen class (v4)
-:136: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#136:
new file mode 100644
-:173: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev' - possible
side-effects?
#173: FILE: drivers/gpu/drm/drm_privacy_screen.c:33:
+#define to_drm_privacy_screen(dev) \
+ container_of(dev, struct drm_privacy_screen, dev)
-:221: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#221: FILE: drivers/gpu/drm/drm_privacy_screen.c:81:
+static struct drm_privacy_screen *drm_privacy_screen_get_by_name(
-:424: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#424: FILE: drivers/gpu/drm/drm_privacy_screen.c:284:
+}
+/*
-:486: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#486: FILE: drivers/gpu/drm/drm_privacy_screen.c:346:
+struct drm_privacy_screen *drm_privacy_screen_register(
-:582: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#582: FILE: include/drm/drm_privacy_screen_consumer.h:33:
+}
+static inline void drm_privacy_screen_put(struct drm_privacy_screen *priv)
-:585: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#585: FILE: include/drm/drm_privacy_screen_consumer.h:36:
+}
+static inline int drm_privacy_screen_set_sw_state(struct drm_privacy_screen
*priv,
-:590: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#590: FILE: include/drm/drm_privacy_screen_consumer.h:41:
+}
+static inline void drm_privacy_screen_get_state(struct drm_privacy_screen
*priv,
-:681: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#681: FILE: include/drm/drm_privacy_screen_driver.h:76:
+struct drm_privacy_screen *drm_privacy_screen_register(
-:728: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#728: FILE: include/drm/drm_privacy_screen_machine.h:37:
+}
+static inline void drm_privacy_screen_lookup_exit(void)
total: 0 errors, 1 warnings, 9 checks, 642 lines checked
3bf5d3a76db4 drm/privacy-screen: Add X86 specific arch init code
-:31: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#31:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 110 lines checked
a4870de0bdc9 drm/privacy-screen: Add notifier support (v2)
-:126: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#126: FILE: include/drm/drm_privacy_screen_consumer.h:53:
}
+static inline int drm_privacy_screen_register_notifier(struct
drm_privacy_screen *priv,
-:131: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#131: FILE: include/drm/drm_privacy_screen_consumer.h:58:
+}
+static inline int drm_privacy_screen_unregister_notifier(struct
drm_privacy_screen *priv,
total: 0 errors, 0 warnings, 2 checks, 120 lines checked
52d7f973ab68 drm/connector: Add a drm_connector privacy-screen helper functions
(v2)
-:58: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#58: FILE: drivers/gpu/drm/drm_connector.c:554:
+ drm_privacy_screen_register_notifier(connector->privacy_screen,
+ &connector->privacy_screen_notifier);
-:68: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#68: FILE: drivers/gpu/drm/drm_connector.c:592:
+ drm_privacy_screen_unregister_notifier(
-:79: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#79: FILE: drivers/gpu/drm/drm_connector.c:2460:
+static void drm_connector_update_privacy_screen_properties(
-:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#90: FILE: drivers/gpu/drm/drm_connector.c:2471:
+ drm_object_property_set_value(&connector->base,
+ connector->privacy_screen_hw_state_property, hw_state);
-:93: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#93: FILE: drivers/gpu/drm/drm_connector.c:2474:
+static int drm_connector_privacy_screen_notifier(
-:105: CHECK:PARENTHESIS_ALIGNM
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95476/ State : success == Summary == CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21257 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/index.html Known issues Here are the changes found in Patchwork_21257 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +21 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html * igt@debugfs_test@read_all_entries: - fi-kbl-soraka: [PASS][2] -> [DMESG-WARN][3] ([i915#1982] / [i915#262]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][4] -> [FAIL][5] ([i915#1888]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886] / [i915#2291]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#295]) +17 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][12] ([i915#1602] / [i915#2029]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-bdw-5557u/igt@run...@aborted.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-tgl-u2: [INCOMPLETE][13] -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s0: - fi-kbl-soraka: [INCOMPLETE][15] ([i915#155]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][17] ([i915#1888]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html Warnings * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [FAIL][19] ([i915#2546]) -> [DMESG-WARN][20] ([i915#295]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21257/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95476/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1392:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:418:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils
== Series Details == Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem backend utils URL : https://patchwork.freedesktop.org/series/95476/ State : warning == Summary == $ dim checkpatch origin/drm-tip 605eef61ebf9 drm/i915/gem: Break out some shmem backend utils b116a99cc04e drm/i915/ttm: add tt shmem backend -:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #16: dropping the shrinker LRU lock and acquiring the object lock it could for total: 0 errors, 1 warnings, 0 checks, 486 lines checked 14f612b9093f drm/i915/gtt: drop unneeded make_unshrinkable 32c05a4de159 drm/i915: drop unneeded make_unshrinkable in free_object 0999a655bf2a drm/i915: add some kernel-doc for shrink_pin and friends c6e18e36eb58 drm/i915/ttm: move shrinker management into adjust_lru -:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #19: an object. Importantly this covers the case where TTM moves something from total: 0 errors, 1 warnings, 0 checks, 264 lines checked df1f7fa12f7b drm/i915/ttm: use cached system pages when evicting lmem fc764587e539 drm/i915/ttm: enable shmem tt backend
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bios: gracefully disable dual eDP for now
== Series Details == Series: drm/i915/bios: gracefully disable dual eDP for now URL : https://patchwork.freedesktop.org/series/95475/ State : success == Summary == CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21255 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/index.html Known issues Here are the changes found in Patchwork_21255 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +12 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] ([i915#2940]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886] / [i915#2291]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_flip@basic-plain-flip@c-dp1: - fi-cfl-8109u: [PASS][7] -> [FAIL][8] ([i915#4165]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp1.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#295]) +13 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@runner@aborted: - fi-bsw-kefka: NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#1436] / [i915#3428]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-bsw-kefka/igt@run...@aborted.html Possible fixes * igt@core_hotunplug@unbind-rebind: - fi-tgl-u2: [INCOMPLETE][13] -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s0: - fi-kbl-soraka: [INCOMPLETE][15] ([i915#155]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-kbl-soraka/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [FAIL][17] ([i915#1888]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [FAIL][19] ([i915#4165]) -> [PASS][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html Warnings * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [FAIL][21] ([i915#2546]) -> [DMESG-WARN][22] ([i915#295]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesk
[Intel-gfx] ✗ Fi.CI.BUILD: failure for CPU + GPU synchronised priority scheduling (rev4)
== Series Details == Series: CPU + GPU synchronised priority scheduling (rev4) URL : https://patchwork.freedesktop.org/series/95294/ State : failure == Summary == Applying: effective and consolidated user experience. In other words why user would not be error: drivers/gpu/drm/i915/i915_drm_client.c: already exists in index error: drivers/gpu/drm/i915/i915_drm_client.h: already exists in index error: patch failed: drivers/gpu/drm/i915/gem/i915_gem_context.c:956 error: drivers/gpu/drm/i915/gem/i915_gem_context.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/gem/i915_gem_context_types.h:277 error: drivers/gpu/drm/i915/gem/i915_gem_context_types.h: patch does not apply error: patch failed: drivers/gpu/drm/i915/gem/i915_gem_context.c:1169 error: drivers/gpu/drm/i915/gem/i915_gem_context.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_drm_client.c:38 error: drivers/gpu/drm/i915/i915_drm_client.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_drm_client.h:7 error: drivers/gpu/drm/i915/i915_drm_client.h: patch does not apply error: patch failed: drivers/gpu/drm/i915/gem/i915_gem_context.c:1932 error: drivers/gpu/drm/i915/gem/i915_gem_context.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_drm_client.c:18 error: drivers/gpu/drm/i915/i915_drm_client.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_drm_client.h:6 error: drivers/gpu/drm/i915/i915_drm_client.h: patch does not apply error: patch failed: drivers/gpu/drm/i915/gt/intel_execlists_submission.c:3216 error: drivers/gpu/drm/i915/gt/intel_execlists_submission.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2414 error: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_scheduler.c:255 error: drivers/gpu/drm/i915/i915_scheduler.c: patch does not apply error: patch failed: drivers/gpu/drm/i915/i915_scheduler_types.h:177 error: drivers/gpu/drm/i915/i915_scheduler_types.h: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. hint: Use 'git am --show-current-patch=diff' to see the failed patch Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/Makefile M drivers/gpu/drm/i915/gem/i915_gem_context.c M drivers/gpu/drm/i915/gem/i915_gem_context_types.h M drivers/gpu/drm/i915/gt/intel_execlists_submission.c M drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c A drivers/gpu/drm/i915/i915_drm_client.c A drivers/gpu/drm/i915/i915_drm_client.h M drivers/gpu/drm/i915/i915_drv.c M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_scheduler.c M drivers/gpu/drm/i915/i915_scheduler_types.h Patch failed at 0001 effective and consolidated user experience. In other words why user would not be When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Connect engine busyness stats from GuC to pmu
On Tue, Oct 05, 2021 at 10:47:11AM -0700, Umesh Nerlige Ramappa wrote:
> With GuC handling scheduling, i915 is not aware of the time that a
> context is scheduled in and out of the engine. Since i915 pmu relies on
> this info to provide engine busyness to the user, GuC shares this info
> with i915 for all engines using shared memory. For each engine, this
> info contains:
>
> - total busyness: total time that the context was running (total)
> - id: id of the running context (id)
> - start timestamp: timestamp when the context started running (start)
>
> At the time (now) of sampling the engine busyness, if the id is valid
> (!= ~0), and start is non-zero, then the context is considered to be
> active and the engine busyness is calculated using the below equation
>
> engine busyness = total + (now - start)
>
> All times are obtained from the gt clock base. For inactive contexts,
> engine busyness is just equal to the total.
>
> The start and total values provided by GuC are 32 bits and wrap around
> in a few minutes. Since perf pmu provides busyness as 64 bit
> monotonically increasing values, there is a need for this implementation
> to account for overflows and extend the time to 64 bits before returning
> busyness to the user. In order to do that, a worker runs periodically at
> frequency = 1/8th the time it takes for the timestamp to wrap. As an
> example, that would be once in 27 seconds for a gt clock frequency of
> 19.2 MHz.
>
> Opens and wip that are targeted for later patches:
>
> 1) On global gt reset the total busyness of engines resets and i915
>needs to fix that so that user sees monotonically increasing
>busyness.
> 2) In runtime suspend mode, the worker may not need to be run. We could
>stop the worker on suspend and rerun it on resume provided that the
>guc pm timestamp does not tick during suspend.
>
> Note:
> There might be an overaccounting of busyness due to the fact that GuC
> may be updating the total and start values while kmd is reading them.
> (i.e kmd may read the updated total and the stale start). In such a
> case, user may see higher busyness value followed by smaller ones which
> would eventually catch up to the higher value.
>
> v2: (Tvrtko)
> - Include details in commit message
> - Move intel engine busyness function into execlist code
> - Use union inside engine->stats
> - Use natural type for ping delay jiffies
> - Drop active_work condition checks
> - Use for_each_engine if iterating all engines
> - Drop seq locking, use spinlock at guc level to update engine stats
> - Document worker specific details
>
> v3: (Tvrtko/Umesh)
> - Demarcate guc and execlist stat objects with comments
> - Document known over-accounting issue in commit
> - Provide a consistent view of guc state
> - Add hooks to gt park/unpark for guc busyness
> - Stop/start worker in gt park/unpark path
> - Drop inline
> - Move spinlock and worker inits to guc initialization
> - Drop helpers that are called only once
>
> Signed-off-by: John Harrison
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 26 +-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 90 +--
> .../drm/i915/gt/intel_execlists_submission.c | 32 +++
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 26 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 21 ++
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h| 5 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 13 +
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 227 ++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> 12 files changed, 398 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 2ae57e4656a3..6fcc70a313d9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1873,22 +1873,6 @@ void intel_engine_dump(struct intel_engine_cs *engine,
> intel_engine_print_breadcrumbs(engine, m);
> }
>
> -static ktime_t __intel_engine_get_busy_time(struct intel_engine_cs *engine,
> - ktime_t *now)
> -{
> - ktime_t total = engine->stats.total;
> -
> - /*
> - * If the engine is executing something at the moment
> - * add it to the total.
> - */
> - *now = ktime_get();
> - if (READ_ONCE(engine->stats.active))
> - total = ktime_add(total, ktime_sub(*now, engine->stats.start));
> -
> - return total;
> -}
> -
> /**
> * intel_engine_get_busy_time() - Return current accumulated engine busyness
> * @engine: engine to report on
> @@ -1898,15 +1882,7 @@ static ktime_t __intel_engine_get_busy_time(struct
> intel_engine_cs *engine,
> */
> ktime_t intel_engine_get_busy_t
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: remove IS_ACTIVE (rev3)
== Series Details == Series: drm/i915: remove IS_ACTIVE (rev3) URL : https://patchwork.freedesktop.org/series/95312/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21253_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21253_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21253_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_21253_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@pi-common@vecs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-skl8/igt@gem_exec_schedule@pi-com...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-skl6/igt@gem_exec_schedule@pi-com...@vecs0.html Known issues Here are the changes found in Patchwork_21253_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#180]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +4 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-snb5/igt@gem_ctx_persiste...@process.html * igt@gem_ctx_sseu@invalid-args: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#280]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-tglb8/igt@gem_ctx_s...@invalid-args.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: NOTRUN -> [FAIL][6] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_schedule@pi-ringfull@vcs0: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#3397]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-skl1/igt@gem_exec_schedule@pi-ringf...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-skl8/igt@gem_exec_schedule@pi-ringf...@vcs0.html * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / [i915#95]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk8/igt@gem_exec_whis...@basic-fds-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-glk2/igt@gem_exec_whis...@basic-fds-all.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-apl2/igt@gem_huc_c...@huc-copy.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3323]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-apl6/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3323]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-skl1/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][14] ([i915#3002]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-snb2/igt@gem_userptr_bl...@input-checking.html * igt@gen9_exec_parse@batch-invalid-length: - shard-snb: NOTRUN -> [SKIP][15] ([fdo#109271]) +400 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-snb5/igt@gen9_exec_pa...@batch-invalid-length.html * igt@i915_pm_backlight@fade_with_suspend: - shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([i915#456]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-tglb5/igt@i915_pm_backlight@fade_with_suspend.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-tglb7/igt@i915_pm_backlight@fade_with_suspend.html * igt@i915_pm_dc@dc6-dpms: - shard-kbl: NOTRUN -> [FAIL][18] ([i915#454]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-kbl7/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-kbl: [PASS][19] -> [INCOMPLETE][20] ([i915#151] / [i915#155]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-kbl7/igt@i915_pm_...@system-suspend-modeset.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/shard-kbl4/igt@i915_pm_...@system-susp
[Intel-gfx] [PATCH v3] drm/i915/display: Wait PSR2 get out of deep sleep to update pipe
Alderlake-P was getting 'max time under evasion' messages when PSR2
is enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a
period of time longer than VBLANK_EVASION_TIME_US.
For PSR1 we had the same issue so intel_psr_wait_for_idle() was
implemented to wait for PSR1 to get into idle state but nothing was
done for PSR2.
For PSR2 we can't only wait for idle state as PSR2 tends to keep
into sleep state(ready to send selective updates).
Waiting for any state below deep sleep proved to be effective in
avoiding the evasion messages and also not wasted a lot of time.
v2:
- dropping the additional wait_for loops, only the _wait_for_atomic()
is necessary
- waiting for states below EDP_PSR2_STATUS_STATE_DEEP_SLEEP
v3:
- dropping intel_wait_for_condition_atomic() function
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_debugfs.c | 3 +-
drivers/gpu/drm/i915/display/intel_psr.c | 52 +++
drivers/gpu/drm/i915/i915_reg.h | 10 ++--
3 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 309d74fd86ce1..d7dd3a57c6170 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -303,8 +303,7 @@ psr_source_status(struct intel_dp *intel_dp, struct
seq_file *m)
};
val = intel_de_read(dev_priv,
EDP_PSR2_STATUS(intel_dp->psr.transcoder));
- status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
- EDP_PSR2_STATUS_STATE_SHIFT;
+ status_val = REG_FIELD_GET(EDP_PSR2_STATUS_STATE_MASK, val);
if (status_val < ARRAY_SIZE(live_status))
status = live_status[status_val];
} else {
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 7a205fd5023bb..ade514fc0a24d 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1809,15 +1809,21 @@ void intel_psr_post_plane_update(const struct
intel_atomic_state *state)
_intel_psr_post_plane_update(state, crtc_state);
}
-/**
- * psr_wait_for_idle - wait for PSR1 to idle
- * @intel_dp: Intel DP
- * @out_value: PSR status in case of failure
- *
- * Returns: 0 on success or -ETIMEOUT if PSR status does not idle.
- *
- */
-static int psr_wait_for_idle(struct intel_dp *intel_dp, u32 *out_value)
+static int _psr2_ready_for_pipe_update_locked(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ /*
+* Any state lower than EDP_PSR2_STATUS_STATE_DEEP_SLEEP is enough.
+* As all higher states has bit 4 of PSR2 state set we can just wait for
+* EDP_PSR2_STATUS_STATE_DEEP_SLEEP to be cleared.
+*/
+ return intel_de_wait_for_clear(dev_priv,
+
EDP_PSR2_STATUS(intel_dp->psr.transcoder),
+ EDP_PSR2_STATUS_STATE_DEEP_SLEEP, 50);
+}
+
+static int _psr1_ready_for_pipe_update_locked(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1827,15 +1833,13 @@ static int psr_wait_for_idle(struct intel_dp *intel_dp,
u32 *out_value)
* exit training time + 1.5 ms of aux channel handshake. 50 ms is
* defensive enough to cover everything.
*/
- return __intel_wait_for_register(&dev_priv->uncore,
-
EDP_PSR_STATUS(intel_dp->psr.transcoder),
-EDP_PSR_STATUS_STATE_MASK,
-EDP_PSR_STATUS_STATE_IDLE, 2, 50,
-out_value);
+ return intel_de_wait_for_clear(dev_priv,
+ EDP_PSR_STATUS(intel_dp->psr.transcoder),
+ EDP_PSR_STATUS_STATE_MASK, 50);
}
/**
- * intel_psr_wait_for_idle - wait for PSR1 to idle
+ * intel_psr_wait_for_idle - wait for PSR be ready for a pipe update
* @new_crtc_state: new CRTC state
*
* This function is expected to be called from pipe_update_start() where it is
@@ -1852,19 +1856,23 @@ void intel_psr_wait_for_idle(const struct
intel_crtc_state *new_crtc_state)
for_each_intel_encoder_mask_with_psr(&dev_priv->drm, encoder,
new_crtc_state->uapi.encoder_mask)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- u32 psr_status;
+ int ret;
mutex_lock(&intel_dp->psr.lock);
- if (!intel_dp->psr.enabled || intel_dp->psr.psr2_enabled) {
+
+ if (!intel_dp->psr.enabled) {
mutex_unlock(&inte
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2)
== Series Details == Series: drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2) URL : https://patchwork.freedesktop.org/series/95043/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21254 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21254 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21254, 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_21254/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21254: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_engines: - fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10685/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21254/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html Known issues Here are the changes found in Patchwork_21254 that come from known issues: ### IGT changes ### Issues hit * igt@runner@aborted: - fi-rkl-guc: NOTRUN -> [FAIL][3] ([i915#3928]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21254/fi-rkl-guc/igt@run...@aborted.html [i915#3928]: https://gitlab.freedesktop.org/drm/intel/issues/3928 Participating hosts (41 -> 1) -- ERROR: It appears as if the changes made in Patchwork_21254 prevented too many machines from booting. Missing(40): fi-kbl-soraka fi-rkl-11600 bat-dg1-6 fi-bdw-gvtdvm fi-icl-u2 fi-apl-guc fi-snb-2520m fi-pnv-d510 fi-icl-y fi-skl-6600u fi-snb-2600 fi-cml-u2 fi-bxt-dsi fi-bdw-5557u fi-bsw-n3050 fi-tgl-u2 fi-glk-dsi fi-bwr-2160 fi-kbl-7500u fi-ctg-p8600 fi-hsw-4770 fi-ivb-3770 fi-elk-e7500 fi-bsw-nick fi-kbl-r fi-kbl-7567u fi-ilk-m540 fi-tgl-dsi fi-cfl-8700k fi-ehl-2 bat-jsl-1 fi-jsl-1 fi-hsw-4200u fi-tgl-1115g4 fi-bsw-cyan fi-cfl-guc bat-adlp-4 fi-cfl-8109u fi-kbl-8809g fi-bsw-kefka Build changes - * Linux: CI_DRM_10685 -> Patchwork_21254 CI-20190529: 20190529 CI_DRM_10685: 36c3656c997b07f326d6b967efb1b75e01713773 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6232: effad6af5678be711a2c3e58e182319de784de54 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21254: 6044dafc24be45f573885716d0b7ac1b78133e3f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6044dafc24be drm/i915/pmu: Connect engine busyness stats from GuC to pmu == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21254/index.html
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2)
== Series Details == Series: drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2) URL : https://patchwork.freedesktop.org/series/95043/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gt/uc/intel_guc.h:167: warning: Function parameter or member 'timestamp' not described in 'intel_guc'
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2)
== Series Details == Series: drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2) URL : https://patchwork.freedesktop.org/series/95043/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6044dafc24be drm/i915/pmu: Connect engine busyness stats from GuC to pmu -:577: CHECK:SPACING: No space is necessary after a cast #577: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1229: + guc->timestamp.gt_stamp = ((u64) gt_stamp_hi << 32) | gt_stamp_now; total: 0 errors, 0 warnings, 1 checks, 614 lines checked
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915/adlp: Keep hardware default dbox B credits (rev2)
== Series Details == Series: series starting with [1/1] drm/i915/adlp: Keep hardware default dbox B credits (rev2) URL : https://patchwork.freedesktop.org/series/94702/ State : success == Summary == CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21252_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_21252_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21252_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_21252_full: ### IGT changes ### Warnings * igt@i915_pm_dc@dc9-dpms: - shard-iclb: [FAIL][1] -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-iclb8/igt@i915_pm...@dc9-dpms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-iclb3/igt@i915_pm...@dc9-dpms.html Known issues Here are the changes found in Patchwork_21252_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-apl2/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: NOTRUN -> [DMESG-WARN][4] ([i915#180]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-kbl6/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-snb6/igt@gem_ctx_persiste...@process.html * igt@gem_ctx_sseu@invalid-args: - shard-tglb: NOTRUN -> [SKIP][6] ([i915#280]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-tglb5/igt@gem_ctx_s...@invalid-args.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-skl10/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][8] ([i915#2846]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-apl7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: NOTRUN -> [FAIL][12] ([i915#2842]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-kbl2/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +171 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-apl8/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3323]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-apl7/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3323]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-skl10/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][16] ([i915#3002]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-snb2/igt@gem_userptr_bl...@input-checking.html * igt@gen9_exec_parse@batch-invalid-length: - shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271]) +400 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-snb6/igt@gen9_exec_pa...@batch-invalid-length.html * igt@i915_pm_dc@dc6-dpms: - shard-kbl: NOTRUN -> [FAIL][18] ([i915#454]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-kbl2/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_dc@dc6-psr: - shard-skl: NOTRUN -> [FAIL][19] ([i915#454]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/shard-skl10/igt@i915_pm...@dc6-ps
Re: [Intel-gfx] [PATCH v1 1/3] string: Consolidate yesno() helpers under string.h hood
On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
We have already few similar implementation and a lot of code that can benefit
of the yesno() helper. Consolidate yesno() helpers under string.h hood.
I was taking a look on i915_utils.h to reduce it and move some of it
elsewhere to be shared with others. I was starting with these helpers
and had [1] done, then Jani pointed me to this thread and also his
previous tentative. I thought the natural place for this would be
include/linux/string_helpers.h, but I will leave it up to you.
After reading the threads, I don't see real opposition to it.
Is there a tree you plan to take this through?
thanks
Lucas De Marchi
[1]
https://lore.kernel.org/lkml/20211005212634.3223113-1-lucas.demar...@intel.com/T/#u
Signed-off-by: Andy Shevchenko
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c| 6 +-
drivers/gpu/drm/i915/i915_utils.h| 6 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 12 +---
include/linux/string.h | 5 +
4 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 360952129b6d..7fde4f90e513 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -23,6 +23,7 @@
*
*/
+#include
#include
#include
@@ -49,11 +50,6 @@ struct dmub_debugfs_trace_entry {
uint32_t param1;
};
-static inline const char *yesno(bool v)
-{
- return v ? "yes" : "no";
-}
-
/* parse_write_buffer_into_params - Helper function to parse debugfs write
buffer into an array
*
* Function takes in attributes passed to debugfs write entry
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index abd4dcd9f79c..e6da5a951132 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
@@ -408,11 +409,6 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
#define MBps(x) KBps(1000 * (x))
#define GBps(x) ((u64)1000 * MBps((x)))
-static inline const char *yesno(bool v)
-{
- return v ? "yes" : "no";
-}
-
static inline const char *onoff(bool v)
{
return v ? "on" : "off";
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index 7d49fd4edc9e..c857d73abbd7 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -34,6 +34,7 @@
#include
#include
+#include
#include
#include
#include
@@ -2015,17 +2016,6 @@ static const struct file_operations rss_debugfs_fops = {
/* RSS Configuration.
*/
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
- static const char *yes = "yes";
- static const char *no = "no";
-
- return x ? yes : no;
-}
-
static int rss_config_show(struct seq_file *seq, void *v)
{
struct adapter *adapter = seq->private;
diff --git a/include/linux/string.h b/include/linux/string.h
index 9521d8cab18e..fd946a5e18c8 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -308,4 +308,9 @@ static __always_inline size_t str_has_prefix(const char
*str, const char *prefix
return strncmp(str, prefix, len) == 0 ? len : 0;
}
+static inline const char *yesno(bool yes)
+{
+ return yes ? "yes" : "no";
+}
+
#endif /* _LINUX_STRING_H_ */
--
2.30.0
Re: [Intel-gfx] [PATCH] drm/i915/bios: gracefully disable dual eDP for now
On Tue, 2021-10-05 at 23:38 +0300, Jani Nikula wrote:
> On Tue, 05 Oct 2021, "Souza, Jose" wrote:
> > On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
> > > For the time being, neither the power sequencer nor the backlight code
> > > properly support two eDP panels simultaneously. While the software
> > > states will be independent, the same sets of registers will be used for
> > > both eDP panels, clobbering the hardware state and leading to errors.
> > >
> > > Gracefully disable dual eDP until proper support has been added.
> > >
> > > Cc: José Roberto de Souza
> > > Cc: Uma Shankar
> > > Cc: Ville Syrjälä
> > > Cc: Swati Sharma
> > > Signed-off-by: Jani Nikula
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bios.c | 47 +++
> > > 1 file changed, 47 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > > b/drivers/gpu/drm/i915/display/intel_bios.c
> > > index f9776ca85de3..b99907c656bb 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > > @@ -1930,6 +1930,50 @@ static int _intel_bios_max_tmds_clock(const struct
> > > intel_bios_encoder_data *devd
> > > }
> > > }
> > >
> > > +static enum port get_edp_port(struct drm_i915_private *i915)
> > > +{
> > > + const struct intel_bios_encoder_data *devdata;
> > > + enum port port;
> > > +
> > > + for_each_port(port) {
> > > + devdata = i915->vbt.ports[port];
> > > +
> > > + if (devdata && intel_bios_encoder_supports_edp(devdata))
> > > + return port;
> > > + }
> > > +
> > > + return PORT_NONE;
> > > +}
> > > +
> > > +/*
> > > + * FIXME: The power sequencer and backlight code currently do not
> > > support more
> > > + * than one set registers, at least not on anything other than VLV/CHV.
> > > It will
> > > + * clobber the registers. As a temporary workaround, gracefully prevent
> > > more
> > > + * than one eDP from being registered.
> > > + */
> > > +static void sanitize_dual_edp(struct intel_bios_encoder_data *devdata,
> > > + enum port port)
> > > +{
> > > + struct drm_i915_private *i915 = devdata->i915;
> > > + struct child_device_config *child = &devdata->child;
> > > + enum port p;
> > > +
> > > + /* CHV might not clobber PPS registers. */
> > > + if (IS_CHERRYVIEW(i915))
> > > + return;
> > > +
> > > + p = get_edp_port(i915);
> > > + if (p == PORT_NONE)
> > > + return;
> > > +
> > > + drm_dbg_kms(&i915->drm, "both ports %c and %c configured as eDP, "
> > > + "disabling port %c eDP\n", port_name(p), port_name(port),
> > > + port_name(port));
> > > +
> > > + child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;
> >
> > Why also cleaning the DEVICE_TYPE_DISPLAYPORT_OUTPUT bit? The rest lgtm.
>
> Could've leaned one way or the other, but do we really want to
> initialize a regular DP on the port?
Yeah, lets go without.
Reviewed-by: José Roberto de Souza
>
> BR,
> Jani.
>
> >
> > > + child->device_type &= ~DEVICE_TYPE_INTERNAL_CONNECTOR;
> > > +}
> > > +
> > > static bool is_port_valid(struct drm_i915_private *i915, enum port port)
> > > {
> > > /*
> > > @@ -1987,6 +2031,9 @@ static void parse_ddi_port(struct drm_i915_private
> > > *i915,
> > > supports_typec_usb, supports_tbt,
> > > devdata->dsc != NULL);
> > >
> > > + if (is_edp)
> > > + sanitize_dual_edp(devdata, port);
> > > +
> > > if (is_dvi)
> > > sanitize_ddc_pin(devdata, port);
> > >
> >
>
Re: [Intel-gfx] [PATCH] drm/i915/bios: gracefully disable dual eDP for now
On Tue, 05 Oct 2021, "Souza, Jose" wrote:
> On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
>> For the time being, neither the power sequencer nor the backlight code
>> properly support two eDP panels simultaneously. While the software
>> states will be independent, the same sets of registers will be used for
>> both eDP panels, clobbering the hardware state and leading to errors.
>>
>> Gracefully disable dual eDP until proper support has been added.
>>
>> Cc: José Roberto de Souza
>> Cc: Uma Shankar
>> Cc: Ville Syrjälä
>> Cc: Swati Sharma
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_bios.c | 47 +++
>> 1 file changed, 47 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index f9776ca85de3..b99907c656bb 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -1930,6 +1930,50 @@ static int _intel_bios_max_tmds_clock(const struct
>> intel_bios_encoder_data *devd
>> }
>> }
>>
>> +static enum port get_edp_port(struct drm_i915_private *i915)
>> +{
>> +const struct intel_bios_encoder_data *devdata;
>> +enum port port;
>> +
>> +for_each_port(port) {
>> +devdata = i915->vbt.ports[port];
>> +
>> +if (devdata && intel_bios_encoder_supports_edp(devdata))
>> +return port;
>> +}
>> +
>> +return PORT_NONE;
>> +}
>> +
>> +/*
>> + * FIXME: The power sequencer and backlight code currently do not support
>> more
>> + * than one set registers, at least not on anything other than VLV/CHV. It
>> will
>> + * clobber the registers. As a temporary workaround, gracefully prevent more
>> + * than one eDP from being registered.
>> + */
>> +static void sanitize_dual_edp(struct intel_bios_encoder_data *devdata,
>> + enum port port)
>> +{
>> +struct drm_i915_private *i915 = devdata->i915;
>> +struct child_device_config *child = &devdata->child;
>> +enum port p;
>> +
>> +/* CHV might not clobber PPS registers. */
>> +if (IS_CHERRYVIEW(i915))
>> +return;
>> +
>> +p = get_edp_port(i915);
>> +if (p == PORT_NONE)
>> +return;
>> +
>> +drm_dbg_kms(&i915->drm, "both ports %c and %c configured as eDP, "
>> +"disabling port %c eDP\n", port_name(p), port_name(port),
>> +port_name(port));
>> +
>> +child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;
>
> Why also cleaning the DEVICE_TYPE_DISPLAYPORT_OUTPUT bit? The rest lgtm.
Could've leaned one way or the other, but do we really want to
initialize a regular DP on the port?
BR,
Jani.
>
>> +child->device_type &= ~DEVICE_TYPE_INTERNAL_CONNECTOR;
>> +}
>> +
>> static bool is_port_valid(struct drm_i915_private *i915, enum port port)
>> {
>> /*
>> @@ -1987,6 +2031,9 @@ static void parse_ddi_port(struct drm_i915_private
>> *i915,
>> supports_typec_usb, supports_tbt,
>> devdata->dsc != NULL);
>>
>> +if (is_edp)
>> +sanitize_dual_edp(devdata, port);
>> +
>> if (is_dvi)
>> sanitize_ddc_pin(devdata, port);
>>
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 0/4] drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
On Sat, 2021-10-02 at 11:14 +0200, Hans de Goede wrote: > Hi Lyude, > > On 10/2/21 12:53 AM, Lyude Paul wrote: > > When I originally moved all of the VESA backlight code in i915 into DRM > > helpers, one of the things I didn't have the hardware or time for > > testing was machines that used a combination of PWM and DPCD in order to > > control their backlights. This has since then caused some breakages and > > resulted in us disabling DPCD backlight support on such machines. This > > works fine, unless you have a machine that actually needs this > > functionality for backlight controls to work at all. Additionally, we > > will need to support PWM for when we start adding support for VESA's > > product (as in the product of multiplication) control mode for better > > brightness ranges. > > > > So - let's finally finish up implementing basic support for these types > > of backlights to solve these problems in our DP helpers, along with > > implementing support for this in i915. And since digging into this issue > > solved the last questions we really had about probing backlights in i915 > > for the most part, let's update some of the comments around that as > > well! > > Backlight control is a topic which I'm reasonably familiar with, > do you want me to review this series for you ? Possibly, although I definitely want to make sure that someone from Intel gets a chance to review this as well. I'm more curious if you might happen to have any systems that would be able to test this. > > Regards, > > Hans > > > > > > > Changes: > > * Fixup docs > > * Add patch to stop us from breaking nouveau > > > > Lyude Paul (4): > > drm/i915: Add support for panels with VESA backlights with PWM > > enable/disable > > drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux > > enable/brightness > > drm/dp, drm/i915: Add support for VESA backlights using PWM for > > brightness control > > drm/i915: Clarify probing order in intel_dp_aux_init_backlight_funcs() > > > > drivers/gpu/drm/drm_dp_helper.c | 75 +++-- > > .../drm/i915/display/intel_dp_aux_backlight.c | 80 ++- > > drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 +- > > include/drm/drm_dp_helper.h | 7 +- > > 4 files changed, 122 insertions(+), 45 deletions(-) > > > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
[Intel-gfx] [PATCH 10/10] drm/i915: Add privacy-screen support (v3)
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
Changes in v3:
- Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector()
Changes in v2:
- Call drm_connector_update_privacy_screen() from
intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
- Move the probe-deferral check to the intel_modeset_probe_defer() helper
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
drivers/gpu/drm/i915/display/intel_ddi.c | 16
drivers/gpu/drm/i915/display/intel_display.c | 10 ++
3 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index b4e7ac51aa31..a62550711e98 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -139,6 +139,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode ||
+ new_conn_state->base.privacy_screen_sw_state !=
old_conn_state->base.privacy_screen_sw_state ||
!drm_connector_atomic_hdr_metadata_equal(old_state, new_state))
crtc_state->mode_changed = true;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0d4cf7fa8720..272714e07cc6 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -25,6 +25,7 @@
*
*/
+#include
#include
#include "i915_drv.h"
@@ -2946,6 +2947,7 @@ static void intel_enable_ddi_dp(struct intel_atomic_state
*state,
if (port == PORT_A && DISPLAY_VER(dev_priv) < 9)
intel_dp_stop_link_train(intel_dp, crtc_state);
+ drm_connector_update_privacy_screen(conn_state);
intel_edp_backlight_on(crtc_state, conn_state);
if (!dig_port->lspcon.active || dig_port->dp.has_hdmi_sink)
@@ -3161,6 +3163,7 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_drrs_update(intel_dp, crtc_state);
intel_backlight_update(state, encoder, crtc_state, conn_state);
+ drm_connector_update_privacy_screen(conn_state);
}
void intel_ddi_update_pipe(struct intel_atomic_state *state,
@@ -3979,6 +3982,19 @@ intel_ddi_init_dp_connector(struct intel_digital_port
*dig_port)
return NULL;
}
+ if (dig_port->base.type == INTEL_OUTPUT_EDP) {
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_privacy_screen *privacy_screen;
+
+ privacy_screen = drm_privacy_screen_get(dev->dev, NULL);
+ if (!IS_ERR(privacy_screen)) {
+
drm_connector_attach_privacy_screen_provider(&connector->base,
+
privacy_screen);
+ } else if (PTR_ERR(privacy_screen) != -ENODEV) {
+ drm_warn(dev, "Error getting privacy-screen\n");
+ }
+ }
+
return connector;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 86dbe366a907..84715a779d9d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
@@ -12769,6 +12770,8 @@ void intel_modeset_driver_remove_nogem(struct
drm_i915_private *i915)
bool intel_modeset_probe_defer(struct pci_dev *pdev)
{
+ struct drm_privacy_screen *privacy_screen;
+
/*
* apple-gmux is needed on dual GPU MacBook Pro
* to probe the panel if we're the inactive GPU.
@@ -12776,6 +12779,13 @@ bool intel_modeset_probe_defer(struct pci_dev *pdev)
if (vga_switcheroo_client_probe_defer(pdev))
return true;
+ /* If the LCD panel has a privacy-screen, wait for it */
+ privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
+ if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
+ return true;
+
+ drm_privacy_screen_put(privacy_screen);
+
return false;
}
--
2.31.1
[Intel-gfx] [PATCH 09/10] drm/i915: Add intel_modeset_probe_defer() helper
The upcoming privacy-screen support adds another check for
deferring probe till some other drivers have bound first.
Factor out the current vga_switcheroo_client_probe_defer() check
into an intel_modeset_probe_defer() helper, so that further
probe-deferral checks can be added there.
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
drivers/gpu/drm/i915/display/intel_display.h | 1 +
drivers/gpu/drm/i915/i915_pci.c | 9 ++---
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 4f0badb11bbb..86dbe366a907 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -12766,6 +12767,18 @@ void intel_modeset_driver_remove_nogem(struct
drm_i915_private *i915)
intel_bios_driver_remove(i915);
}
+bool intel_modeset_probe_defer(struct pci_dev *pdev)
+{
+ /*
+* apple-gmux is needed on dual GPU MacBook Pro
+* to probe the panel if we're the inactive GPU.
+*/
+ if (vga_switcheroo_client_probe_defer(pdev))
+ return true;
+
+ return false;
+}
+
void intel_display_driver_register(struct drm_i915_private *i915)
{
if (!HAS_DISPLAY(i915))
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 3028072c2cf3..d3d34acb6c08 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -633,6 +633,7 @@ void intel_display_driver_register(struct drm_i915_private
*i915);
void intel_display_driver_unregister(struct drm_i915_private *i915);
/* modesetting */
+bool intel_modeset_probe_defer(struct pci_dev *pdev);
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init_noirq(struct drm_i915_private *i915);
int intel_modeset_init_nogem(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 169837de395d..8fc45d8119b6 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -22,8 +22,6 @@
*
*/
-#include
-
#include
#include
@@ -1189,11 +1187,8 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (PCI_FUNC(pdev->devfn))
return -ENODEV;
- /*
-* apple-gmux is needed on dual GPU MacBook Pro
-* to probe the panel if we're the inactive GPU.
-*/
- if (vga_switcheroo_client_probe_defer(pdev))
+ /* Detect if we need to wait for other drivers early on */
+ if (intel_modeset_probe_defer(pdev))
return -EPROBE_DEFER;
err = i915_driver_probe(pdev, ent);
--
2.31.1
[Intel-gfx] [PATCH 08/10] platform/x86: thinkpad_acpi: Register a privacy-screen device
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also allow the GPU driver to get a handle to it and export
the privacy-screen setting as a property on the DRM connector object
for the LCD panel. This DRM connector property is a new standardized
interface which all user-space code should use to query and control
the privacy-screen.
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
Changes in v3:
- On receiving a TP_HKEY_EV_PRIVACYGUARD_TOGGLE event only call
drm_privacy_screen_call_notifier_chain() if the privacy-screen state
has actually changed
Changes in v2:
- Make the new lcdshadow_set_sw_state, lcdshadow_get_hw_state and
lcdshadow_ops symbols static
- Update state and call drm_privacy_screen_call_notifier_chain()
when the state is changed by pressing the Fn + D hotkey combo
---
drivers/platform/x86/Kconfig | 2 +
drivers/platform/x86/thinkpad_acpi.c | 97 +---
2 files changed, 74 insertions(+), 25 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index e21ea3d23e6f..20208207e366 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -501,7 +501,9 @@ config THINKPAD_ACPI
depends on ACPI_VIDEO || ACPI_VIDEO = n
depends on BACKLIGHT_CLASS_DEVICE
depends on I2C
+ depends on DRM
select ACPI_PLATFORM_PROFILE
+ select DRM_PRIVACY_SCREEN
select HWMON
select NVRAM
select NEW_LEDS
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index b8f2556c4797..291cd18c9c8f 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -73,6 +73,7 @@
#include
#include
#include
+#include
#include "dual_accel_detect.h"
/* ThinkPad CMOS commands */
@@ -157,6 +158,7 @@ enum tpacpi_hkey_event_t {
TP_HKEY_EV_VOL_UP = 0x1015, /* Volume up or unmute */
TP_HKEY_EV_VOL_DOWN = 0x1016, /* Volume down or unmute */
TP_HKEY_EV_VOL_MUTE = 0x1017, /* Mixer output mute */
+ TP_HKEY_EV_PRIVACYGUARD_TOGGLE = 0x130f, /* Toggle priv.guard on/off */
/* Reasons for waking up from S3/S4 */
TP_HKEY_EV_WKUP_S3_UNDOCK = 0x2304, /* undock requested, S3 */
@@ -3889,6 +3891,12 @@ static bool hotkey_notify_extended_hotkey(const u32 hkey)
{
unsigned int scancode;
+ switch (hkey) {
+ case TP_HKEY_EV_PRIVACYGUARD_TOGGLE:
+ tpacpi_driver_event(hkey);
+ return true;
+ }
+
/* Extended keycodes start at 0x300 and our offset into the map
* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
* will be positive, but might not be in the correct range.
@@ -9819,30 +9827,40 @@ static struct ibm_struct battery_driver_data = {
* LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
*/
+static struct drm_privacy_screen *lcdshadow_dev;
static acpi_handle lcdshadow_get_handle;
static acpi_handle lcdshadow_set_handle;
-static int lcdshadow_state;
-static int lcdshadow_on_off(bool state)
+static int lcdshadow_set_sw_state(struct drm_privacy_screen *priv,
+ enum drm_privacy_screen_status state)
{
int output;
+ if (WARN_ON(!mutex_is_locked(&priv->lock)))
+ return -EIO;
+
if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
return -EIO;
- lcdshadow_state = state;
+ priv->hw_state = priv->sw_state = state;
return 0;
}
-static int lcdshadow_set(bool on)
+static void lcdshadow_get_hw_state(struct drm_privacy_screen *priv)
{
- if (lcdshadow_state < 0)
- return lcdshadow_state;
- if (lcdshadow_state == on)
- return 0;
- return lcdshadow_on_off(on);
+ int output;
+
+ if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0))
+ return;
+
+ priv->hw_state = priv->sw_state = output & 0x1;
}
+static const struct drm_privacy_screen_ops lcdshadow_ops = {
+ .set_sw_state = lcdshadow_set_sw_state,
+ .get_hw_state = lcdshadow_get_hw_state,
+};
+
static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
{
acpi_status status1, status2;
@@ -9850,36 +9868,44 @@ static int tpacpi_lcdshadow_init(struct ibm_init_struct
*iibm)
status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
status2 = acpi_get_handle(hkey_handle, "", &lcdshadow_set_handle);
- if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
- lcdshadow_state = -ENODEV;
+ if (ACPI_FAILURE(status1) || ACPI_FAILURE(s
[Intel-gfx] [PATCH 07/10] platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 83c88a8ebaf2..b8f2556c4797 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -9819,19 +9819,15 @@ static struct ibm_struct battery_driver_data = {
* LCD Shadow subdriver, for the Lenovo PrivacyGuard feature
*/
+static acpi_handle lcdshadow_get_handle;
+static acpi_handle lcdshadow_set_handle;
static int lcdshadow_state;
static int lcdshadow_on_off(bool state)
{
- acpi_handle set_shadow_handle;
int output;
- if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "",
&set_shadow_handle))) {
- pr_warn("Thinkpad ACPI has no %s interface.\n", "");
- return -EIO;
- }
-
- if (!acpi_evalf(set_shadow_handle, &output, NULL, "dd", (int)state))
+ if (!acpi_evalf(lcdshadow_set_handle, &output, NULL, "dd", (int)state))
return -EIO;
lcdshadow_state = state;
@@ -9849,15 +9845,17 @@ static int lcdshadow_set(bool on)
static int tpacpi_lcdshadow_init(struct ibm_init_struct *iibm)
{
- acpi_handle get_shadow_handle;
+ acpi_status status1, status2;
int output;
- if (ACPI_FAILURE(acpi_get_handle(hkey_handle, "GSSS",
&get_shadow_handle))) {
+ status1 = acpi_get_handle(hkey_handle, "GSSS", &lcdshadow_get_handle);
+ status2 = acpi_get_handle(hkey_handle, "", &lcdshadow_set_handle);
+ if (ACPI_FAILURE(status1) || ACPI_FAILURE(status2)) {
lcdshadow_state = -ENODEV;
return 0;
}
- if (!acpi_evalf(get_shadow_handle, &output, NULL, "dd", 0)) {
+ if (!acpi_evalf(lcdshadow_get_handle, &output, NULL, "dd", 0)) {
lcdshadow_state = -EIO;
return -EIO;
}
--
2.31.1
[Intel-gfx] [PATCH 06/10] platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 30 ++--
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 50ff04c84650..83c88a8ebaf2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3885,6 +3885,24 @@ static bool
adaptive_keyboard_hotkey_notify_hotkey(unsigned int scancode)
}
}
+static bool hotkey_notify_extended_hotkey(const u32 hkey)
+{
+ unsigned int scancode;
+
+ /* Extended keycodes start at 0x300 and our offset into the map
+* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
+* will be positive, but might not be in the correct range.
+*/
+ scancode = (hkey & 0xfff) - (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
+ if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
+ scancode < TPACPI_HOTKEY_MAP_LEN) {
+ tpacpi_input_send_key(scancode);
+ return true;
+ }
+
+ return false;
+}
+
static bool hotkey_notify_hotkey(const u32 hkey,
bool *send_acpi_ev,
bool *ignore_acpi_ev)
@@ -3919,17 +3937,7 @@ static bool hotkey_notify_hotkey(const u32 hkey,
return adaptive_keyboard_hotkey_notify_hotkey(scancode);
case 3:
- /* Extended keycodes start at 0x300 and our offset into the map
-* TP_ACPI_HOTKEYSCAN_EXTENDED_START. The calculated scancode
-* will be positive, but might not be in the correct range.
-*/
- scancode -= (0x300 - TP_ACPI_HOTKEYSCAN_EXTENDED_START);
- if (scancode >= TP_ACPI_HOTKEYSCAN_EXTENDED_START &&
- scancode < TPACPI_HOTKEY_MAP_LEN) {
- tpacpi_input_send_key(scancode);
- return true;
- }
- break;
+ return hotkey_notify_extended_hotkey(hkey);
}
return false;
--
2.31.1
[Intel-gfx] [PATCH 05/10] drm/connector: Add a drm_connector privacy-screen helper functions (v2)
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen status.
2. drm_connector_update_privacy_screen(), update the privacy-screen's
sw_state if the connector has a privacy-screen.
Changes in v2:
- Do not update connector->state->privacy_screen_sw_state on
atomic-commits.
- Change drm_connector_update_privacy_screen() to take drm_connector_state
as argument instead of a full drm_atomic_state. This allows the helper
to be called by drivers when they are enabling crtcs/encoders/connectors.
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 102
include/drm/drm_connector.h | 11
2 files changed, 113 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b2f1f1b1bfb4..00cf3b6135f6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -462,6 +463,11 @@ void drm_connector_cleanup(struct drm_connector *connector)
DRM_CONNECTOR_REGISTERED))
drm_connector_unregister(connector);
+ if (connector->privacy_screen) {
+ drm_privacy_screen_put(connector->privacy_screen);
+ connector->privacy_screen = NULL;
+ }
+
if (connector->tile_group) {
drm_mode_put_tile_group(dev, connector->tile_group);
connector->tile_group = NULL;
@@ -543,6 +549,10 @@ int drm_connector_register(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(connector->dev);
+ if (connector->privacy_screen)
+ drm_privacy_screen_register_notifier(connector->privacy_screen,
+ &connector->privacy_screen_notifier);
+
mutex_lock(&connector_list_lock);
list_add_tail(&connector->global_connector_list_entry, &connector_list);
mutex_unlock(&connector_list_lock);
@@ -578,6 +588,11 @@ void drm_connector_unregister(struct drm_connector
*connector)
list_del_init(&connector->global_connector_list_entry);
mutex_unlock(&connector_list_lock);
+ if (connector->privacy_screen)
+ drm_privacy_screen_unregister_notifier(
+ connector->privacy_screen,
+ &connector->privacy_screen_notifier);
+
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
@@ -2442,6 +2457,93 @@ drm_connector_attach_privacy_screen_properties(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_connector_attach_privacy_screen_properties);
+static void drm_connector_update_privacy_screen_properties(
+ struct drm_connector *connector, bool set_sw_state)
+{
+ enum drm_privacy_screen_status sw_state, hw_state;
+
+ drm_privacy_screen_get_state(connector->privacy_screen,
+&sw_state, &hw_state);
+
+ if (set_sw_state)
+ connector->state->privacy_screen_sw_state = sw_state;
+ drm_object_property_set_value(&connector->base,
+ connector->privacy_screen_hw_state_property, hw_state);
+}
+
+static int drm_connector_privacy_screen_notifier(
+ struct notifier_block *nb, unsigned long action, void *data)
+{
+ struct drm_connector *connector =
+ container_of(nb, struct drm_connector, privacy_screen_notifier);
+ struct drm_device *dev = connector->dev;
+
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+ drm_connector_update_privacy_screen_properties(connector, true);
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_sw_state_property);
+ drm_sysfs_connector_status_event(connector,
+ connector->privacy_screen_hw_state_property);
+
+ return NOTIFY_DONE;
+}
+
+/**
+ * drm_connector_attach_privacy_screen_provider - attach a privacy-screen to
+ *the connector
+ * @connector: connector to attach the privacy-screen to
+ * @priv: drm_privacy_screen to attach
+ *
+ * Create and attach the standard privacy-screen properties and register
+ * a generic notifier for generating sysfs-connector-status-events
+ * on external changes to the privacy-screen status.
+ * This function takes ownership of the passed in drm_privacy_screen and will
+ * call drm_privacy_screen_put() on it when the connector is destroyed.
+ */
+void drm_connector_attach_privacy_screen
[Intel-gfx] [PATCH 04/10] drm/privacy-screen: Add notifier support (v2)
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Changes in v2:
- Drop WARN_ON(mutex_is_locked(&priv->lock)) check in
drm_privacy_screen_call_notifier_chain() it may be locked by
another thread, which would lead to a false-positive triggering
of the check
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 64 +++
include/drm/drm_privacy_screen_consumer.h | 15 ++
include/drm/drm_privacy_screen_driver.h | 4 ++
3 files changed, 83 insertions(+)
diff --git a/drivers/gpu/drm/drm_privacy_screen.c
b/drivers/gpu/drm/drm_privacy_screen.c
index 183a6011adf0..beaf99e9120a 100644
--- a/drivers/gpu/drm/drm_privacy_screen.c
+++ b/drivers/gpu/drm/drm_privacy_screen.c
@@ -257,6 +257,49 @@ void drm_privacy_screen_get_state(struct
drm_privacy_screen *priv,
}
EXPORT_SYMBOL(drm_privacy_screen_get_state);
+/**
+ * drm_privacy_screen_register_notifier - register a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Register a notifier with the privacy-screen to be notified of changes made
+ * to the privacy-screen state from outside of the privacy-screen class.
+ * E.g. the state may be changed by the hardware itself in response to a
+ * hotkey press.
+ *
+ * The notifier is called with no locks held. The new hw_state and sw_state
+ * can be retrieved using the drm_privacy_screen_get_state() function.
+ * A pointer to the drm_privacy_screen's struct is passed as the void *data
+ * argument of the notifier_block's notifier_call.
+ *
+ * The notifier will NOT be called when changes are made through
+ * drm_privacy_screen_set_sw_state(). It is only called for external changes.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_register_notifier(struct drm_privacy_screen *priv,
+struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_register_notifier);
+
+/**
+ * drm_privacy_screen_unregister_notifier - unregister a notifier
+ * @priv: Privacy screen to register the notifier with
+ * @nb: Notifier-block for the notifier to register
+ *
+ * Unregister a notifier registered with
drm_privacy_screen_register_notifier().
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int drm_privacy_screen_unregister_notifier(struct drm_privacy_screen *priv,
+ struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&priv->notifier_head, nb);
+}
+EXPORT_SYMBOL(drm_privacy_screen_unregister_notifier);
+
/*** drm_privacy_screen_driver.h functions ***/
static ssize_t sw_state_show(struct device *dev,
@@ -354,6 +397,7 @@ struct drm_privacy_screen *drm_privacy_screen_register(
return ERR_PTR(-ENOMEM);
mutex_init(&priv->lock);
+ BLOCKING_INIT_NOTIFIER_HEAD(&priv->notifier_head);
priv->dev.class = drm_class;
priv->dev.type = &drm_privacy_screen_type;
@@ -401,3 +445,23 @@ void drm_privacy_screen_unregister(struct
drm_privacy_screen *priv)
device_unregister(&priv->dev);
}
EXPORT_SYMBOL(drm_privacy_screen_unregister);
+
+/**
+ * drm_privacy_screen_call_notifier_chain - notify consumers of state change
+ * @priv: Privacy screen to register the notifier with
+ *
+ * A privacy-screen provider driver can call this functions upon external
+ * changes to the privacy-screen state. E.g. the state may be changed by the
+ * hardware itself in response to a hotkey press.
+ * This function must be called without holding the privacy-screen lock.
+ * the driver must update sw_state and hw_state to reflect the new state before
+ * calling this function.
+ * The expected behavior from the driver upon receiving an external state
+ * change event is: 1. Take the lock; 2. Update sw_state and hw_state;
+ * 3. Release the lock. 4. Call drm_privacy_screen_call_notifier_chain().
+ */
+void drm_privacy_screen_call_notifier_chain(struct drm_privacy_screen *priv)
+{
+ blocking_notifier_call_chain(&priv->notifier_head, 0, priv);
+}
+EXPORT_SYMBOL(drm_privacy_screen_call_notifier_chain);
diff --git a/include/drm/drm_privacy_screen_consumer.h
b/include/drm/drm_privacy_screen_consumer.h
index 0cbd23b0453d..7f66a90d15b7 100644
--- a/include/drm/drm_privacy_screen_consumer.h
+++ b/include/drm/drm_privacy_screen_consumer.h
@@ -24,6 +24,11 @@ int drm_privacy_screen_set_sw_state(struct
drm_privacy_screen *priv,
void drm_privacy_screen_get_state(struct drm_privacy_screen *priv,
enum drm_privacy_screen_status *sw_state_ret,
enum drm_privacy_screen_status *hw_state_ret);
+
+int drm_privacy_screen_register_notifier(st
[Intel-gfx] [PATCH 03/10] drm/privacy-screen: Add X86 specific arch init code
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_privacy_screen_x86.c | 86
include/drm/drm_privacy_screen_machine.h | 5 ++
3 files changed, 92 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 788fc37096f6..12997ca5670d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,7 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
-drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
drm_privacy_screen_x86.o
obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c
b/drivers/gpu/drm/drm_privacy_screen_x86.c
new file mode 100644
index ..a2cafb294ca6
--- /dev/null
+++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright (C) 2020 Red Hat, Inc.
+ *
+ * Authors:
+ * Hans de Goede
+ */
+
+#include
+#include
+
+#ifdef CONFIG_X86
+static struct drm_privacy_screen_lookup arch_lookup;
+
+struct arch_init_data {
+ struct drm_privacy_screen_lookup lookup;
+ bool (*detect)(void);
+};
+
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+static acpi_status __init acpi_set_handle(acpi_handle handle, u32 level,
+ void *context, void **return_value)
+{
+ *(acpi_handle *)return_value = handle;
+ return AE_CTRL_TERMINATE;
+}
+
+static bool __init detect_thinkpad_privacy_screen(void)
+{
+ union acpi_object obj = { .type = ACPI_TYPE_INTEGER };
+ struct acpi_object_list args = { .count = 1, .pointer = &obj, };
+ acpi_handle ec_handle = NULL;
+ unsigned long long output;
+ acpi_status status;
+
+ /* Get embedded-controller handle */
+ status = acpi_get_devices("PNP0C09", acpi_set_handle, NULL, &ec_handle);
+ if (ACPI_FAILURE(status) || !ec_handle)
+ return false;
+
+ /* And call the privacy-screen get-status method */
+ status = acpi_evaluate_integer(ec_handle, "HKEY.GSSS", &args, &output);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ return (output & 0x1) ? true : false;
+}
+#endif
+
+static const struct arch_init_data arch_init_data[] __initconst = {
+#if IS_ENABLED(CONFIG_THINKPAD_ACPI)
+ {
+ .lookup = {
+ .dev_id = NULL,
+ .con_id = NULL,
+ .provider = "privacy_screen-thinkpad_acpi",
+ },
+ .detect = detect_thinkpad_privacy_screen,
+ },
+#endif
+};
+
+void __init drm_privacy_screen_lookup_init(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(arch_init_data); i++) {
+ if (!arch_init_data[i].detect())
+ continue;
+
+ pr_info("Found '%s' privacy-screen provider\n",
+ arch_init_data[i].lookup.provider);
+
+ /* Make a copy because arch_init_data is __initconst */
+ arch_lookup = arch_init_data[i].lookup;
+ drm_privacy_screen_lookup_add(&arch_lookup);
+ break;
+ }
+}
+
+void drm_privacy_screen_lookup_exit(void)
+{
+ if (arch_lookup.provider)
+ drm_privacy_screen_lookup_remove(&arch_lookup);
+}
+#endif /* ifdef CONFIG_X86 */
diff --git a/include/drm/drm_privacy_screen_machine.h
b/include/drm/drm_privacy_screen_machine.h
index aaa0d38cce92..02e5371904d3 100644
--- a/include/drm/drm_privacy_screen_machine.h
+++ b/include/drm/drm_privacy_screen_machine.h
@@ -31,11 +31,16 @@ struct drm_privacy_screen_lookup {
void drm_privacy_screen_lookup_add(struct drm_privacy_screen_lookup *lookup);
void drm_privacy_screen_lookup_remove(struct drm_privacy_screen_lookup
*lookup);
+#if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) && IS_ENABLED(CONFIG_X86)
+void drm_privacy_screen_lookup_init(void);
+void drm_privacy_screen_lookup_exit(void);
+#else
static inline void drm_privacy_screen_lookup_init(void)
{
}
static inline void drm_privacy_screen_lookup_exit(void)
{
}
+#endif
#endif
--
2.31.1
[Intel-gfx] [PATCH 02/10] drm: Add privacy-screen class (v4)
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the driver for these
other devices to register themselves as a privacy-screen provider; and
allowing the drm/kms code to get a privacy-screen provider associated
with a specific GPU/connector combo.
Changes in v2:
- Make CONFIG_DRM_PRIVACY_SCREEN a bool which controls if the drm_privacy
code gets built as part of the main drm module rather then making it
a tristate which builds its own module.
- Add a #if IS_ENABLED(CONFIG_DRM_PRIVACY_SCREEN) check to
drm_privacy_screen_consumer.h and define stubs when the check fails.
Together these 2 changes fix several dependency issues.
- Remove module related code now that this is part of the main drm.ko
- Use drm_class as class for the privacy-screen devices instead of
adding a separate class for this
Changes in v3:
- Make the static inline drm_privacy_screen_get_state() stub set sw_state
and hw_state to PRIVACY_SCREEN_DISABLED to squelch an uninitialized
variable warning when CONFIG_DRM_PRIVICAY_SCREEN is not set
Changes in v4:
- Make drm_privacy_screen_set_sw_state() skip calling out to the hw if
hw_state == new_sw_state
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
Documentation/gpu/drm-kms-helpers.rst | 15 +
MAINTAINERS | 8 +
drivers/gpu/drm/Kconfig | 4 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_drv.c | 4 +
drivers/gpu/drm/drm_privacy_screen.c | 403 ++
include/drm/drm_privacy_screen_consumer.h | 50 +++
include/drm/drm_privacy_screen_driver.h | 80 +
include/drm/drm_privacy_screen_machine.h | 41 +++
9 files changed, 606 insertions(+)
create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
create mode 100644 include/drm/drm_privacy_screen_consumer.h
create mode 100644 include/drm/drm_privacy_screen_driver.h
create mode 100644 include/drm/drm_privacy_screen_machine.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index ec2f65b31930..5bb55ec1b9b5 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -435,3 +435,18 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
+
+Privacy-screen class
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_privacy_screen_driver.h
+ :internal:
+
+.. kernel-doc:: include/drm/drm_privacy_screen_machine.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_privacy_screen.c
+ :export:
diff --git a/MAINTAINERS b/MAINTAINERS
index 28e5f0ae1009..cb94bb3b8724 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6423,6 +6423,14 @@ F: drivers/gpu/drm/drm_panel.c
F: drivers/gpu/drm/panel/
F: include/drm/drm_panel.h
+DRM PRIVACY-SCREEN CLASS
+M: Hans de Goede
+L: dri-de...@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/drm_privacy_screen*
+F: include/drm/drm_privacy_screen*
+
DRM TTM SUBSYSTEM
M: Christian Koenig
M: Huang Rui
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 2a926d0de423..c686c08447ac 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -481,3 +481,7 @@ config DRM_PANEL_ORIENTATION_QUIRKS
config DRM_LIB_RANDOM
bool
default n
+
+config DRM_PRIVACY_SCREEN
+ bool
+ default n
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 0dff40bb863c..788fc37096f6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -32,6 +32,7 @@ drm-$(CONFIG_OF) += drm_of.o
drm-$(CONFIG_PCI) += drm_pci.o
drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_PRIVACY_SCREEN) += drm_privacy_screen.o
obj-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7a5097467ba5..dc293b771c3f 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include "drm_crtc_internal.h"
#include "drm_internal.h"
@@ -1029,6 +1030,7 @@ static const struct file_operations drm_stub_fops = {
static void drm_core_exit(void)
{
+ drm_privacy_screen_lookup_exit();
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
@@ -1056,6 +1058,8 @@ static int __init drm_core_init(void)
if (ret < 0)
goto error;
+ drm_privacy_screen
[Intel-gfx] [PATCH 01/10] drm/connector: Add support for privacy-screen properties (v4)
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
locked out of making state changes
- Write kerneldoc explaining how the 2 properties work together, what
happens when changes to the state are made outside of the DRM code's
control, etc.
Changes in v3 (Hans de Goede)
- Some small tweaks to the kerneldoc describing the 2 properties
Changes in v4 (Hans de Goede)
- Change the "Enabled, locked" and "Disabled, locked" hw-state enum value
names to "Enabled-locked" and "Disabled-locked". The xrandr command shows
all possible enum values separated by commas in its output, so having a
comma in an enum name is not a good idea.
- Do not add a privacy_screen_hw_state member to drm_connector_state
since this property is immutable its value must be directly stored in the
obj->properties->values array
Signed-off-by: Rajat Jain
Acked-by: Pekka Paalanen
Reviewed-by: Mario Limonciello
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Co-developed-by: Hans de Goede
Signed-off-by: Hans de Goede
---
Documentation/gpu/drm-kms.rst | 2 +
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 101 ++
include/drm/drm_connector.h | 44 +
4 files changed, 151 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1ef7951ded5e..d14bf1c35d7e 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -506,6 +506,8 @@ Property Types and Blob Property Support
.. kernel-doc:: drivers/gpu/drm/drm_property.c
:export:
+.. _standard_connector_properties:
+
Standard Connector Properties
-
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 909f31833181..cdd31fc78bfc 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -797,6 +797,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+ } else if (property == connector->privacy_screen_sw_state_property) {
+ state->privacy_screen_sw_state = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -874,6 +876,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == connector->privacy_screen_sw_state_property) {
+ *val = state->privacy_screen_sw_state;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3bc782b630b9..b2f1f1b1bfb4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1264,6 +1264,46 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* For DVI-I and TVout there is also a matching property "select
subconnector"
* allowing to switch between signal types.
* DP subconnector corresponds to a downstream port.
+ *
+ * privacy-screen sw-state, privacy-screen hw-state:
+ * These 2 optional properties can be used to query the state of the
+ * electronic privacy screen that is available on some displays; and in
+ * some cases also control the state. If a driver implements these
+ * properties then both properties must be present.
+ *
+ * "privacy-screen hw-state" is read-only and reflects the actual state
+ * of the privacy-screen, possible values: "Enabled", "Disabled,
+ * "Enabled-locked", "Disabled-locked". The locked states indicate
+ * that the state cannot be changed through the DRM API. E.g. there
+ * might be devices where the firmware-setup options, or a hardware
+ * slider-switch, offer always on / off modes.
+ *
+ * "privacy-screen sw-state" can be set to change the privacy-screen state
+ * when not locked. In this case the driver must update the hw-state
+ * property to reflect the new state on completion of the commit of the
+ * sw-state property. Setting the sw-state property when the hw-state is
+ * locked must be interpreted by the driver as a request to change the
+ * state to the set state when the hw-state becomes unlocked. E.g. if
+ * "privacy-screen hw-state" is
[Intel-gfx] [PATCH 00/10] drm: Add privacy-screen class and connector properties
Hi all, Here is a new version of my privacy-screen series, addressing the review-remark from Ville on patch 10/10 from the version posted on October 2nd. This new version contains the following changes: - drm/i915: Add privacy-screen support (v3) - Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector() Ville, can you (re)review "[PATCH 10/10] drm/i915: Add privacy-screen support (v3)" please ? For anyone just tuning in, here is some more info from the previous cover-letters: The first userspace consumer of the new properties is now fully ready for merging (it is just waiting for the kernel bits to land first): - https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952 - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032 The new API works as designed and add the following features to GNOME: 1. Showing an OSD notification when the privacy-screen is toggled on/off through hotkeys handled by the embedded-controller 2. Allowing control of the privacy-screen from the GNOME control-panel, including the on/off slider shown there updating to match the hw-setting when the setting is changed with the control-panel open. 3. Restoring the last user-setting at login This series consists of a number of different parts: 1. A new version of Rajat's privacy-screen connector properties patch, this adds new userspace API in the form of new properties 2. Since on most devices the privacy screen is actually controlled by some vendor specific ACPI/WMI interface which has a driver under drivers/platform/x86, we need some "glue" code to make this functionality available to KMS drivers. Patches 2-4 add a new privacy-screen class for this, which allows non KMS drivers (and possibly KMS drivers too) to register a privacy-screen device and also adds an interface for KMS drivers to get access to the privacy-screen associated with a specific connector. This is modelled similar to how we deal with e.g. PWMs and GPIOs in the kernel, including separate includes for consumers and providers(drivers). 3. Some drm_connector helper functions to keep the actual changes needed for this in individual KMS drivers as small as possible (patch 5). 4. Make the thinkpad_acpi code register a privacy-screen device on ThinkPads with a privacy-screen (patches 6-8) 5. Make the i915 driver export the privacy-screen functionality through the connector properties on the eDP connector. I believe that it would be best to merge the entire series, including the thinkpad_acpi changes through drm-misc in one go. As the pdx86 subsys maintainer I hereby give my ack for merging the thinkpad_acpi changes through drm-misc. There is one small caveat with this series, which it is good to be aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads with an eprivacy screen, until the thinkpad_acpi driver is loaded. This means that initrd generation tools will need to be updated to include thinkpad_acpi when the i915 driver is added to the initrd. Without this the loading of the i915 driver will be delayed to after the switch to real rootfs. Regards, Hans Hans de Goede (9): drm: Add privacy-screen class (v4) drm/privacy-screen: Add X86 specific arch init code drm/privacy-screen: Add notifier support (v2) drm/connector: Add a drm_connector privacy-screen helper functions (v2) platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once platform/x86: thinkpad_acpi: Register a privacy-screen device drm/i915: Add intel_modeset_probe_defer() helper drm/i915: Add privacy-screen support (v3) Rajat Jain (1): drm/connector: Add support for privacy-screen properties (v4) Documentation/gpu/drm-kms-helpers.rst| 15 + Documentation/gpu/drm-kms.rst| 2 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 4 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_atomic_uapi.c| 4 + drivers/gpu/drm/drm_connector.c | 203 drivers/gpu/drm/drm_drv.c| 4 + drivers/gpu/drm/drm_privacy_screen.c | 467 +++ drivers/gpu/drm/drm_privacy_screen_x86.c | 86 drivers/gpu/drm/i915/display/intel_atomic.c | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 15 + drivers/gpu/drm/i915/display/intel_display.c | 23 + drivers/gpu/drm/i915/display/intel_display.h | 1 + drivers/gpu/drm/i915/i915_pci.c | 9 +- drivers/platform/x86/Kconfig | 2 + drivers/platform/x86/thinkpad_acpi.c | 137 -- include/drm/drm_connector.h | 55 +++ include/drm/drm_privacy_screen_consumer.h| 65 +++ include/drm/drm_privacy_screen_driver.h | 84 include/drm/drm_privacy_screen_
Re: [Intel-gfx] [PATCH] drm/i915/bios: gracefully disable dual eDP for now
On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
> For the time being, neither the power sequencer nor the backlight code
> properly support two eDP panels simultaneously. While the software
> states will be independent, the same sets of registers will be used for
> both eDP panels, clobbering the hardware state and leading to errors.
>
> Gracefully disable dual eDP until proper support has been added.
>
> Cc: José Roberto de Souza
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Swati Sharma
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 47 +++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index f9776ca85de3..b99907c656bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1930,6 +1930,50 @@ static int _intel_bios_max_tmds_clock(const struct
> intel_bios_encoder_data *devd
> }
> }
>
> +static enum port get_edp_port(struct drm_i915_private *i915)
> +{
> + const struct intel_bios_encoder_data *devdata;
> + enum port port;
> +
> + for_each_port(port) {
> + devdata = i915->vbt.ports[port];
> +
> + if (devdata && intel_bios_encoder_supports_edp(devdata))
> + return port;
> + }
> +
> + return PORT_NONE;
> +}
> +
> +/*
> + * FIXME: The power sequencer and backlight code currently do not support
> more
> + * than one set registers, at least not on anything other than VLV/CHV. It
> will
> + * clobber the registers. As a temporary workaround, gracefully prevent more
> + * than one eDP from being registered.
> + */
> +static void sanitize_dual_edp(struct intel_bios_encoder_data *devdata,
> + enum port port)
> +{
> + struct drm_i915_private *i915 = devdata->i915;
> + struct child_device_config *child = &devdata->child;
> + enum port p;
> +
> + /* CHV might not clobber PPS registers. */
> + if (IS_CHERRYVIEW(i915))
> + return;
> +
> + p = get_edp_port(i915);
> + if (p == PORT_NONE)
> + return;
> +
> + drm_dbg_kms(&i915->drm, "both ports %c and %c configured as eDP, "
> + "disabling port %c eDP\n", port_name(p), port_name(port),
> + port_name(port));
> +
> + child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;
Why also cleaning the DEVICE_TYPE_DISPLAYPORT_OUTPUT bit? The rest lgtm.
> + child->device_type &= ~DEVICE_TYPE_INTERNAL_CONNECTOR;
> +}
> +
> static bool is_port_valid(struct drm_i915_private *i915, enum port port)
> {
> /*
> @@ -1987,6 +2031,9 @@ static void parse_ddi_port(struct drm_i915_private
> *i915,
> supports_typec_usb, supports_tbt,
> devdata->dsc != NULL);
>
> + if (is_edp)
> + sanitize_dual_edp(devdata, port);
> +
> if (is_dvi)
> sanitize_ddc_pin(devdata, port);
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove IS_ACTIVE (rev3)
== Series Details == Series: drm/i915: remove IS_ACTIVE (rev3) URL : https://patchwork.freedesktop.org/series/95312/ State : success == Summary == CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21253 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/index.html Known issues Here are the changes found in Patchwork_21253 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-x1275: NOTRUN -> [SKIP][2] ([fdo#109271]) +28 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@amdgpu/amd_prime@i915-to-amd: - fi-snb-2520m: NOTRUN -> [SKIP][3] ([fdo#109271]) +37 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html - fi-kbl-x1275: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@hangcheck: - fi-ivb-3770:[PASS][6] -> [INCOMPLETE][7] ([i915#3303]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-hpd-fast: - fi-tgl-u2: NOTRUN -> [SKIP][8] ([fdo#109284] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-x1275: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-snb-2520m: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-u2: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-u2: NOTRUN -> [SKIP][12] ([fdo#109285]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-x1275: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-userptr: - fi-tgl-u2: NOTRUN -> [SKIP][14] ([i915#3301]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-tgl-u2/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-ivb-3770:NOTRUN -> [FAIL][15] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-ivb-3770/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][16] ([i915#2940]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [FAIL][18] ([i915#4165]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_flip@basic-plain-flip@c-dp2: - fi-cfl-8109u: [DMESG-WARN][20] ([i915#295]) -> [PASS][21] +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@kms_flip@basic-plain-f...@c-dp2.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21253/fi-cfl-8
Re: [Intel-gfx] [PATCH] drm/i915/bios: gracefully disable dual eDP for now
On Tue, 05 Oct 2021, Ville Syrjälä wrote:
> On Tue, Oct 05, 2021 at 08:56:36PM +0300, Jani Nikula wrote:
>> For the time being, neither the power sequencer nor the backlight code
>> properly support two eDP panels simultaneously. While the software
>> states will be independent, the same sets of registers will be used for
>> both eDP panels, clobbering the hardware state and leading to errors.
>>
>> Gracefully disable dual eDP until proper support has been added.
>>
>> Cc: José Roberto de Souza
>> Cc: Uma Shankar
>> Cc: Ville Syrjälä
>> Cc: Swati Sharma
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_bios.c | 47 +++
>> 1 file changed, 47 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index f9776ca85de3..b99907c656bb 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -1930,6 +1930,50 @@ static int _intel_bios_max_tmds_clock(const struct
>> intel_bios_encoder_data *devd
>> }
>> }
>>
>> +static enum port get_edp_port(struct drm_i915_private *i915)
>> +{
>> +const struct intel_bios_encoder_data *devdata;
>> +enum port port;
>> +
>> +for_each_port(port) {
>> +devdata = i915->vbt.ports[port];
>> +
>> +if (devdata && intel_bios_encoder_supports_edp(devdata))
>> +return port;
>> +}
>> +
>> +return PORT_NONE;
>> +}
>> +
>> +/*
>> + * FIXME: The power sequencer and backlight code currently do not support
>> more
>> + * than one set registers, at least not on anything other than VLV/CHV. It
>> will
>> + * clobber the registers. As a temporary workaround, gracefully prevent more
>> + * than one eDP from being registered.
>> + */
>> +static void sanitize_dual_edp(struct intel_bios_encoder_data *devdata,
>> + enum port port)
>> +{
>> +struct drm_i915_private *i915 = devdata->i915;
>> +struct child_device_config *child = &devdata->child;
>> +enum port p;
>> +
>> +/* CHV might not clobber PPS registers. */
>> +if (IS_CHERRYVIEW(i915))
>
> vlv and chv should both behave identically. At least I don't remember
> any single eDP assumptions in the code for either.
This bit of code is not run on VLV, only CHV and DDI. It's subtle.
> Hmm. Quick glance suggest bxt/glk should handle this correctly
> as well? But the more recent platforms are certainly borked.
> Well, that's assuming the vbt related bits are correct for bxt/glk.
VLV/CHV figure out the PPS in a complicated manner, and use pipe
specific backlight. They might work.
BXT/GLK look at VBT for the pps/backlight index, but that's just the
*one* number. All the structures are set up nicely, but then they use
the same set of registers for all panels.
The recent failure mode was a really weird looking VDD warn, and it just
turned out to be two intel_pps instances using the same registers and
getting royally confused about the sw/hw states.
We'd need to figure out the per-panel pps/backlight to use from VBT, for
each panel, and then set that up.
BR,
Jani.
>
>> +return;
>> +
>> +p = get_edp_port(i915);
>> +if (p == PORT_NONE)
>> +return;
>> +
>> +drm_dbg_kms(&i915->drm, "both ports %c and %c configured as eDP, "
>> +"disabling port %c eDP\n", port_name(p), port_name(port),
>> +port_name(port));
>> +
>> +child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;
>> +child->device_type &= ~DEVICE_TYPE_INTERNAL_CONNECTOR;
>> +}
>> +
>> static bool is_port_valid(struct drm_i915_private *i915, enum port port)
>> {
>> /*
>> @@ -1987,6 +2031,9 @@ static void parse_ddi_port(struct drm_i915_private
>> *i915,
>> supports_typec_usb, supports_tbt,
>> devdata->dsc != NULL);
>>
>> +if (is_edp)
>> +sanitize_dual_edp(devdata, port);
>> +
>> if (is_dvi)
>> sanitize_ddc_pin(devdata, port);
>>
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy()
On Mon, Oct 04, 2021 at 01:37:37PM +0300, Dan Carpenter wrote: > The "digi_port" pointer can't be NULL and we have already dereferenced > it so checking for NULL is not necessary. Delete the check. > > Signed-off-by: Dan Carpenter Thanks. Applied to drm-intel-next. > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index 51d07e9af9f3..b9c6eb13804f 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -4025,8 +4025,7 @@ static void intel_ddi_encoder_destroy(struct > drm_encoder *encoder) > intel_display_power_flush_work(i915); > > drm_encoder_cleanup(encoder); > - if (dig_port) > - kfree(dig_port->hdcp_port_data.streams); > + kfree(dig_port->hdcp_port_data.streams); > kfree(dig_port); > } > > -- > 2.20.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().
On Tue, Oct 05, 2021 at 05:00:46PM +0200, Sebastian Andrzej Siewior wrote:
> This is a revert of commits
>d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
> irqsafe")
>6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
> timeline->mutex")
>
> The existing code leads to a different behaviour depending on wheather
> lockdep is enabled or not. Any following lock that is acquired without
> disabling interrupts (but needs to) will not be noticed by lockdep.
>
> This it not just a lockdep annotation but is used but an actual mutex_t
> that is properly used as a lock but in case of __timeline_mark_lock()
> lockdep is only told that it is acquired but no lock has been acquired.
>
> It appears that its purporse is just satisfy the lockdep_assert_held()
> check in intel_context_mark_active(). The other problem with disabling
> interrupts is that on PREEMPT_RT interrupts are also disabled which
> leads to problems for instance later during memory allocation.
>
> Add an argument to intel_context_mark_active() which is true if the lock
> must have been acquired, false if other magic is involved and the lock
> is not needed. Use the `false' argument only from within
> switch_to_kernel_context() and remove __timeline_mark_lock().
>
> Cc: Peter Zijlstra
> Signed-off-by: Sebastian Andrzej Siewior
Eeew, nice find.
> -static inline void intel_context_mark_active(struct intel_context *ce)
> +static inline void intel_context_mark_active(struct intel_context *ce,
> + bool timeline_mutex_needed)
> {
> - lockdep_assert_held(&ce->timeline->mutex);
> + if (timeline_mutex_needed)
> + lockdep_assert_held(&ce->timeline->mutex);
> ++ce->active_count;
> }
Chris, might it be possible to write that something like:
lockdep_assert(lockdep_is_held(&ce->timeline->mutex) ||
engine_is_parked(ce));
instead?
Otherwise,
Acked-by: Peter Zijlstra (Intel)
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915/adlp: Keep hardware default dbox B credits (rev2)
== Series Details == Series: series starting with [1/1] drm/i915/adlp: Keep hardware default dbox B credits (rev2) URL : https://patchwork.freedesktop.org/series/94702/ State : success == Summary == CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21252 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/index.html Known issues Here are the changes found in Patchwork_21252 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@memory-alloc: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-kbl-soraka/igt@amdgpu/amd_ba...@memory-alloc.html * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-x1275: NOTRUN -> [SKIP][3] ([fdo#109271]) +28 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@amdgpu/amd_prime@i915-to-amd: - fi-snb-2520m: NOTRUN -> [SKIP][4] ([fdo#109271]) +37 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: NOTRUN -> [FAIL][5] ([i915#1888]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html - fi-kbl-x1275: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][8] -> [INCOMPLETE][9] ([i915#2940]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][10] -> [FAIL][11] ([i915#1372]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@dp-hpd-fast: - fi-tgl-u2: NOTRUN -> [SKIP][12] ([fdo#109284] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-x1275: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-snb-2520m: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-u2: NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-u2: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-x1275: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-userptr: - fi-tgl-u2: NOTRUN -> [SKIP][18] ([i915#3301]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-tgl-u2/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-bsw-n3050: NOTRUN -> [FAIL][19] ([fdo#109271] / [i915#1436] / [i915#3428]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21252/fi-bsw-n3050/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][20] ([i915#2940]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bsw-kefka/igt@i915_selfte
Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
Thanks for explanation. This patch is Acked-by: Oak Zeng Regards, Oak > -Original Message- > From: Auld, Matthew > Sent: October 5, 2021 1:07 PM > To: Zeng, Oak ; Thomas Hellström > ; intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org; Christian König > > Subject: Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem > backend > > On 05/10/2021 15:23, Zeng, Oak wrote: > > > > > > Regards, > > Oak > > > >> -Original Message- > >> From: Thomas Hellström > >> Sent: October 5, 2021 9:48 AM > >> To: Zeng, Oak ; Auld, Matthew > >> ; intel-gfx@lists.freedesktop.org > >> Cc: dri-de...@lists.freedesktop.org; Christian König > >> > >> Subject: Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem > >> backend > >> > >> > >> On 10/5/21 04:05, Zeng, Oak wrote: > >>> Hi Matthew/Thomas, > >>> > >>> See one question inline > >>> > >>> Regards, > >>> Oak > >>> > >>> -Original Message- > >>> From: Intel-gfx On Behalf Of > >> Matthew Auld > >>> Sent: September 27, 2021 7:41 AM > >>> To: intel-gfx@lists.freedesktop.org > >>> Cc: dri-de...@lists.freedesktop.org; Thomas Hellström > >> ; Christian König > >> > >>> Subject: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem > backend > >>> > >>> For cached objects we can allocate our pages directly in shmem. This > should > >> make it possible(in a later patch) to utilise the existing i915-gem > >> shrinker > code > >> for such objects. For now this is still disabled. > >>> > >>> v2(Thomas): > >>> - Add optional try_to_writeback hook for objects. Importantly we need > >>> to check if the object is even still shrinkable; in between us > >>> dropping the shrinker LRU lock and acquiring the object lock it > >>> could for > >>> example have been moved. Also we need to differentiate between > >>> "lazy" shrinking and the immediate writeback mode. Also later we > need > >> to > >>> handle objects which don't even have mm.pages, so bundling this into > >>> put_pages() would require somehow handling that edge case, hence > >>> just letting the ttm backend handle everything in try_to_writeback > >>> doesn't seem too bad. > >>> v3(Thomas): > >>> - Likely a bad idea to touch the object from the unpopulate hook, > >>> since it's not possible to hold a reference, without also creating > >>> circular dependency, so likely this is too fragile. For now just > >>> ensure we at least mark the pages as dirty/accessed when called from > the > >>> shrinker on WILLNEED objects. > >>> - s/try_to_writeback/shrinker_release_pages, since this can do more > >>> than just writeback. > >>> - Get rid of do_backup boolean and just set the SWAPPED flag prior to > >>> calling unpopulate. > >>> - Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, > >> since > >>> these just get skipped anyway. We can try to come up with something > >>> better later. > >>> > >>> Signed-off-by: Matthew Auld > >>> Cc: Thomas Hellström > >>> Cc: Christian König > >>> --- > >>>drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 + > >>>.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 + > >>>drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 17 +- > >>>drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 240 > - > >> - > >>>5 files changed, 245 insertions(+), 36 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h > >> b/drivers/gpu/drm/i915/gem/i915_gem_object.h > >>> index 3043fcbd31bd..1c9a1d8d3434 100644 > >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h > >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h > >>> @@ -601,6 +601,14 @@ int i915_gem_object_wait_migration(struct > >> drm_i915_gem_object *obj, bool > >> i915_gem_object_placement_possible(struct drm_i915_gem_object *obj, > >>> enum intel_memory_type type); > >>> > >>> +struct sg_table *shmem_alloc_st(struct drm_i915_private *i915, > >>> + size_t size, struct intel_memory_region *mr, > >>> + struct address_space *mapping, > >>> + unsigned int max_segment); > >>> +void shmem_free_st(struct sg_table *st, struct address_space > *mapping, > >>> + bool dirty, bool backup); > >>> +void __shmem_writeback(size_t size, struct address_space *mapping); > >>> + > >>>#ifdef CONFIG_MMU_NOTIFIER > >>>static inline bool > >>>i915_gem_object_is_userptr(struct drm_i915_gem_object *obj) diff -- > git > >> a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > >> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > >>> index fa2ba9e2a4d0..f0fb17be2f7a 100644 > >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h > >>> @@ -56,6 +56,8 @@ struct drm_i915_gem_objec
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Improve DP link training further (rev5)
== Series Details == Series: drm/i915: Improve DP link training further (rev5) URL : https://patchwork.freedesktop.org/series/95405/ State : success == Summary == CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21250_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21250_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-apl8/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-snb7/igt@gem_ctx_persiste...@process.html * igt@gem_ctx_sseu@invalid-args: - shard-tglb: NOTRUN -> [SKIP][3] ([i915#280]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-tglb3/igt@gem_ctx_s...@invalid-args.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][4] ([i915#2846]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-skl2/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][5] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-apl2/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: [PASS][6] -> [FAIL][7] ([i915#2842] / [i915#3468]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-apl3/igt@gem_exec_fair@basic-n...@vecs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2849]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk8/igt@gem_exec_whis...@basic-fds-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-glk7/igt@gem_exec_whis...@basic-fds-all.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-apl1/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271]) +229 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-apl3/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-apl2/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-skl2/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][19] ([i915#3002]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-snb5/igt@gem_userptr_bl...@input-checking.html * igt@gen9_exec_parse@batch-invalid-length: - shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271]) +319 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-snb7/igt@gen9_exec_pa...@batch-invalid-length.html * igt@i915_pm_backlight@fade_with_suspend: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#456]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-tglb5/igt@i915_pm_backlight@fade_with_suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/shard-tglb7/igt@i915_pm_backlight@fade_with_suspend.html * igt@i915_pm_dc@dc6-dpms: - shard-kbl:
[Intel-gfx] [PATCH v6 6/8] drm/i915/ttm: move shrinker management into adjust_lru
We currently just evict lmem objects to system memory when under memory
pressure. For this case we might lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets migrated back to lmem when touched again.
For all cases we can just adjust the i915 shrinker LRU each time we also
adjust the TTM LRU. The two cases we care about are:
1) When something is moved by TTM, including when initially populating
an object. Importantly this covers the case where TTM moves something from
lmem <-> smem, outside of the normal get_pages() interface, which
should still ensure the shmem pages underneath are reclaimable.
2) When calling into i915_gem_object_unlock(). The unlock should
ensure the object is removed from the shinker LRU, if it was indeed
swapped out, or just purged, when the shrinker drops the object lock.
v2(Thomas):
- Handle managing the shrinker LRU in adjust_lru, where it is always
safe to touch the object.
v3(Thomas):
- Pretty much a re-write. This time piggy back off the shrink_pin
stuff, which actually seems to fit quite well for what we want here.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 25 ++-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 5 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 45 +++--
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 65 +--
5 files changed, 130 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index e641db297e0e..3eac8cf2ae10 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -294,6 +294,12 @@ i915_gem_object_is_shrinkable(const struct
drm_i915_gem_object *obj)
return i915_gem_object_type_has(obj, I915_GEM_OBJECT_IS_SHRINKABLE);
}
+static inline bool
+i915_gem_object_has_self_managed_shrink_list(const struct drm_i915_gem_object
*obj)
+{
+ return i915_gem_object_type_has(obj,
I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST);
+}
+
static inline bool
i915_gem_object_is_proxy(const struct drm_i915_gem_object *obj)
{
@@ -531,6 +537,8 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object *obj);
void i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj);
+void __i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj);
+void __i915_gem_object_make_purgeable(struct drm_i915_gem_object *obj);
void i915_gem_object_make_purgeable(struct drm_i915_gem_object *obj);
static inline bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index f4233c4e8d2e..9dbbca682a77 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -34,9 +34,11 @@ struct i915_lut_handle {
struct drm_i915_gem_object_ops {
unsigned int flags;
-#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
-#define I915_GEM_OBJECT_IS_PROXY BIT(2)
-#define I915_GEM_OBJECT_NO_MMAPBIT(3)
+#define I915_GEM_OBJECT_IS_SHRINKABLE BIT(1)
+/* Skip the shrinker management in set_pages/unset_pages */
+#define I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST BIT(2)
+#define I915_GEM_OBJECT_IS_PROXY BIT(3)
+#define I915_GEM_OBJECT_NO_MMAPBIT(4)
/* Interface between the GEM object and its backing storage.
* get_pages() is called once prior to the use of the associated set
@@ -485,6 +487,23 @@ struct drm_i915_gem_object {
*/
atomic_t shrink_pin;
+ /**
+* @ttm_shrinker_status: Whether TTM is currently holding a
+* shrink_pin for this object. Protected by the object lock.
+*
+* I915_TTM_SHRINKER_UNPINNED: We don't have an extra shrink_pin
+* for this object. The underlying pages or ttm_tt is using
+* shmem pages underneath, and as such this object might be
+* currently visible to the shrinker.
+*
+* I915_TTM_SHRINKER_PINNED: We are holding shrink_pin for this
+* object, which prevents the shrinker from seeing this object.
+* The object is not currently using shmem pages undearneath.
+*/
+#define I915_TTM_SHRINKER_UNPINNED 1
+#define I915_TTM_SHRINKER_PINNED 2
+ int ttm_shrinker_status;
+
/**
* Priority list of potential placements for this object.
*/
diff --gi
[Intel-gfx] [PATCH v6 3/8] drm/i915/gtt: drop unneeded make_unshrinkable
We already do this when mapping the pages. Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 - drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c index 890191f286e3..baea9770200a 100644 --- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c +++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c @@ -185,7 +185,6 @@ static void gen6_alloc_va_range(struct i915_address_space *vm, pt = stash->pt[0]; __i915_gem_object_pin_pages(pt->base); - i915_gem_object_make_unshrinkable(pt->base); fill32_px(pt, vm->scratch[0]->encode); diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c index 037a9a6e4889..8af2f709571c 100644 --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c @@ -301,7 +301,6 @@ static void __gen8_ppgtt_alloc(struct i915_address_space * const vm, pt = stash->pt[!!lvl]; __i915_gem_object_pin_pages(pt->base); - i915_gem_object_make_unshrinkable(pt->base); fill_px(pt, vm->scratch[lvl]->encode); -- 2.26.3
[Intel-gfx] [PATCH v6 5/8] drm/i915: add some kernel-doc for shrink_pin and friends
Attempt to document shrink_pin and the other relevant interfaces that
interact with it, before we start messing with it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 24 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 31 +++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7dd5f804aab3..f4233c4e8d2e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -461,6 +461,28 @@ struct drm_i915_gem_object {
* instead go through the pin/unpin interfaces.
*/
atomic_t pages_pin_count;
+
+ /**
+* @shrink_pin: Prevents the pages from being made visible to
+* the shrinker, while the shrink_pin is non-zero. Most users
+* should pretty much never have to care about this, outside of
+* some special use cases.
+*
+* By default most objects will start out as visible to the
+* shrinker(if I915_GEM_OBJECT_IS_SHRINKABLE) as soon as the
+* backing pages are attached to the object, like in
+* __i915_gem_object_set_pages(). They will then be removed the
+* shrinker list once the pages are released.
+*
+* The @shrink_pin is incremented by calling
+* i915_gem_object_make_unshrinkable(), which will also remove
+* the object from the shrinker list, if the pin count was zero.
+*
+* Callers will then typically call
+* i915_gem_object_make_shrinkable() or
+* i915_gem_object_make_purgeable() to decrement the pin count,
+* and make the pages visible again.
+*/
atomic_t shrink_pin;
/**
@@ -522,7 +544,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_dma_page;
/**
-* Element within i915->mm.unbound_list or i915->mm.bound_list,
+* Element within i915->mm.shrink_list or i915->mm.purge_list,
* locked by i915->mm.obj_lock.
*/
struct list_head link;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index ae2a8d54b7a4..66121fedc655 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -463,6 +463,16 @@ void i915_gem_shrinker_taints_mutex(struct
drm_i915_private *i915,
#define obj_to_i915(obj__) to_i915((obj__)->base.dev)
+/**
+ * i915_gem_object_make_unshrinkable - Hide the object from the shrinker. By
+ * default all object types that support shrinking(see IS_SHRINKABLE), will
also
+ * make the object visible to the shrinker after allocating the system memory
+ * pages.
+ * @obj: The GEM object.
+ *
+ * This is typically used for special kernel internal objects that can't be
+ * easily processed by the shrinker, like if they are perma-pinned.
+ */
void i915_gem_object_make_unshrinkable(struct drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = obj_to_i915(obj);
@@ -513,12 +523,33 @@ static void __i915_gem_object_make_shrinkable(struct
drm_i915_gem_object *obj,
spin_unlock_irqrestore(&i915->mm.obj_lock, flags);
}
+/**
+ * i915_gem_object_make_shrinkable - Move the object to the tail of the
+ * shrinkable list. Objects on this list might be swapped out. Used with
+ * WILLNEED objects.
+ * @obj: The GEM object.
+ *
+ * MUST only be called on objects which have backing pages.
+ *
+ * MUST be balanced with previous call to i915_gem_object_make_unshrinkable().
+ */
void i915_gem_object_make_shrinkable(struct drm_i915_gem_object *obj)
{
__i915_gem_object_make_shrinkable(obj,
&obj_to_i915(obj)->mm.shrink_list);
}
+/**
+ * i915_gem_object_make_purgeable - Move the object to the tail of the
purgeable
+ * list. Used with DONTNEED objects. Unlike with shrinkable objects, the
+ * shrinker will attempt to discard the backing pages, instead of trying to
swap
+ * them out.
+ * @obj: The GEM object.
+ *
+ * MUST only be called on objects which have backing pages.
+ *
+ * MUST be balanced with previous call to i915_gem_object_make_unshrinkable().
+ */
void i915_gem_object_make_purgeable(struct drm_i915_gem_object *obj)
{
__i915_gem_object_make_shrinkable(obj,
--
2.26.3
[Intel-gfx] [PATCH v6 8/8] drm/i915/ttm: enable shmem tt backend
Turn on the shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 48069b5a664e..66caee29a884 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1097,7 +1097,8 @@ static u64 i915_ttm_mmap_offset(struct
drm_i915_gem_object *obj)
static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
.name = "i915_gem_object_ttm",
- .flags = I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
+ .flags = I915_GEM_OBJECT_IS_SHRINKABLE |
+I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
.get_pages = i915_ttm_get_pages,
.put_pages = i915_ttm_put_pages,
--
2.26.3
[Intel-gfx] [PATCH v6 7/8] drm/i915/ttm: use cached system pages when evicting lmem
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 98b7ead1a008..48069b5a664e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -134,11 +134,11 @@ static enum ttm_caching
i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
{
/*
-* Objects only allowed in system get cached cpu-mappings.
-* Other objects get WC mapping for now. Even if in system.
+* Objects only allowed in system get cached cpu-mappings, or when
+* evicting lmem-only buffers to system for swapping. Other objects get
+* WC mapping for now. Even if in system.
*/
- if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
- obj->mm.n_placements <= 1)
+ if (obj->mm.n_placements <= 1)
return ttm_cached;
return ttm_write_combined;
--
2.26.3
[Intel-gfx] [PATCH v6 1/8] drm/i915/gem: Break out some shmem backend utils
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute the page sizes using
the dma segments rather than using the physical page address segments.
v2(Reported-by: kernel test robot )
- Make sure we initialise the mapping on the error path in
shmem_get_pages()
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 181 +-
1 file changed, 106 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 11f072193f3b..36b711ae9e28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -25,46 +25,61 @@ static void check_release_pagevec(struct pagevec *pvec)
cond_resched();
}
-static int shmem_get_pages(struct drm_i915_gem_object *obj)
+static void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup)
{
- struct drm_i915_private *i915 = to_i915(obj->base.dev);
- struct intel_memory_region *mem = obj->mm.region;
- const unsigned long page_count = obj->base.size / PAGE_SIZE;
+ struct sgt_iter sgt_iter;
+ struct pagevec pvec;
+ struct page *page;
+
+ mapping_clear_unevictable(mapping);
+
+ pagevec_init(&pvec);
+ for_each_sgt_page(page, sgt_iter, st) {
+ if (dirty)
+ set_page_dirty(page);
+
+ if (backup)
+ mark_page_accessed(page);
+
+ if (!pagevec_add(&pvec, page))
+ check_release_pagevec(&pvec);
+ }
+ if (pagevec_count(&pvec))
+ check_release_pagevec(&pvec);
+
+ sg_free_table(st);
+ kfree(st);
+}
+
+static struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region
*mr,
+ struct address_space *mapping,
+ unsigned int max_segment)
+{
+ const unsigned long page_count = size / PAGE_SIZE;
unsigned long i;
- struct address_space *mapping;
struct sg_table *st;
struct scatterlist *sg;
- struct sgt_iter sgt_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
- unsigned int max_segment = i915_sg_segment_size();
- unsigned int sg_page_sizes;
gfp_t noreclaim;
int ret;
- /*
-* Assert that the object is not currently in any GPU domain. As it
-* wasn't in the GTT, there shouldn't be any way it could have been in
-* a GPU cache
-*/
- GEM_BUG_ON(obj->read_domains & I915_GEM_GPU_DOMAINS);
- GEM_BUG_ON(obj->write_domain & I915_GEM_GPU_DOMAINS);
-
/*
* If there's no chance of allocating enough pages for the whole
* object, bail early.
*/
- if (obj->base.size > resource_size(&mem->region))
- return -ENOMEM;
+ if (size > resource_size(&mr->region))
+ return ERR_PTR(-ENOMEM);
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
-rebuild_st:
if (sg_alloc_table(st, page_count, GFP_KERNEL)) {
kfree(st);
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
}
/*
@@ -73,14 +88,12 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
*
* Fail silently without starting the shrinker
*/
- mapping = obj->base.filp->f_mapping;
mapping_set_unevictable(mapping);
noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM);
noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
sg = st->sgl;
st->nents = 0;
- sg_page_sizes = 0;
for (i = 0; i < page_count; i++) {
const unsigned int shrink[] = {
I915_SHRINK_BOUND | I915_SHRINK_UNBOUND,
@@ -135,10 +148,9 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
if (!i ||
sg->length >= max_segment ||
page_to_pfn(page) != last_pfn + 1) {
- if (i) {
- sg_page_sizes |= sg->length;
+ if (i)
sg = sg_next(sg);
- }
+
st->nents++;
sg_set_page(sg, page, PAGE_SIZE, 0);
} else {
@@ -149,14 +161,65 @@ static int shmem_get_pages(struct drm_i915_gem_object
*
[Intel-gfx] [PATCH v6 2/8] drm/i915/ttm: add tt shmem backend
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to check if the object is even still shrinkable; in between us
dropping the shrinker LRU lock and acquiring the object lock it could for
example have been moved. Also we need to differentiate between
"lazy" shrinking and the immediate writeback mode. Also later we need to
handle objects which don't even have mm.pages, so bundling this into
put_pages() would require somehow handling that edge case, hence
just letting the ttm backend handle everything in try_to_writeback
doesn't seem too bad.
v3(Thomas):
- Likely a bad idea to touch the object from the unpopulate hook,
since it's not possible to hold a reference, without also creating
circular dependency, so likely this is too fragile. For now just
ensure we at least mark the pages as dirty/accessed when called from the
shrinker on WILLNEED objects.
- s/try_to_writeback/shrinker_release_pages, since this can do more
than just writeback.
- Get rid of do_backup boolean and just set the SWAPPED flag prior to
calling unpopulate.
- Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, since
these just get skipped anyway. We can try to come up with something
better later.
v4(Thomas):
- s/PCI_DMA/DMA/. Also drop NO_KERNEL_MAPPING and NO_WARN, which
apparently doesn't do anything with streaming mappings.
- Just pass along the error for ->truncate, and assume nothing.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
Cc: Oak Zeng
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 11 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 18 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 17 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 233 --
6 files changed, 247 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 9df3ee60604e..e641db297e0e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -93,7 +93,6 @@ void i915_gem_flush_free_objects(struct drm_i915_private
*i915);
struct sg_table *
__i915_gem_object_unset_pages(struct drm_i915_gem_object *obj);
-void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
/**
* i915_gem_object_lookup_rcu - look up a temporary GEM object from its handle
@@ -449,7 +448,7 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
}
int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
-void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
+int i915_gem_object_truncate(struct drm_i915_gem_object *obj);
void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
/**
@@ -612,6 +611,14 @@ int i915_gem_object_wait_migration(struct
drm_i915_gem_object *obj,
bool i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
enum intel_memory_type type);
+struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region *mr,
+ struct address_space *mapping,
+ unsigned int max_segment);
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup);
+void __shmem_writeback(size_t size, struct address_space *mapping);
+
#ifdef CONFIG_MMU_NOTIFIER
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7c3da4e3e737..7dd5f804aab3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -54,8 +54,10 @@ struct drm_i915_gem_object_ops {
int (*get_pages)(struct drm_i915_gem_object *obj);
void (*put_pages)(struct drm_i915_gem_object *obj,
struct sg_table *pages);
- void (*truncate)(struct drm_i915_gem_object *obj);
+ int (*truncate)(struct drm_i915_gem_object *obj);
void (*writeback)(struct drm_i915_gem_object *obj);
+ int (*shrinker_release_pages)(struct drm_i915_gem_object *obj,
+ bool should_writeback);
int (*pread)(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_pread *arg);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8eb1c3a6fc9c..ea6d9b3d2d6b
[Intel-gfx] [PATCH v6 4/8] drm/i915: drop unneeded make_unshrinkable in free_object
The comment here is no longer accurate, since the current shrinker code requires a full ref before touching any objects. Also unset_pages() should already do the required make_unshrinkable() for us, if needed, which is also nicely balanced with set_pages(). Signed-off-by: Matthew Auld Cc: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 76ce6a1500bc..1dc3c1940c32 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -337,15 +337,6 @@ static void i915_gem_free_object(struct drm_gem_object *gem_obj) */ atomic_inc(&i915->mm.free_count); - /* -* This serializes freeing with the shrinker. Since the free -* is delayed, first by RCU then by the workqueue, we want the -* shrinker to be able to free pages of unreferenced objects, -* or else we may oom whilst there are plenty of deferred -* freed objects. -*/ - i915_gem_object_make_unshrinkable(obj); - /* * Since we require blocking on struct_mutex to unbind the freed * object from the GPU before releasing resources back to the -- 2.26.3
Re: [Intel-gfx] [PATCH] drm/i915/bios: gracefully disable dual eDP for now
On Tue, Oct 05, 2021 at 08:56:36PM +0300, Jani Nikula wrote:
> For the time being, neither the power sequencer nor the backlight code
> properly support two eDP panels simultaneously. While the software
> states will be independent, the same sets of registers will be used for
> both eDP panels, clobbering the hardware state and leading to errors.
>
> Gracefully disable dual eDP until proper support has been added.
>
> Cc: José Roberto de Souza
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Cc: Swati Sharma
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 47 +++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index f9776ca85de3..b99907c656bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1930,6 +1930,50 @@ static int _intel_bios_max_tmds_clock(const struct
> intel_bios_encoder_data *devd
> }
> }
>
> +static enum port get_edp_port(struct drm_i915_private *i915)
> +{
> + const struct intel_bios_encoder_data *devdata;
> + enum port port;
> +
> + for_each_port(port) {
> + devdata = i915->vbt.ports[port];
> +
> + if (devdata && intel_bios_encoder_supports_edp(devdata))
> + return port;
> + }
> +
> + return PORT_NONE;
> +}
> +
> +/*
> + * FIXME: The power sequencer and backlight code currently do not support
> more
> + * than one set registers, at least not on anything other than VLV/CHV. It
> will
> + * clobber the registers. As a temporary workaround, gracefully prevent more
> + * than one eDP from being registered.
> + */
> +static void sanitize_dual_edp(struct intel_bios_encoder_data *devdata,
> + enum port port)
> +{
> + struct drm_i915_private *i915 = devdata->i915;
> + struct child_device_config *child = &devdata->child;
> + enum port p;
> +
> + /* CHV might not clobber PPS registers. */
> + if (IS_CHERRYVIEW(i915))
vlv and chv should both behave identically. At least I don't remember
any single eDP assumptions in the code for either.
Hmm. Quick glance suggest bxt/glk should handle this correctly
as well? But the more recent platforms are certainly borked.
Well, that's assuming the vbt related bits are correct for bxt/glk.
> + return;
> +
> + p = get_edp_port(i915);
> + if (p == PORT_NONE)
> + return;
> +
> + drm_dbg_kms(&i915->drm, "both ports %c and %c configured as eDP, "
> + "disabling port %c eDP\n", port_name(p), port_name(port),
> + port_name(port));
> +
> + child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;
> + child->device_type &= ~DEVICE_TYPE_INTERNAL_CONNECTOR;
> +}
> +
> static bool is_port_valid(struct drm_i915_private *i915, enum port port)
> {
> /*
> @@ -1987,6 +2031,9 @@ static void parse_ddi_port(struct drm_i915_private
> *i915,
> supports_typec_usb, supports_tbt,
> devdata->dsc != NULL);
>
> + if (is_edp)
> + sanitize_dual_edp(devdata, port);
> +
> if (is_dvi)
> sanitize_ddc_pin(devdata, port);
>
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH] drm/i915/pmu: Connect engine busyness stats from GuC to pmu
On Mon, Oct 04, 2021 at 04:21:44PM +0100, Tvrtko Ursulin wrote:
On 24/09/2021 23:34, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using shared memory. For each engine, this
info contains:
- total busyness: total time that the context was running (total)
- id: id of the running context (id)
- start timestamp: timestamp when the context started running (start)
At the time (now) of sampling the engine busyness, if the id is valid
(!= ~0), and start is non-zero, then the context is considered to be
active and the engine busyness is calculated using the below equation
engine busyness = total + (now - start)
All times are obtained from the gt clock base. For inactive contexts,
engine busyness is just equal to the total.
The start and total values provided by GuC are 32 bits and wrap around
in a few minutes. Since perf pmu provides busyness as 64 bit
monotonically increasing values, there is a need for this implementation
to account for overflows and extend the time to 64 bits before returning
busyness to the user. In order to do that, a worker runs periodically at
frequqncy = 1/8th the time it takes for the timestamp to wrap. As an
frequency
example, that would be once in 27 seconds for a gt clock frequency of
19.2 MHz.
Opens and wip that are targeted for later patches:
1) On global gt reset the total busyness of engines resets and i915
needs to fix that so that user sees monotonically increasing
busyness.
2) In runtime suspend mode, the worker may not need to be run. We could
stop the worker on suspend and rerun it on resume provided that the
guc pm timestamp does not tick during suspend.
2) sounds easy since there are park/unpark hooks for pmu already. Will
see if I can figure out why you did not just immediately do it.
I posted a new revision now with all these comments for your review.
For (2), something was throwing a warning when I tried this earlier. I
figured I need to move the initialization of the work and spinlock
elsewhere.
I would also document in the commit message the known problem of
possible over-accounting, just for historical reference.
I added a note. If that's not the issue you are mentioning w.r.t.
engine busyness, let me know.
v2: (Tvrtko)
- Include details in commit message
- Move intel engine busyness function into execlist code
- Use union inside engine->stats
- Use natural type for ping delay jiffies
- Drop active_work condition checks
- Use for_each_engine if iterating all engines
- Drop seq locking, use spinlock at guc level to update engine stats
- Document worker specific details
Signed-off-by: John Harrison
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 26 +--
drivers/gpu/drm/i915/gt/intel_engine_types.h | 82 ---
.../drm/i915/gt/intel_execlists_submission.c | 32 +++
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 26 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 21 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 13 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 204 ++
drivers/gpu/drm/i915/i915_reg.h | 2 +
10 files changed, 363 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ae57e4656a3..6fcc70a313d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1873,22 +1873,6 @@ void intel_engine_dump(struct intel_engine_cs *engine,
intel_engine_print_breadcrumbs(engine, m);
}
-static ktime_t __intel_engine_get_busy_time(struct intel_engine_cs *engine,
- ktime_t *now)
-{
- ktime_t total = engine->stats.total;
-
- /*
-* If the engine is executing something at the moment
-* add it to the total.
-*/
- *now = ktime_get();
- if (READ_ONCE(engine->stats.active))
- total = ktime_add(total, ktime_sub(*now, engine->stats.start));
-
- return total;
-}
-
/**
* intel_engine_get_busy_time() - Return current accumulated engine busyness
* @engine: engine to report on
@@ -1898,15 +1882,7 @@ static ktime_t __intel_engine_get_busy_time(struct
intel_engine_cs *engine,
*/
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine, ktime_t
*now)
{
- unsigned int seq;
- ktime_t total;
-
- do {
- seq = read_seqcount_begin(&engine->stats.lock);
- total = __intel_engine_get_busy_time(engine, now);
- } while (read_seqcount_retry(&engine->stats.lock, seq));
-
- return total;
+ return eng
[Intel-gfx] [PATCH] drm/i915/bios: gracefully disable dual eDP for now
For the time being, neither the power sequencer nor the backlight code
properly support two eDP panels simultaneously. While the software
states will be independent, the same sets of registers will be used for
both eDP panels, clobbering the hardware state and leading to errors.
Gracefully disable dual eDP until proper support has been added.
Cc: José Roberto de Souza
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Swati Sharma
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c | 47 +++
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index f9776ca85de3..b99907c656bb 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1930,6 +1930,50 @@ static int _intel_bios_max_tmds_clock(const struct
intel_bios_encoder_data *devd
}
}
+static enum port get_edp_port(struct drm_i915_private *i915)
+{
+ const struct intel_bios_encoder_data *devdata;
+ enum port port;
+
+ for_each_port(port) {
+ devdata = i915->vbt.ports[port];
+
+ if (devdata && intel_bios_encoder_supports_edp(devdata))
+ return port;
+ }
+
+ return PORT_NONE;
+}
+
+/*
+ * FIXME: The power sequencer and backlight code currently do not support more
+ * than one set registers, at least not on anything other than VLV/CHV. It will
+ * clobber the registers. As a temporary workaround, gracefully prevent more
+ * than one eDP from being registered.
+ */
+static void sanitize_dual_edp(struct intel_bios_encoder_data *devdata,
+ enum port port)
+{
+ struct drm_i915_private *i915 = devdata->i915;
+ struct child_device_config *child = &devdata->child;
+ enum port p;
+
+ /* CHV might not clobber PPS registers. */
+ if (IS_CHERRYVIEW(i915))
+ return;
+
+ p = get_edp_port(i915);
+ if (p == PORT_NONE)
+ return;
+
+ drm_dbg_kms(&i915->drm, "both ports %c and %c configured as eDP, "
+ "disabling port %c eDP\n", port_name(p), port_name(port),
+ port_name(port));
+
+ child->device_type &= ~DEVICE_TYPE_DISPLAYPORT_OUTPUT;
+ child->device_type &= ~DEVICE_TYPE_INTERNAL_CONNECTOR;
+}
+
static bool is_port_valid(struct drm_i915_private *i915, enum port port)
{
/*
@@ -1987,6 +2031,9 @@ static void parse_ddi_port(struct drm_i915_private *i915,
supports_typec_usb, supports_tbt,
devdata->dsc != NULL);
+ if (is_edp)
+ sanitize_dual_edp(devdata, port);
+
if (is_dvi)
sanitize_ddc_pin(devdata, port);
--
2.30.2
[Intel-gfx] [PATCH] drm/i915/pmu: Connect engine busyness stats from GuC to pmu
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using shared memory. For each engine, this
info contains:
- total busyness: total time that the context was running (total)
- id: id of the running context (id)
- start timestamp: timestamp when the context started running (start)
At the time (now) of sampling the engine busyness, if the id is valid
(!= ~0), and start is non-zero, then the context is considered to be
active and the engine busyness is calculated using the below equation
engine busyness = total + (now - start)
All times are obtained from the gt clock base. For inactive contexts,
engine busyness is just equal to the total.
The start and total values provided by GuC are 32 bits and wrap around
in a few minutes. Since perf pmu provides busyness as 64 bit
monotonically increasing values, there is a need for this implementation
to account for overflows and extend the time to 64 bits before returning
busyness to the user. In order to do that, a worker runs periodically at
frequency = 1/8th the time it takes for the timestamp to wrap. As an
example, that would be once in 27 seconds for a gt clock frequency of
19.2 MHz.
Opens and wip that are targeted for later patches:
1) On global gt reset the total busyness of engines resets and i915
needs to fix that so that user sees monotonically increasing
busyness.
2) In runtime suspend mode, the worker may not need to be run. We could
stop the worker on suspend and rerun it on resume provided that the
guc pm timestamp does not tick during suspend.
Note:
There might be an overaccounting of busyness due to the fact that GuC
may be updating the total and start values while kmd is reading them.
(i.e kmd may read the updated total and the stale start). In such a
case, user may see higher busyness value followed by smaller ones which
would eventually catch up to the higher value.
v2: (Tvrtko)
- Include details in commit message
- Move intel engine busyness function into execlist code
- Use union inside engine->stats
- Use natural type for ping delay jiffies
- Drop active_work condition checks
- Use for_each_engine if iterating all engines
- Drop seq locking, use spinlock at guc level to update engine stats
- Document worker specific details
v3: (Tvrtko/Umesh)
- Demarcate guc and execlist stat objects with comments
- Document known over-accounting issue in commit
- Provide a consistent view of guc state
- Add hooks to gt park/unpark for guc busyness
- Stop/start worker in gt park/unpark path
- Drop inline
- Move spinlock and worker inits to guc initialization
- Drop helpers that are called only once
Signed-off-by: John Harrison
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 26 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 90 +--
.../drm/i915/gt/intel_execlists_submission.c | 32 +++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 26 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 21 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h| 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 13 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 227 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 2 +
12 files changed, 398 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ae57e4656a3..6fcc70a313d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1873,22 +1873,6 @@ void intel_engine_dump(struct intel_engine_cs *engine,
intel_engine_print_breadcrumbs(engine, m);
}
-static ktime_t __intel_engine_get_busy_time(struct intel_engine_cs *engine,
- ktime_t *now)
-{
- ktime_t total = engine->stats.total;
-
- /*
-* If the engine is executing something at the moment
-* add it to the total.
-*/
- *now = ktime_get();
- if (READ_ONCE(engine->stats.active))
- total = ktime_add(total, ktime_sub(*now, engine->stats.start));
-
- return total;
-}
-
/**
* intel_engine_get_busy_time() - Return current accumulated engine busyness
* @engine: engine to report on
@@ -1898,15 +1882,7 @@ static ktime_t __intel_engine_get_busy_time(struct
intel_engine_cs *engine,
*/
ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine, ktime_t
*now)
{
- unsigned int seq;
- ktime_t total;
-
- do {
- seq = read_seqcount_begin(&engine->stats.lock);
- total = __intel_engine_get_busy_time(engine, now);
- } while (read_se
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup (rev3)
== Series Details == Series: drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup (rev3) URL : https://patchwork.freedesktop.org/series/94105/ State : success == Summary == CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21248_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_21248_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-apl2/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@hostile: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-snb5/igt@gem_ctx_persiste...@hostile.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_sseu@invalid-args: - shard-tglb: NOTRUN -> [SKIP][5] ([i915#280]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-tglb6/igt@gem_ctx_s...@invalid-args.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-skl8/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-kbl: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-kbl2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271]) +249 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-snb5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_whisper@basic-fds-all: - shard-glk: [PASS][18] -> [DMESG-WARN][19] ([i915#118] / [i915#95]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk8/igt@gem_exec_whis...@basic-fds-all.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-glk4/igt@gem_exec_whis...@basic-fds-all.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-apl3/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3323]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-skl8/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][22] ([i915#3002]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/shard-snb6/igt@gem_userptr_bl...@input-checking.html * igt@gem_workarounds@suspend-resume-context: - shard-tglb: [PASS][23]
[Intel-gfx] [PATCH v3] drm/i915: remove IS_ACTIVE
When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
provide much value just encapsulating it in a boolean context. So I also
added the support for handling undefined macros as the IS_ENABLED()
counterpart. However the feedback received from Masahiro Yamada was that
it is too ugly, not providing much value. And just wrapping in a boolean
context is too dumb - we could simply open code it.
As detailed in commit babaab2f4738 ("drm/i915: Encapsulate kconfig
constant values inside boolean predicates"), the IS_ACTIVE macro was
added to workaround a compilation warning. However after checking again
our current uses of IS_ACTIVE it turned out there is only
1 case in which it triggers a warning in clang (due
-Wconstant-logical-operand) and 2 in smatch. All the others
can simply use the shorter version, without wrapping it in any macro.
So here I'm dialing all the way back to simply removing the macro. That
single case hit by clang can be changed to make the constant come first,
so it doesn't think it's mask:
- if (context && CONFIG_DRM_I915_FENCE_TIMEOUT)
+ if (CONFIG_DRM_I915_FENCE_TIMEOUT && context)
As talked with Dan Carpenter, that logic will be added in smatch as
well, so it will also stop warning about it.
Signed-off-by: Lucas De Marchi
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
.../gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
.../gpu/drm/i915/gt/selftest_engine_heartbeat.c| 4 ++--
drivers/gpu/drm/i915/gt/selftest_execlists.c | 14 +++---
drivers/gpu/drm/i915/i915_config.c | 2 +-
drivers/gpu/drm/i915/i915_request.c| 2 +-
drivers/gpu/drm/i915/i915_utils.h | 13 -
11 files changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 74e33a4cdfe8..d225d3dd0b40 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -804,7 +804,7 @@ static int intel_context_set_gem(struct intel_context *ce,
intel_engine_has_semaphores(ce->engine))
__set_bit(CONTEXT_USE_SEMAPHORES, &ce->flags);
- if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
+ if (CONFIG_DRM_I915_REQUEST_TIMEOUT &&
ctx->i915->params.request_timeout_ms) {
unsigned int timeout_ms = ctx->i915->params.request_timeout_ms;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 5130e8ed9564..65fc6ff5f59d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -395,7 +395,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
/* Track the mmo associated with the fenced vma */
vma->mmo = mmo;
- if (IS_ACTIVE(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND))
+ if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index eed4634c08cd..452248884ef1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -275,7 +275,7 @@ static inline bool intel_engine_uses_guc(const struct
intel_engine_cs *engine)
static inline bool
intel_engine_has_preempt_reset(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT))
+ if (!CONFIG_DRM_I915_PREEMPT_TIMEOUT)
return false;
return intel_engine_has_preemption(engine);
@@ -302,7 +302,7 @@ intel_virtual_engine_has_heartbeat(const struct
intel_engine_cs *engine)
static inline bool
intel_engine_has_heartbeat(const struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+ if (!CONFIG_DRM_I915_HEARTBEAT_INTERVAL)
return false;
if (intel_engine_is_virtual(engine))
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 74775ae961b2..a3698f611f45 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -207,7 +207,7 @@ static void heartbeat(struct work_struct *wrk)
void intel_engine_unpark_heartbeat(struct intel_engine_cs *engine)
{
- if (!IS_ACTIVE(CONFIG_DRM_I915_HEARTBEAT_INTERVAL))
+ if (!CONFIG_DRM_I915_HEARTBEAT_INTERVAL)
return;
next_heartbeat(engine);
diff --git a/drivers/gpu/
Re: [Intel-gfx] [PATCH 21/26] drm/i915: Multi-BB execbuf
On Mon, Oct 04, 2021 at 03:06:32PM -0700, Matthew Brost wrote:
> Allow multiple batch buffers to be submitted in a single execbuf IOCTL
> after a context has been configured with the 'set_parallel' extension.
> The number batches is implicit based on the contexts configuration.
>
> This is implemented with a series of loops. First a loop is used to find
> all the batches, a loop to pin all the HW contexts, a loop to create all
> the requests, a loop to submit (emit BB start, etc...) all the requests,
> a loop to tie the requests to the VMAs they touch, and finally a loop to
> commit the requests to the backend.
>
> A composite fence is also created for the generated requests to return
> to the user and to stick in dma resv slots.
>
> No behavior from the existing IOCTL should be changed aside from when
> throttling because the ring for a context is full, wait on the request
> while holding the object locks.
>
> IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071&rev=1
> media UMD: https://github.com/intel/media-driver/pull/1252
>
> v2:
> (Matthew Brost)
> - Return proper error value if i915_request_create fails
> v3:
> (John Harrison)
> - Add comment explaining create / add order loops + locking
> - Update commit message explaining different in IOCTL behavior
> - Line wrap some comments
> - eb_add_request returns void
> - Return -EINVAL rather triggering BUG_ON if cmd parser used
> (Checkpatch)
> - Check eb->batch_len[*current_batch]
>
> Signed-off-by: Matthew Brost
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 793 --
> drivers/gpu/drm/i915/gt/intel_context.h | 8 +-
> drivers/gpu/drm/i915/gt/intel_context_types.h | 10 +
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +
> drivers/gpu/drm/i915/i915_request.h | 9 +
> drivers/gpu/drm/i915/i915_vma.c | 21 +-
> drivers/gpu/drm/i915/i915_vma.h | 13 +-
> 7 files changed, 599 insertions(+), 257 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 2f2434b52317..5c7fb6f68bbb 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -244,17 +244,25 @@ struct i915_execbuffer {
> struct drm_i915_gem_exec_object2 *exec; /** ioctl execobj[] */
> struct eb_vma *vma;
>
> - struct intel_engine_cs *engine; /** engine to queue the request to */
> + struct intel_gt *gt; /* gt for the execbuf */
> struct intel_context *context; /* logical state for the request */
> struct i915_gem_context *gem_context; /** caller's context */
>
> - struct i915_request *request; /** our request to build */
> - struct eb_vma *batch; /** identity of the batch obj/vma */
> + /** our requests to build */
> + struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
> + /** identity of the batch obj/vma */
> + struct eb_vma *batches[MAX_ENGINE_INSTANCE + 1];
> struct i915_vma *trampoline; /** trampoline used for chaining */
>
> + /** used for excl fence in dma_resv objects when > 1 BB submitted */
> + struct dma_fence *composite_fence;
> +
> /** actual size of execobj[] as we may extend it for the cmdparser */
> unsigned int buffer_count;
>
> + /* number of batches in execbuf IOCTL */
> + unsigned int num_batches;
> +
> /** list of vma not yet bound during reservation phase */
> struct list_head unbound;
>
> @@ -281,7 +289,8 @@ struct i915_execbuffer {
>
> u64 invalid_flags; /** Set of execobj.flags that are invalid */
>
> - u64 batch_len; /** Length of batch within object */
> + /** Length of batch within object */
> + u64 batch_len[MAX_ENGINE_INSTANCE + 1];
> u32 batch_start_offset; /** Location within object of batch */
> u32 batch_flags; /** Flags composed for emit_bb_start() */
> struct intel_gt_buffer_pool_node *batch_pool; /** pool node for batch
> buffer */
> @@ -299,14 +308,13 @@ struct i915_execbuffer {
> };
>
> static int eb_parse(struct i915_execbuffer *eb);
> -static struct i915_request *eb_pin_engine(struct i915_execbuffer *eb,
> - bool throttle);
> +static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle);
> static void eb_unpin_engine(struct i915_execbuffer *eb);
>
> static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
> {
> - return intel_engine_requires_cmd_parser(eb->engine) ||
> - (intel_engine_using_cmd_parser(eb->engine) &&
> + return intel_engine_requires_cmd_parser(eb->context->engine) ||
> + (intel_engine_using_cmd_parser(eb->context->engine) &&
>eb->args->batch_len);
> }
>
> @@ -544,11 +552,21 @@ eb_validate_vma(struct i915_execbuffer *eb,
> return 0;
> }
>
> -static void
> +static inline bool
> +is_batch_buffer(struct i91
Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
On 05/10/2021 15:23, Zeng, Oak wrote:
Regards,
Oak
-Original Message-
From: Thomas Hellström
Sent: October 5, 2021 9:48 AM
To: Zeng, Oak ; Auld, Matthew
; intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Christian König
Subject: Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem
backend
On 10/5/21 04:05, Zeng, Oak wrote:
Hi Matthew/Thomas,
See one question inline
Regards,
Oak
-Original Message-
From: Intel-gfx On Behalf Of
Matthew Auld
Sent: September 27, 2021 7:41 AM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
; Christian König
Subject: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
For cached objects we can allocate our pages directly in shmem. This should
make it possible(in a later patch) to utilise the existing i915-gem shrinker
code
for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to check if the object is even still shrinkable; in between us
dropping the shrinker LRU lock and acquiring the object lock it could for
example have been moved. Also we need to differentiate between
"lazy" shrinking and the immediate writeback mode. Also later we need
to
handle objects which don't even have mm.pages, so bundling this into
put_pages() would require somehow handling that edge case, hence
just letting the ttm backend handle everything in try_to_writeback
doesn't seem too bad.
v3(Thomas):
- Likely a bad idea to touch the object from the unpopulate hook,
since it's not possible to hold a reference, without also creating
circular dependency, so likely this is too fragile. For now just
ensure we at least mark the pages as dirty/accessed when called from the
shrinker on WILLNEED objects.
- s/try_to_writeback/shrinker_release_pages, since this can do more
than just writeback.
- Get rid of do_backup boolean and just set the SWAPPED flag prior to
calling unpopulate.
- Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk,
since
these just get skipped anyway. We can try to come up with something
better later.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 17 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 240 -
-
5 files changed, 245 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3043fcbd31bd..1c9a1d8d3434 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -601,6 +601,14 @@ int i915_gem_object_wait_migration(struct
drm_i915_gem_object *obj, bool
i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
enum intel_memory_type type);
+struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region *mr,
+ struct address_space *mapping,
+ unsigned int max_segment);
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup);
+void __shmem_writeback(size_t size, struct address_space *mapping);
+
#ifdef CONFIG_MMU_NOTIFIER
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj) diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index fa2ba9e2a4d0..f0fb17be2f7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -56,6 +56,8 @@ struct drm_i915_gem_object_ops {
struct sg_table *pages);
void (*truncate)(struct drm_i915_gem_object *obj);
void (*writeback)(struct drm_i915_gem_object *obj);
+ int (*shrinker_release_pages)(struct drm_i915_gem_object *obj,
+ bool should_writeback);
int (*pread)(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_pread *arg); diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 36b711ae9e28..19e55cc29a15 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -25,8 +25,8 @@ static void check_release_pagevec(struct pagevec
*pvec)
cond_resched();
}
-static void shmem_free_st(struct sg_table *st, struct address_space
*mapping,
- bool dirty, bool backup)
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: PREEMPT_RT related fixups.
== Series Details == Series: drm/i915: PREEMPT_RT related fixups. URL : https://patchwork.freedesktop.org/series/95463/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21251 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21251 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21251, 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_21251/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21251: ### IGT changes ### Possible regressions * igt@i915_module_load@reload: - fi-kbl-8809g: [PASS][1] -> [DMESG-WARN][2] +37 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-kbl-8809g/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-kbl-8809g/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][3] -> [DMESG-WARN][4] +35 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@client: - fi-ivb-3770:[PASS][5] -> [DMESG-WARN][6] +34 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-ivb-3770/igt@i915_selftest@l...@client.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-ivb-3770/igt@i915_selftest@l...@client.html - fi-rkl-guc: [PASS][7] -> [DMESG-WARN][8] +35 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-rkl-guc/igt@i915_selftest@l...@client.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-rkl-guc/igt@i915_selftest@l...@client.html * igt@i915_selftest@live@dmabuf: - fi-cfl-8700k: [PASS][9] -> [DMESG-WARN][10] +35 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8700k/igt@i915_selftest@l...@dmabuf.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-cfl-8700k/igt@i915_selftest@l...@dmabuf.html - fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] +35 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-icl-u2/igt@i915_selftest@l...@dmabuf.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-icl-u2/igt@i915_selftest@l...@dmabuf.html * igt@i915_selftest@live@execlists: - fi-bwr-2160:[PASS][13] -> [DMESG-WARN][14] +34 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bwr-2160/igt@i915_selftest@l...@execlists.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-bwr-2160/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem: - fi-snb-2600:[PASS][15] -> [DMESG-WARN][16] +27 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-snb-2600/igt@i915_selftest@l...@gem.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-snb-2600/igt@i915_selftest@l...@gem.html * igt@i915_selftest@live@gt_contexts: - fi-rkl-11600: [PASS][17] -> [DMESG-WARN][18] +36 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-rkl-11600/igt@i915_selftest@live@gt_contexts.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-rkl-11600/igt@i915_selftest@live@gt_contexts.html * igt@i915_selftest@live@gt_heartbeat: - fi-pnv-d510:[PASS][19] -> [DMESG-WARN][20] +34 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-pnv-d510/igt@i915_selftest@live@gt_heartbeat.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-pnv-d510/igt@i915_selftest@live@gt_heartbeat.html - fi-skl-6600u: [PASS][21] -> [DMESG-WARN][22] +36 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html - fi-kbl-x1275: NOTRUN -> [DMESG-WARN][23] +36 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi-kbl-x1275/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_mocs: - fi-tgl-1115g4: [PASS][24] -> [DMESG-WARN][25] +36 similar issues [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21251/fi
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: PREEMPT_RT related fixups.
== Series Details ==
Series: drm/i915: PREEMPT_RT related fixups.
URL : https://patchwork.freedesktop.org/series/95463/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4bae9e7a5800 drm/i915: Use preempt_disable/enable_rt() where recommended
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#7:
ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into kms
driver.")
total: 0 errors, 1 warnings, 0 checks, 18 lines checked
c3da899d24de drm/i915: Don't disable interrupts on PREEMPT_RT during atomic
updates
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
started disabling interrupts across atomic updates. This breaks on PREEMPT_RT
total: 0 errors, 1 warnings, 0 checks, 42 lines checked
b42b86050fde drm/i915: Disable tracing points on PREEMPT_RT
1d34fd20b9ee drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE
58071bffaf38 drm/i915/gt: Queue and wait for the irq_work item.
9152fc01f425 drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() +
spin_lock()
41f3da18a28a drm/i915: Drop the irqs_disabled() check
711977242684 drm/i915: Don't disable interrupts and pretend a lock as been
acquired in __timeline_mark_lock().
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#8:
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
irqsafe")
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit d67739268cf0 ("drm/i915/gt: Mark
up the nested engine-pm timeline lock as irqsafe")'
#8:
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
irqsafe")
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 6c69a45445af ("drm/i915/gt: Mark
context->active_count as protected by timeline->mutex")'
#9:
6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
timeline->mutex")
total: 2 errors, 1 warnings, 0 checks, 119 lines checked
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/dp: add drm_dp_phy_name() for getting DP PHY name
== Series Details == Series: series starting with [1/2] drm/dp: add drm_dp_phy_name() for getting DP PHY name URL : https://patchwork.freedesktop.org/series/95447/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21245_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21245_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21245_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_21245_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@debugfs-forcewake-user: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-iclb7/igt@i915_pm_...@debugfs-forcewake-user.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-iclb4/igt@i915_pm_...@debugfs-forcewake-user.html Known issues Here are the changes found in Patchwork_21245_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@process: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-snb6/igt@gem_ctx_persiste...@process.html * igt@gem_ctx_sseu@invalid-args: - shard-tglb: NOTRUN -> [SKIP][4] ([i915#280]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-tglb2/igt@gem_ctx_s...@invalid-args.html * igt@gem_exec_fair@basic-deadline: - shard-skl: NOTRUN -> [FAIL][5] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-skl5/igt@gem_exec_f...@basic-deadline.html - shard-apl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-kbl6/igt@gem_exec_fair@basic-n...@vecs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-kbl7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-apl6/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +201 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-apl2/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3323]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-apl3/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-skl5/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][17] ([i915#3002]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-snb2/igt@gem_userptr_bl...@input-checking.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +4 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21245/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html * igt@gen9_exec_parse@batch-invalid-length: - shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271]) +473 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchw
Re: [Intel-gfx] [PATCH] drm/i915/display: Remove check for low voltage sku for max dp source rate
On Tue, Oct 05, 2021 at 01:34:21PM +0300, Jani Nikula wrote:
>
> Cc: Imre, I think you were involved in adding the checks.
About ADL-S the spec says:
Bspec 53597:
Combo Port Maximum Speed:
OEM must use VBT to specify a maximum that is tolerated by the board design.
Combo Port HBR3 support:
May require retimer on motherboard. The OEM must use VBT to limit the link rate
to HBR2 if HBR3 not supported by motherboard.
Bspec/49201:
Combo Port HBR3/6.48GHz support:
Only supported on SKUs with higher I/O voltage
I take the above meaning that only high voltage SKUs support HBR3 and
on those SKUs the OEM must limit this to HBR2 if HBR3 would require a
retimer on the board, but the board doesn't have this.
If the above isn't correct and low voltage SKUs also in fact support
HBR3 (with retimers if necessary) then this should imo clarified at
Bspec/49201. The VBT limit could be used then if present, ignoring the
low voltage SKU readout.
> BR,
> Jani.
>
> On Tue, 05 Oct 2021, "Nautiyal, Ankit K" wrote:
> > On 10/5/2021 1:34 PM, Jani Nikula wrote:
> >> On Tue, 05 Oct 2021, Ankit Nautiyal wrote:
> >>> The low voltage sku check can be ignored as OEMs need to consider that
> >>> when designing the board and then put any limits in VBT.
> >> "can" or "must"?
> >>
> >> VBT has been notoriously buggy over the years, and we need to safeguard
> >> against that. Are there any cases where having these checks are wrong?
> >
> > Hi Jani,
> >
> > Bspec page for Combo PHY PLL frequencies now says "OEM must use VBT to
> > specify a maximum that is tolerated by the board design" for the rates
> > above 5.4G.
> >
> > Earlier it was mentioned that rates > 5.4G were supported on SKUs with
> > Higher I/O Voltage.
> >
> > There was an instance where on an ADL-S board, where VBT was showing as
> > HBR3 supporting for a combo phy port, but we were reading the IO
> > voltage as 0.85V in is_low_voltage_sku()
> >
> > (Specifically, we were reading Register_PORT_COMP_DW3 bits 24-25 as 0)
> > for a combo PHY port, and therefore we were limiting the BW to 5.4Gbps
> >
> > Due to this, 8k@60 mode was getting pruned on the board for that combo
> > phy port. On removing the low_voltage_sku( ) the mode was able to be set
> > properly.
> >
> > Incidentally, with Windows 8k@60 was also coming up on the same board on
> > same port.
> >
> > So I had checked with HW team and GOP/VBT team if driver should consider
> > the low voltage sku check. As per their response we 'can' ignore the
> > check and rely on the VBT, as OEM should limit the rate as per board
> > design. The Bspec was also updated to reflect the same.
> >
> > So IMHO we need not limit the rate as per is_low_voltage_sku check, as
> > this limiting of the rate through VBT is a must for the OEMs.
> >
> > I should perhaps change the wording of the commit message to convey the
> > same.
> >
> >
> > Thanks & Regards,
> >
> > Ankit
> >
> >
> >>
> >> BR,
> >> Jani.
> >>
> >>> Same is now changed in Bspec (53720).
> >>>
> >>> Signed-off-by: Ankit Nautiyal
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_dp.c | 32 +++--
> >>> 1 file changed, 3 insertions(+), 29 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >>> b/drivers/gpu/drm/i915/display/intel_dp.c
> >>> index 74a657ae131a..75c364c3c88e 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >>> @@ -297,23 +297,13 @@ static int dg2_max_source_rate(struct intel_dp
> >>> *intel_dp)
> >>> return intel_dp_is_edp(intel_dp) ? 81 : 135;
> >>> }
> >>>
> >>> -static bool is_low_voltage_sku(struct drm_i915_private *i915, enum phy
> >>> phy)
> >>> -{
> >>> - u32 voltage;
> >>> -
> >>> - voltage = intel_de_read(i915, ICL_PORT_COMP_DW3(phy)) &
> >>> VOLTAGE_INFO_MASK;
> >>> -
> >>> - return voltage == VOLTAGE_INFO_0_85V;
> >>> -}
> >>> -
> >>> static int icl_max_source_rate(struct intel_dp *intel_dp)
> >>> {
> >>> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> >>> struct drm_i915_private *dev_priv =
> >>> to_i915(dig_port->base.base.dev);
> >>> enum phy phy = intel_port_to_phy(dev_priv, dig_port->base.port);
> >>>
> >>> - if (intel_phy_is_combo(dev_priv, phy) &&
> >>> - (is_low_voltage_sku(dev_priv, phy) || !intel_dp_is_edp(intel_dp)))
> >>> + if (intel_phy_is_combo(dev_priv, phy) && !intel_dp_is_edp(intel_dp))
> >>> return 54;
> >>>
> >>> return 81;
> >>> @@ -321,23 +311,7 @@ static int icl_max_source_rate(struct intel_dp
> >>> *intel_dp)
> >>>
> >>> static int ehl_max_source_rate(struct intel_dp *intel_dp)
> >>> {
> >>> - struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> >>> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> >>> - enum phy phy = intel_port_to_phy(dev_priv, dig_port->base.port);
> >>> -
> >>> - if (intel_dp_is_edp(intel_dp) || is_low_
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Remove check for low voltage sku for max dp source rate
== Series Details ==
Series: drm/i915/display: Remove check for low voltage sku for max dp source
rate
URL : https://patchwork.freedesktop.org/series/95444/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21244_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_21244_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_async_flips@crc:
- {shard-rkl}:[PASS][1] -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-rkl-6/igt@kms_async_fl...@crc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-rkl-2/igt@kms_async_fl...@crc.html
Known issues
Here are the changes found in Patchwork_21244_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl: NOTRUN -> [DMESG-WARN][3] ([i915#180]) +2 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_ctx_persistence@process:
- shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-snb5/igt@gem_ctx_persiste...@process.html
* igt@gem_ctx_sseu@invalid-args:
- shard-tglb: NOTRUN -> [SKIP][5] ([i915#280])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-tglb6/igt@gem_ctx_s...@invalid-args.html
* igt@gem_exec_fair@basic-deadline:
- shard-skl: NOTRUN -> [FAIL][6] ([i915#2846])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-skl5/igt@gem_exec_f...@basic-deadline.html
- shard-apl: NOTRUN -> [FAIL][7] ([i915#2846])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-apl7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-kbl7/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_whisper@basic-fds-all:
- shard-glk: [PASS][10] -> [DMESG-WARN][11] ([i915#118] /
[i915#95]) +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-glk8/igt@gem_exec_whis...@basic-fds-all.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-glk2/igt@gem_exec_whis...@basic-fds-all.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][12] -> [SKIP][13] ([i915#2190])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-tglb8/igt@gem_huc_c...@huc-copy.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-tglb6/igt@gem_huc_c...@huc-copy.html
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-apl1/igt@gem_huc_c...@huc-copy.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-apl6/igt@gem_soft...@noreloc-s3.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-apl7/igt@gem_soft...@noreloc-s3.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-apl7/igt@gem_userptr_bl...@dmabuf-sync.html
- shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-skl5/igt@gem_userptr_bl...@dmabuf-sync.html
* igt@gem_userptr_blits@input-checking:
- shard-snb: NOTRUN -> [DMESG-WARN][19] ([i915#3002])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-snb2/igt@gem_userptr_bl...@input-checking.html
* igt@gen9_exec_parse@batch-invalid-length:
- shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271]) +244 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-snb5/igt@gen9_exec_pa...@batch-invalid-length.html
* igt@i915_pm_backlight@fade_with_suspend:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#456]) +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/shard-tglb5/igt@i915_pm_backlight@fade_with_suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21244/shard-tglb7/igt@i9
[Intel-gfx] [PATCH 5/8] drm/i915/gt: Queue and wait for the irq_work item.
Disabling interrupts and invoking the irq_work function directly breaks
on PREEMPT_RT.
PREEMPT_RT does not invoke all irq_work from hardirq context because
some of the user have spinlock_t locking in the callback function.
These locks are then turned into a sleeping locks which can not be
acquired with disabled interrupts.
Using irq_work_queue() has the benefit that the irqwork will be invoked
in the regular context. In general there is "no" delay between enqueuing
the callback and its invocation because the interrupt is raised right
away on architectures which support it (which includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 209cf265bf746..6e1b9068d944c 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -311,10 +311,9 @@ void __intel_breadcrumbs_park(struct intel_breadcrumbs *b)
/* Kick the work once more to drain the signalers, and disarm the irq */
irq_work_sync(&b->irq_work);
while (READ_ONCE(b->irq_armed) && !atomic_read(&b->active)) {
- local_irq_disable();
- signal_irq_work(&b->irq_work);
- local_irq_enable();
+ irq_work_queue(&b->irq_work);
cond_resched();
+ irq_work_sync(&b->irq_work);
}
}
--
2.33.0
[Intel-gfx] [PATCH 8/8] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock().
This is a revert of commits
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
irqsafe")
6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
timeline->mutex")
The existing code leads to a different behaviour depending on wheather
lockdep is enabled or not. Any following lock that is acquired without
disabling interrupts (but needs to) will not be noticed by lockdep.
This it not just a lockdep annotation but is used but an actual mutex_t
that is properly used as a lock but in case of __timeline_mark_lock()
lockdep is only told that it is acquired but no lock has been acquired.
It appears that its purporse is just satisfy the lockdep_assert_held()
check in intel_context_mark_active(). The other problem with disabling
interrupts is that on PREEMPT_RT interrupts are also disabled which
leads to problems for instance later during memory allocation.
Add an argument to intel_context_mark_active() which is true if the lock
must have been acquired, false if other magic is involved and the lock
is not needed. Use the `false' argument only from within
switch_to_kernel_context() and remove __timeline_mark_lock().
Cc: Peter Zijlstra
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_context.h | 6 ++-
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 38 +--
drivers/gpu/drm/i915/i915_request.c | 7 ++--
drivers/gpu/drm/i915/i915_request.h | 3 +-
5 files changed, 12 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index c410989507466..bed60dff93eff 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -161,9 +161,11 @@ static inline void intel_context_enter(struct
intel_context *ce)
ce->ops->enter(ce);
}
-static inline void intel_context_mark_active(struct intel_context *ce)
+static inline void intel_context_mark_active(struct intel_context *ce,
+bool timeline_mutex_needed)
{
- lockdep_assert_held(&ce->timeline->mutex);
+ if (timeline_mutex_needed)
+ lockdep_assert_held(&ce->timeline->mutex);
++ce->active_count;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
index 74775ae961b2b..02c0ab9fbb4b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
@@ -42,7 +42,7 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
struct i915_request *rq;
intel_context_enter(ce);
- rq = __i915_request_create(ce, gfp);
+ rq = __i915_request_create(ce, gfp, true);
intel_context_exit(ce);
return rq;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 1f07ac4e0672a..d75638d1d561e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -80,39 +80,6 @@ static int __engine_unpark(struct intel_wakeref *wf)
return 0;
}
-#if IS_ENABLED(CONFIG_LOCKDEP)
-
-static unsigned long __timeline_mark_lock(struct intel_context *ce)
-{
- unsigned long flags;
-
- local_irq_save(flags);
- mutex_acquire(&ce->timeline->mutex.dep_map, 2, 0, _THIS_IP_);
-
- return flags;
-}
-
-static void __timeline_mark_unlock(struct intel_context *ce,
- unsigned long flags)
-{
- mutex_release(&ce->timeline->mutex.dep_map, _THIS_IP_);
- local_irq_restore(flags);
-}
-
-#else
-
-static unsigned long __timeline_mark_lock(struct intel_context *ce)
-{
- return 0;
-}
-
-static void __timeline_mark_unlock(struct intel_context *ce,
- unsigned long flags)
-{
-}
-
-#endif /* !IS_ENABLED(CONFIG_LOCKDEP) */
-
static void duration(struct dma_fence *fence, struct dma_fence_cb *cb)
{
struct i915_request *rq = to_request(fence);
@@ -159,7 +126,6 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
{
struct intel_context *ce = engine->kernel_context;
struct i915_request *rq;
- unsigned long flags;
bool result = true;
/* GPU is pointing to the void, as good as in the kernel context. */
@@ -201,10 +167,9 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
* engine->wakeref.count, we may see the request completion and retire
* it causing an underflow of the engine->wakeref.
*/
- flags = __timeline_mark_lock(ce);
GEM_BUG_ON(atomic_read(&ce->timeline->active_count) < 0);
- rq = __i915_request_create(ce, GFP_NOWAIT);
+ rq = __i915_request_create(ce, GFP_NOWAIT, false);
if (IS_ERR(rq))
/* Context switch failed, hope for the best! Mayb
[Intel-gfx] [PATCH 7/8] drm/i915: Drop the irqs_disabled() check
The !irqs_disabled() check triggers on PREEMPT_RT even with i915_sched_engine::lock acquired. The reason is the lock is transformed into a sleeping lock on PREEMPT_RT and does not disable interrupts. There is no need to check for disabled interrupts. The lockdep annotation below already check if the lock has been acquired by the caller and will yell if the interrupts are not disabled. Remove the !irqs_disabled() check. Reported-by: Maarten Lankhorst Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/i915_request.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 79da5eca60af5..b9dd6100c6d17 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -559,7 +559,6 @@ bool __i915_request_submit(struct i915_request *request) RQ_TRACE(request, "\n"); - GEM_BUG_ON(!irqs_disabled()); lockdep_assert_held(&engine->sched_engine->lock); /* @@ -668,7 +667,6 @@ void __i915_request_unsubmit(struct i915_request *request) */ RQ_TRACE(request, "\n"); - GEM_BUG_ON(!irqs_disabled()); lockdep_assert_held(&engine->sched_engine->lock); /* -- 2.33.0
[Intel-gfx] [PATCH 6/8] drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock()
execlists_dequeue() is invoked from a function which uses
local_irq_disable() to disable interrupts so the spin_lock() behaves
like spin_lock_irq().
This breaks PREEMPT_RT because local_irq_disable() + spin_lock() is not
the same as spin_lock_irq().
execlists_dequeue_irq() and execlists_dequeue() has each one caller
only. If intel_engine_cs::active::lock is acquired and released with the
_irq suffix then it behaves almost as if execlists_dequeue() would be
invoked with disabled interrupts. The difference is the last part of the
function which is then invoked with enabled interrupts.
I can't tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Maarten Lankhorst
---
.../drm/i915/gt/intel_execlists_submission.c| 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index de5f9c86b9a44..dbf44f9567449 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -1283,7 +1283,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* and context switches) submission.
*/
- spin_lock(&sched_engine->lock);
+ spin_lock_irq(&sched_engine->lock);
/*
* If the queue is higher priority than the last
@@ -1383,7 +1383,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
* Even if ELSP[1] is occupied and not worthy
* of timeslices, our queue might be.
*/
- spin_unlock(&sched_engine->lock);
+ spin_unlock_irq(&sched_engine->lock);
return;
}
}
@@ -1409,7 +1409,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (last && !can_merge_rq(last, rq)) {
spin_unlock(&ve->base.sched_engine->lock);
- spin_unlock(&engine->sched_engine->lock);
+ spin_unlock_irq(&engine->sched_engine->lock);
return; /* leave this for another sibling */
}
@@ -1571,7 +1571,7 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
*/
sched_engine->queue_priority_hint = queue_prio(sched_engine);
i915_sched_engine_reset_on_empty(sched_engine);
- spin_unlock(&sched_engine->lock);
+ spin_unlock_irq(&sched_engine->lock);
/*
* We can skip poking the HW if we ended up with exactly the same set
@@ -1597,13 +1597,6 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
}
}
-static void execlists_dequeue_irq(struct intel_engine_cs *engine)
-{
- local_irq_disable(); /* Suspend interrupts across request submission */
- execlists_dequeue(engine);
- local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
-}
-
static void clear_ports(struct i915_request **ports, int count)
{
memset_p((void **)ports, NULL, count);
@@ -2427,7 +2420,7 @@ static void execlists_submission_tasklet(struct
tasklet_struct *t)
}
if (!engine->execlists.pending[0]) {
- execlists_dequeue_irq(engine);
+ execlists_dequeue(engine);
start_timeslice(engine);
}
--
2.33.0
[Intel-gfx] [PATCH 0/8] drm/i915: PREEMPT_RT related fixups.
Hi, the following patches are from the PREEMPT_RT queue. It is mostly about disabling interrupts/preemption which leads to problems. Unfortunately DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because it acquires locks from within trace points. I tested it on a SandyBridge with built-in i915 by using X, OpenGL and playing videos without noticing any warnings. However, some code paths were not entered. Sebastian
[Intel-gfx] [PATCH 2/8] drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates
From: Mike Galbraith
Commit
8d7849db3eab7 ("drm/i915: Make sprite updates atomic")
started disabling interrupts across atomic updates. This breaks on PREEMPT_RT
because within this section the code attempt to acquire spinlock_t locks which
are sleeping locks on PREEMPT_RT.
According to the comment the interrupts are disabled to avoid random delays and
not required for protection or synchronisation.
If this needs to happen with disabled interrupts on PREEMPT_RT, and the
whole section is restricted to register access then all sleeping locks
need to be acquired before interrupts are disabled and some function
maybe moved after enabling interrupts again.
This includes:
- prepare_to_wait() + finish_wait() due its wake queue.
- drm_crtc_vblank_put() -> vblank_disable_fn() drm_device::vbl_lock.
- skl_pfit_enable(), intel_update_plane(), vlv_atomic_update_fifo() and
maybe others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/display/intel_crtc.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 254e67141a776..7a39029b083f4 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -425,7 +425,8 @@ void intel_pipe_update_start(const struct intel_crtc_state
*new_crtc_state)
*/
intel_psr_wait_for_idle(new_crtc_state);
- local_irq_disable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ local_irq_disable();
crtc->debug.min_vbl = min;
crtc->debug.max_vbl = max;
@@ -450,11 +451,13 @@ void intel_pipe_update_start(const struct
intel_crtc_state *new_crtc_state)
break;
}
- local_irq_enable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ local_irq_enable();
timeout = schedule_timeout(timeout);
- local_irq_disable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ local_irq_disable();
}
finish_wait(wq, &wait);
@@ -487,7 +490,8 @@ void intel_pipe_update_start(const struct intel_crtc_state
*new_crtc_state)
return;
irq_disable:
- local_irq_disable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ local_irq_disable();
}
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_VBLANK_EVADE)
@@ -566,7 +570,8 @@ void intel_pipe_update_end(struct intel_crtc_state
*new_crtc_state)
new_crtc_state->uapi.event = NULL;
}
- local_irq_enable();
+ if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+ local_irq_enable();
/* Send VRR Push to terminate Vblank */
intel_vrr_send_push(new_crtc_state);
--
2.33.0
[Intel-gfx] [PATCH 1/8] drm/i915: Use preempt_disable/enable_rt() where recommended
From: Mike Galbraith
Mario Kleiner suggest in commit
ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into kms
driver.")
a spots where preemption should be disabled on PREEMPT_RT. The
difference is that on PREEMPT_RT the intel_uncore::lock disables neither
preemption nor interrupts and so region remains preemptible.
The area covers only register reads and writes. The part that worries me
is:
- __intel_get_crtc_scanline() the worst case is 100us if no match is
found.
- intel_crtc_scanlines_since_frame_timestamp() not sure how long this
may take in the worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner
Signed-off-by: Mike Galbraith
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_irq.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9bc4f4a8e12ec..547347241a47c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -886,7 +886,8 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
*/
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
- /* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */
+ if (IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_disable();
/* Get optional system timestamp before query. */
if (stime)
@@ -950,7 +951,8 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc *_crtc,
if (etime)
*etime = ktime_get();
- /* preempt_enable_rt() should go right here in PREEMPT_RT patchset. */
+ if (IS_ENABLED(CONFIG_PREEMPT_RT))
+ preempt_enable();
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
--
2.33.0
[Intel-gfx] [PATCH 4/8] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE
The order of the header files is important. If this header file is included after tracepoint.h was included then the NOTRACE here becomes a nop. Currently this happens for two .c files which use the tracepoitns behind DRM_I915_LOW_LEVEL_TRACEPOINTS. Cc: Steven Rostedt Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner --- drivers/gpu/drm/i915/i915_trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index 773e7362c4442..5ff6c0a37fdfa 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -826,7 +826,7 @@ DEFINE_EVENT(i915_request, i915_request_add, TP_ARGS(rq) ); -#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS) +#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS) && !defined(NOTRACE) DEFINE_EVENT(i915_request, i915_request_guc_submit, TP_PROTO(struct i915_request *rq), TP_ARGS(rq) -- 2.33.0
[Intel-gfx] [PATCH 3/8] drm/i915: Disable tracing points on PREEMPT_RT
Luca Abeni reported this: | BUG: scheduling while atomic: kworker/u8:2/15203/0x0003 | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10 | Call Trace: | rt_spin_lock+0x3f/0x50 | gen6_read32+0x45/0x1d0 [i915] | g4x_get_vblank_counter+0x36/0x40 [i915] | trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915] The tracing events use trace_i915_pipe_update_start() among other events use functions acquire spinlock_t locks which are transformed into sleeping locks on PREEMPT_RT. A few trace points use intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also might acquire a sleeping locks on PREEMPT_RT. At the time the arguments are evaluated within trace point, preemption is disabled and so the locks must not be acquired on PREEMPT_RT. Based on this I don't see any other way than disable trace points on PREMPT_RT. Reported-by: Luca Abeni Cc: Steven Rostedt Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/i915_trace.h | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index 806ad688274bf..773e7362c4442 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -2,6 +2,10 @@ #if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ) #define _I915_TRACE_H_ +#ifdef CONFIG_PREEMPT_RT +#define NOTRACE +#endif + #include #include #include -- 2.33.0
Re: [Intel-gfx] [PATCH] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup
On 05/10/2021 14:05, Thomas Hellström wrote:
Hi, Tvrtko,
On 10/5/21 13:31, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.
Before this patch the driver was not quite ready for that setup, mainly
because it was able to emit a semaphore wait between the two GPUs, which
results in deadlocks because semaphore target location in HWSP is neither
shared between the two, nor mapped in both GGTT spaces.
To fix it the patch adds an additional check to a couple of relevant code
paths in order to prevent using semaphores for inter-engine
synchronisation when relevant objects are not in the same GGTT space.
v2:
* Avoid adding rq->i915. (Chris)
v3:
* Use GGTT which describes the limit more precisely.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Matthew Auld
Cc: Thomas Hellström
An IMO pretty important bugfix. I read up a bit on the previous
discussion on this, and from what I understand the other two options were
1) Ripping out the semaphore code,
2) Consider dma-fences from other instances of the same driver as foreign.
Yes, with the caveat on the second point that there is a multi-tile
scenario, granted of limited consequence because it only applies is
someone tries to run that wo/ GuC, where the "same driver" check is not
enough. This patch handles that case as well. And of course it is
hypothetical someone would be able to create a inter-tile dependency
there. Probably nothing in the current code does it.
For imported dma-bufs we do 2), but particularly with lmem and p2p
that's a more straightforward decision.
I am not immediately familiar with p2p considerations.
I don't think 1) is a reasonable approach to fix this bug, (but perhaps
as a general cleanup?), and for 2) yes I guess we might end up doing
that, unless we find some real benefits in treating
same-driver-separate-device dma-fences as local, but for this particular
bug, IMO this is a reasonable fix.
On the option of removing the semaphore inter-optimisation I would not
call it cleanup since it had clear performance benefits. I personally
don't have those benchmarks results saved though. So I'd proceed with
caution there if the code can harmlessly remain in the confines of the
execlists backend.
Second topic, the whole same driver fence upcast issue, I suppose can be
discussed along the lines of whether priority inheritance across drivers
is useful. Like for instance page flip prio boost, which currently does
safely work between i915 instances, and is relevant to hybrid graphics.
It was safe when I looked at it, courtesy of global scheduler lock. If
we wanted to keep that and formalise via an more explicit/generic cross
driver API is the question. So unless it is not safe after all, I
wouldn't rip it out before the discussion on the big picture happens.
So,
Reviewed-by: Thomas Hellström
Thanks, I'll push it once again cleared by CI.
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_request.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 79da5eca60af..4f189982f67e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1145,6 +1145,12 @@ __emit_semaphore_wait(struct i915_request *to,
return 0;
}
+static bool
+can_use_semaphore_wait(struct i915_request *to, struct i915_request
*from)
+{
+ return to->engine->gt->ggtt == from->engine->gt->ggtt;
+}
+
static int
emit_semaphore_wait(struct i915_request *to,
struct i915_request *from,
@@ -1153,6 +1159,9 @@ emit_semaphore_wait(struct i915_request *to,
const intel_engine_mask_t mask = READ_ONCE(from->engine)->mask;
struct i915_sw_fence *wait = &to->submit;
+ if (!can_use_semaphore_wait(to, from))
+ goto await_fence;
+
if (!intel_context_use_semaphores(to->context))
goto await_fence;
@@ -1256,7 +1265,8 @@ __i915_request_await_execution(struct
i915_request *to,
* immediate execution, and so we must wait until it reaches the
* active slot.
*/
- if (intel_engine_has_semaphores(to->engine) &&
+ if (can_use_semaphore_wait(to, from) &&
+ intel_engine_has_semaphores(to->engine) &&
!i915_request_has_initial_breadcrumb(to)) {
err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
if (err < 0)
Re: [Intel-gfx] [PATCH v2] component: do not leave master devres group open after bind
On Wed, Sep 22, 2021 at 11:54:32AM +0300, Kai Vehmanen wrote:
> In current code, the devres group for aggregate master is left open
> after call to component_master_add_*(). This leads to problems when the
> master does further managed allocations on its own. When any
> participating driver calls component_del(), this leads to immediate
> release of resources.
>
> This came up when investigating a page fault occurring with i915 DRM
> driver unbind with 5.15-rc1 kernel. The following sequence occurs:
>
> i915_pci_remove()
>-> intel_display_driver_unregister()
> -> i915_audio_component_cleanup()
>-> component_del()
> -> component.c:take_down_master()
>-> hdac_component_master_unbind() [via master->ops->unbind()]
>-> devres_release_group(master->parent, NULL)
>
> With older kernels this has not caused issues, but with audio driver
> moving to use managed interfaces for more of its allocations, this no
> longer works. Devres log shows following to occur:
>
> component_master_add_with_match()
> [ 126.886032] snd_hda_intel :00:1f.3: DEVRES ADD 323ccdc5
> devm_component_match_release (24 bytes)
> [ 126.886045] snd_hda_intel :00:1f.3: DEVRES ADD 865cdb29 grp<
> (0 bytes)
> [ 126.886049] snd_hda_intel :00:1f.3: DEVRES ADD 1b480725 grp<
> (0 bytes)
>
> audio driver completes its PCI probe()
> [ 126.892238] snd_hda_intel :00:1f.3: DEVRES ADD 1b480725
> pcim_iomap_release (48 bytes)
>
> component_del() called() at DRM/i915 unbind()
> [ 137.579422] i915 :00:02.0: DEVRES REL ef44c293 grp< (0 bytes)
> [ 137.579445] snd_hda_intel :00:1f.3: DEVRES REL 865cdb29 grp<
> (0 bytes)
> [ 137.579458] snd_hda_intel :00:1f.3: DEVRES REL 1b480725
> pcim_iomap_release (48 bytes)
>
> So the "devres_release_group(master->parent, NULL)" ends up freeing the
> pcim_iomap allocation. Upon next runtime resume, the audio driver will
> cause a page fault as the iomap alloc was released without the driver
> knowing about it.
>
> Fix this issue by using the "struct master" pointer as identifier for
> the devres group, and by closing the devres group after
> the master->ops->bind() call is done. This allows devres allocations
> done by the driver acting as master to be isolated from the binding state
> of the aggregate driver. This modifies the logic originally introduced in
> commit 9e1ccb4a7700 ("drivers/base: fix devres handling for master device")
>
> BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/4136
> Signed-off-by: Kai Vehmanen
> Acked-by: Imre Deak
> Acked-by: Russell King (Oracle)
> ---
> drivers/base/component.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
What commit does this "fix:"? And does it need to go to stable
kernel(s)?
thanks,
greg k-h
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve DP link training further (rev5)
== Series Details == Series: drm/i915: Improve DP link training further (rev5) URL : https://patchwork.freedesktop.org/series/95405/ State : success == Summary == CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21250 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/index.html Known issues Here are the changes found in Patchwork_21250 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-x1275: NOTRUN -> [SKIP][2] ([fdo#109271]) +28 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@amdgpu/amd_prime@i915-to-amd: - fi-snb-2520m: NOTRUN -> [SKIP][3] ([fdo#109271]) +37 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html * igt@gem_huc_copy@huc-copy: - fi-kbl-x1275: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-x1275: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-snb-2520m: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-x1275: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][8] ([i915#2940]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@kms_flip@basic-flip-vs-modeset@c-dp1: - fi-cfl-8109u: [FAIL][10] ([i915#4165]) -> [PASS][11] +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b: - fi-cfl-8109u: [DMESG-WARN][12] ([i915#295]) -> [PASS][13] +18 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295 [i915#4165]: https://gitlab.freedesktop.org/drm/intel/issues/4165 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (38 -> 34) -- Additional (2): fi-kbl-x1275 fi-snb-2520m Missing(6): bat-dg1-6 fi-bsw-cyan bat-adlp-4 fi-bdw-samus bat-jsl-2 bat-jsl-1 Build changes - * Linux: CI_DRM_10683 -> Patchwork_21250 CI-20190529: 20190529 CI_DRM_10683: 2db2331e0b19308750c3b921c2779c4c2da9b04b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6230: a079f2e00693facf4cf6512f0ddb69b30826c80f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_21250: dbbc7aeca18af7e73feebf885dd1c105c585370f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == dbbc7aeca18a drm/i915: Call intel_dp_dump_link_status() for CR failures 15ce918cc135 drm/i915: Pimp link training debug prints ddfa1864e7d7 drm/i915: Print the DP vswing adjustment request 94bb4313c0df drm/i915: Show LTTPR in the TPS debug print dee501a3511e drm/i915: Tweak the DP "max vswing reached?" condition == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21250/index.html
Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
Regards,
Oak
> -Original Message-
> From: Thomas Hellström
> Sent: October 5, 2021 9:48 AM
> To: Zeng, Oak ; Auld, Matthew
> ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Christian König
>
> Subject: Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem
> backend
>
>
> On 10/5/21 04:05, Zeng, Oak wrote:
> > Hi Matthew/Thomas,
> >
> > See one question inline
> >
> > Regards,
> > Oak
> >
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> Matthew Auld
> > Sent: September 27, 2021 7:41 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
> ; Christian König
>
> > Subject: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
> >
> > For cached objects we can allocate our pages directly in shmem. This should
> make it possible(in a later patch) to utilise the existing i915-gem shrinker
> code
> for such objects. For now this is still disabled.
> >
> > v2(Thomas):
> >- Add optional try_to_writeback hook for objects. Importantly we need
> > to check if the object is even still shrinkable; in between us
> > dropping the shrinker LRU lock and acquiring the object lock it could
> > for
> > example have been moved. Also we need to differentiate between
> > "lazy" shrinking and the immediate writeback mode. Also later we need
> to
> > handle objects which don't even have mm.pages, so bundling this into
> > put_pages() would require somehow handling that edge case, hence
> > just letting the ttm backend handle everything in try_to_writeback
> > doesn't seem too bad.
> > v3(Thomas):
> >- Likely a bad idea to touch the object from the unpopulate hook,
> > since it's not possible to hold a reference, without also creating
> > circular dependency, so likely this is too fragile. For now just
> > ensure we at least mark the pages as dirty/accessed when called from
> > the
> > shrinker on WILLNEED objects.
> >- s/try_to_writeback/shrinker_release_pages, since this can do more
> > than just writeback.
> >- Get rid of do_backup boolean and just set the SWAPPED flag prior to
> > calling unpopulate.
> >- Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk,
> since
> > these just get skipped anyway. We can try to come up with something
> > better later.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Christian König
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 +
> > .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 +-
> > drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 17 +-
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 240 -
> -
> > 5 files changed, 245 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 3043fcbd31bd..1c9a1d8d3434 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -601,6 +601,14 @@ int i915_gem_object_wait_migration(struct
> drm_i915_gem_object *obj, bool
> i915_gem_object_placement_possible(struct drm_i915_gem_object *obj,
> > enum intel_memory_type type);
> >
> > +struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
> > + size_t size, struct intel_memory_region *mr,
> > + struct address_space *mapping,
> > + unsigned int max_segment);
> > +void shmem_free_st(struct sg_table *st, struct address_space *mapping,
> > + bool dirty, bool backup);
> > +void __shmem_writeback(size_t size, struct address_space *mapping);
> > +
> > #ifdef CONFIG_MMU_NOTIFIER
> > static inline bool
> > i915_gem_object_is_userptr(struct drm_i915_gem_object *obj) diff --git
> a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > index fa2ba9e2a4d0..f0fb17be2f7a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> > @@ -56,6 +56,8 @@ struct drm_i915_gem_object_ops {
> > struct sg_table *pages);
> > void (*truncate)(struct drm_i915_gem_object *obj);
> > void (*writeback)(struct drm_i915_gem_object *obj);
> > + int (*shrinker_release_pages)(struct drm_i915_gem_object *obj,
> > + bool should_writeback);
> >
> > int (*pread)(struct drm_i915_gem_object *obj,
> > const struct drm_i915_gem_pread *arg); diff --git
> a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > index 36b711ae9e28..19e55cc29a15 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > @@ -25,8 +
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Improve DP link training further (rev4)
On Tue, Oct 05, 2021 at 12:49:53PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Improve DP link training further (rev4) > URL : https://patchwork.freedesktop.org/series/95405/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21247 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_21247 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_21247, 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_21247/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_21247: > > ### IGT changes ### > > Possible regressions > > * igt@core_hotunplug@unbind-rebind: > - fi-tgl-u2: NOTRUN -> [INCOMPLETE][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html That looks like a straight up race during unbind. We turn off interrupts first, only then we cancel the hpd stuff (including the modeset_retry work) which presuambly was already running and told fb_helper that stuff happened, then the fb_helper proceeds to do a modeset while interrupts are already off and we're in the middle of tearing down the driver, and all hell breaks loose as a result. Unrelated to these patches, I *think*. I'll hit retest anyway to make sure. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
On 10/5/21 04:05, Zeng, Oak wrote:
Hi Matthew/Thomas,
See one question inline
Regards,
Oak
-Original Message-
From: Intel-gfx On Behalf Of Matthew
Auld
Sent: September 27, 2021 7:41 AM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
; Christian König
Subject: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem backend
For cached objects we can allocate our pages directly in shmem. This should
make it possible(in a later patch) to utilise the existing i915-gem shrinker
code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to check if the object is even still shrinkable; in between us
dropping the shrinker LRU lock and acquiring the object lock it could for
example have been moved. Also we need to differentiate between
"lazy" shrinking and the immediate writeback mode. Also later we need to
handle objects which don't even have mm.pages, so bundling this into
put_pages() would require somehow handling that edge case, hence
just letting the ttm backend handle everything in try_to_writeback
doesn't seem too bad.
v3(Thomas):
- Likely a bad idea to touch the object from the unpopulate hook,
since it's not possible to hold a reference, without also creating
circular dependency, so likely this is too fragile. For now just
ensure we at least mark the pages as dirty/accessed when called from the
shrinker on WILLNEED objects.
- s/try_to_writeback/shrinker_release_pages, since this can do more
than just writeback.
- Get rid of do_backup boolean and just set the SWAPPED flag prior to
calling unpopulate.
- Keep shmem_tt as lowest priority for the TTM LRU bo_swapout walk, since
these just get skipped anyway. We can try to come up with something
better later.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_object.h| 8 +
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 17 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 240 --
5 files changed, 245 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 3043fcbd31bd..1c9a1d8d3434 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -601,6 +601,14 @@ int i915_gem_object_wait_migration(struct
drm_i915_gem_object *obj, bool i915_gem_object_placement_possible(struct
drm_i915_gem_object *obj,
enum intel_memory_type type);
+struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
+ size_t size, struct intel_memory_region *mr,
+ struct address_space *mapping,
+ unsigned int max_segment);
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup);
+void __shmem_writeback(size_t size, struct address_space *mapping);
+
#ifdef CONFIG_MMU_NOTIFIER
static inline bool
i915_gem_object_is_userptr(struct drm_i915_gem_object *obj) diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index fa2ba9e2a4d0..f0fb17be2f7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -56,6 +56,8 @@ struct drm_i915_gem_object_ops {
struct sg_table *pages);
void (*truncate)(struct drm_i915_gem_object *obj);
void (*writeback)(struct drm_i915_gem_object *obj);
+ int (*shrinker_release_pages)(struct drm_i915_gem_object *obj,
+ bool should_writeback);
int (*pread)(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_pread *arg); diff --git
a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 36b711ae9e28..19e55cc29a15 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -25,8 +25,8 @@ static void check_release_pagevec(struct pagevec *pvec)
cond_resched();
}
-static void shmem_free_st(struct sg_table *st, struct address_space *mapping,
- bool dirty, bool backup)
+void shmem_free_st(struct sg_table *st, struct address_space *mapping,
+ bool dirty, bool backup)
{
struct sgt_iter sgt_iter;
struct pagevec pvec;
@@ -52,10 +52,10 @@ static void shmem_free_st(struct sg_table *st, struct
address_space *mapping,
kfree(st);
}
-static struct sg_table *shmem_alloc_st(struct drm_i915_private *i915,
-
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Improve DP link training further (rev5)
== Series Details == Series: drm/i915: Improve DP link training further (rev5) URL : https://patchwork.freedesktop.org/series/95405/ State : warning == Summary == $ dim checkpatch origin/drm-tip dee501a3511e drm/i915: Tweak the DP "max vswing reached?" condition 94bb4313c0df drm/i915: Show LTTPR in the TPS debug print ddfa1864e7d7 drm/i915: Print the DP vswing adjustment request -:25: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #25: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:349: +#define TRAIN_REQ_VSWING_ARGS(link_status) \ + _TRAIN_REQ_VSWING_ARGS(link_status, 0), \ + _TRAIN_REQ_VSWING_ARGS(link_status, 1), \ + _TRAIN_REQ_VSWING_ARGS(link_status, 2), \ + _TRAIN_REQ_VSWING_ARGS(link_status, 3) -:25: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'link_status' - possible side-effects? #25: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:349: +#define TRAIN_REQ_VSWING_ARGS(link_status) \ + _TRAIN_REQ_VSWING_ARGS(link_status, 0), \ + _TRAIN_REQ_VSWING_ARGS(link_status, 1), \ + _TRAIN_REQ_VSWING_ARGS(link_status, 2), \ + _TRAIN_REQ_VSWING_ARGS(link_status, 3) -:31: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #31: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:355: + (drm_dp_get_adjust_request_pre_emphasis((link_status), (lane)) >> DP_TRAIN_PRE_EMPHASIS_SHIFT) -:32: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #32: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:356: +#define TRAIN_REQ_PREEMPH_ARGS(link_status) \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 0), \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 1), \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 2), \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 3) -:32: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'link_status' - possible side-effects? #32: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:356: +#define TRAIN_REQ_PREEMPH_ARGS(link_status) \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 0), \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 1), \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 2), \ + _TRAIN_REQ_PREEMPH_ARGS(link_status, 3) total: 2 errors, 1 warnings, 2 checks, 41 lines checked 15ce918cc135 drm/i915: Pimp link training debug prints dbbc7aeca18a drm/i915: Call intel_dp_dump_link_status() for CR failures
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/28] dma-buf: add dma_resv_for_each_fence_unlocked v8
== Series Details == Series: series starting with [01/28] dma-buf: add dma_resv_for_each_fence_unlocked v8 URL : https://patchwork.freedesktop.org/series/95456/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21249 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21249 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21249, 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_21249/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21249: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-tgl-u2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html New tests - New tests have been introduced between CI_DRM_10683 and Patchwork_21249: ### New IGT tests (1) ### * igt@dmabuf@all@dma_resv: - Statuses : 31 pass(s) - Exec time: [0.02, 0.10] s Known issues Here are the changes found in Patchwork_21249 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@memory-alloc: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-kbl-soraka/igt@amdgpu/amd_ba...@memory-alloc.html * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-x1275: NOTRUN -> [SKIP][4] ([fdo#109271]) +28 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@amdgpu/amd_prime@i915-to-amd: - fi-snb-2520m: NOTRUN -> [SKIP][5] ([fdo#109271]) +37 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: NOTRUN -> [FAIL][6] ([i915#1888]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-1115g4: [PASS][7] -> [FAIL][8] ([i915#1888]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][9] ([i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html - fi-kbl-x1275: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@dp-hpd-fast: - fi-tgl-u2: NOTRUN -> [SKIP][11] ([fdo#109284] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-x1275: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-snb-2520m: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-u2: NOTRUN -> [SKIP][14] ([i915#4103]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-u2: NOTRUN -> [SKIP][15] ([fdo#109285]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-x1275: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21249/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-userptr: - fi-tgl-u2: NOTRUN -> [SKIP][17] ([i
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/28] dma-buf: add dma_resv_for_each_fence_unlocked v8
== Series Details == Series: series starting with [01/28] dma-buf: add dma_resv_for_each_fence_unlocked v8 URL : https://patchwork.freedesktop.org/series/95456/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/28] dma-buf: add dma_resv_for_each_fence_unlocked v8
== Series Details ==
Series: series starting with [01/28] dma-buf: add
dma_resv_for_each_fence_unlocked v8
URL : https://patchwork.freedesktop.org/series/95456/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4d20a8353f25 dma-buf: add dma_resv_for_each_fence_unlocked v8
-:23: WARNING:TYPO_SPELLING: 'superflous' may be misspelled - perhaps
'superfluous'?
#23:
v4: fix NULL deref when no explicit fence exists, drop superflous
^^
-:247: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'cursor' - possible
side-effects?
#247: FILE: include/linux/dma-resv.h:243:
+#define dma_resv_for_each_fence_unlocked(cursor, fence)
\
+ for (fence = dma_resv_iter_first_unlocked(cursor); \
+fence; fence = dma_resv_iter_next_unlocked(cursor))
-:247: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fence' - possible
side-effects?
#247: FILE: include/linux/dma-resv.h:243:
+#define dma_resv_for_each_fence_unlocked(cursor, fence)
\
+ for (fence = dma_resv_iter_first_unlocked(cursor); \
+fence; fence = dma_resv_iter_next_unlocked(cursor))
-:253: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: "Christian König" ' !=
'Signed-off-by: Christian König '
total: 0 errors, 2 warnings, 2 checks, 207 lines checked
730f3d21c81f dma-buf: add dma_resv_for_each_fence v2
-:105: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'cursor' - possible
side-effects?
#105: FILE: include/linux/dma-resv.h:261:
+#define dma_resv_for_each_fence(cursor, obj, all_fences, fence)\
+ for (dma_resv_iter_begin(cursor, obj, all_fences), \
+fence = dma_resv_iter_first(cursor); fence;\
+fence = dma_resv_iter_next(cursor))
-:105: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fence' - possible
side-effects?
#105: FILE: include/linux/dma-resv.h:261:
+#define dma_resv_for_each_fence(cursor, obj, all_fences, fence)\
+ for (dma_resv_iter_begin(cursor, obj, all_fences), \
+fence = dma_resv_iter_first(cursor); fence;\
+fence = dma_resv_iter_next(cursor))
-:112: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: "Christian König" ' !=
'Signed-off-by: Christian König '
total: 0 errors, 1 warnings, 2 checks, 86 lines checked
013a9ec61fe0 dma-buf: add dma_resv selftest v3
-:40: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#40:
new file mode 100644
-:45: WARNING:SPDX_LICENSE_TAG: Improper SPDX comment style for
'drivers/dma-buf/st-dma-resv.c', please use '//' instead
#45: FILE: drivers/dma-buf/st-dma-resv.c:1:
+/* SPDX-License-Identifier: MIT */
-:45: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#45: FILE: drivers/dma-buf/st-dma-resv.c:1:
+/* SPDX-License-Identifier: MIT */
-:48: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each
line
#48: FILE: drivers/dma-buf/st-dma-resv.c:4:
+/*
+* Copyright © 2019 Intel Corporation
-:235: ERROR:OPEN_BRACE: that open brace { should be on the previous line
#235: FILE: drivers/dma-buf/st-dma-resv.c:191:
+static int test_for_each_unlocked(void *arg, bool shared)
+{
-:302: ERROR:OPEN_BRACE: that open brace { should be on the previous line
#302: FILE: drivers/dma-buf/st-dma-resv.c:258:
+static int test_excl_for_each_unlocked(void *arg)
+{
-:307: ERROR:OPEN_BRACE: that open brace { should be on the previous line
#307: FILE: drivers/dma-buf/st-dma-resv.c:263:
+static int test_shared_for_each_unlocked(void *arg)
+{
-:326: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: "Christian König" ' !=
'Signed-off-by: Christian König '
total: 3 errors, 5 warnings, 0 checks, 294 lines checked
ccd90c562c2f dma-buf: use new iterator in dma_resv_copy_fences
-:125: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: "Christian König" ' !=
'Signed-off-by: Christian König '
total: 0 errors, 1 warnings, 0 checks, 106 lines checked
a6d5759c5743 dma-buf: use new iterator in dma_resv_get_fences v3
-:156: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: "Christian König" ' !=
'Signed-off-by: Christian König '
total: 0 errors, 1 warnings, 0 checks, 134 lines checked
a7df5e34b826 dma-buf: use new iterator in dma_resv_wait_timeout
-:101: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: "Christian König" ' !=
'Signed-off-by: Christian König '
total: 0 errors, 1 warnings, 0 checks, 82 lines checked
18fd3c76ebf0 dma-buf: use new iterator in dma_resv_test_signaled
-:92: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: "Christian König" ' !=
'Signed-off-by: Christian König '
total: 0 errors, 1 warnings, 0 checks, 72 lines che
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup (rev3)
== Series Details ==
Series: drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup (rev3)
URL : https://patchwork.freedesktop.org/series/94105/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21248
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_21248:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-tgl-dsi}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-tgl-dsi/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_21248 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-x1275: NOTRUN -> [SKIP][2] ([fdo#109271]) +28 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html
* igt@amdgpu/amd_prime@i915-to-amd:
- fi-snb-2520m: NOTRUN -> [SKIP][3] ([fdo#109271]) +37 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-x1275: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6] ([i915#2940])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-n3050: [PASS][7] -> [INCOMPLETE][8] ([i915#2940])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-x1275: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-snb-2520m: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_flip@basic-flip-vs-dpms@c-dp2:
- fi-cfl-8109u: [PASS][11] -> [DMESG-WARN][12] ([i915#165])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-d...@c-dp2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-d...@c-dp2.html
* igt@kms_flip@basic-flip-vs-modeset@c-dp2:
- fi-cfl-8109u: [PASS][13] -> [DMESG-WARN][14] ([i915#165] /
[i915#295]) +5 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp2.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-x1275: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#533])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#1436] /
[i915#3428])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-bsw-nick/igt@run...@aborted.html
- fi-bsw-n3050: NOTRUN -> [FAIL][17] ([fdo#109271] / [i915#1436] /
[i915#3428])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-bsw-n3050/igt@run...@aborted.html
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][18] ([i915#95]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21248/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@c-dp1:
- fi-cfl-8109u: [FAIL][20] ([i915#4165]) -> [DMESG-WARN][21]
([i915#165] / [i915#295]) +1 similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-cfl-8109u/igt@kms_flip@basic-flip-vs-mode...@c-dp1.html
[2
Re: [Intel-gfx] [PATCH] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup
Hi, Tvrtko,
On 10/5/21 13:31, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.
Before this patch the driver was not quite ready for that setup, mainly
because it was able to emit a semaphore wait between the two GPUs, which
results in deadlocks because semaphore target location in HWSP is neither
shared between the two, nor mapped in both GGTT spaces.
To fix it the patch adds an additional check to a couple of relevant code
paths in order to prevent using semaphores for inter-engine
synchronisation when relevant objects are not in the same GGTT space.
v2:
* Avoid adding rq->i915. (Chris)
v3:
* Use GGTT which describes the limit more precisely.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Matthew Auld
Cc: Thomas Hellström
An IMO pretty important bugfix. I read up a bit on the previous
discussion on this, and from what I understand the other two options were
1) Ripping out the semaphore code,
2) Consider dma-fences from other instances of the same driver as foreign.
For imported dma-bufs we do 2), but particularly with lmem and p2p
that's a more straightforward decision.
I don't think 1) is a reasonable approach to fix this bug, (but perhaps
as a general cleanup?), and for 2) yes I guess we might end up doing
that, unless we find some real benefits in treating
same-driver-separate-device dma-fences as local, but for this particular
bug, IMO this is a reasonable fix.
So,
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_request.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 79da5eca60af..4f189982f67e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1145,6 +1145,12 @@ __emit_semaphore_wait(struct i915_request *to,
return 0;
}
+static bool
+can_use_semaphore_wait(struct i915_request *to, struct i915_request *from)
+{
+ return to->engine->gt->ggtt == from->engine->gt->ggtt;
+}
+
static int
emit_semaphore_wait(struct i915_request *to,
struct i915_request *from,
@@ -1153,6 +1159,9 @@ emit_semaphore_wait(struct i915_request *to,
const intel_engine_mask_t mask = READ_ONCE(from->engine)->mask;
struct i915_sw_fence *wait = &to->submit;
+ if (!can_use_semaphore_wait(to, from))
+ goto await_fence;
+
if (!intel_context_use_semaphores(to->context))
goto await_fence;
@@ -1256,7 +1265,8 @@ __i915_request_await_execution(struct i915_request *to,
* immediate execution, and so we must wait until it reaches the
* active slot.
*/
- if (intel_engine_has_semaphores(to->engine) &&
+ if (can_use_semaphore_wait(to, from) &&
+ intel_engine_has_semaphores(to->engine) &&
!i915_request_has_initial_breadcrumb(to)) {
err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
if (err < 0)
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Improve DP link training further (rev4)
== Series Details == Series: drm/i915: Improve DP link training further (rev4) URL : https://patchwork.freedesktop.org/series/95405/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21247 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_21247 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_21247, 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_21247/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_21247: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-tgl-u2: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@core_hotunp...@unbind-rebind.html Known issues Here are the changes found in Patchwork_21247 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-bsw-kefka: NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@amdgpu/amd_prime@amd-to-i915: - fi-kbl-x1275: NOTRUN -> [SKIP][4] ([fdo#109271]) +28 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html * igt@amdgpu/amd_prime@i915-to-amd: - fi-snb-2520m: NOTRUN -> [SKIP][5] ([fdo#109271]) +37 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-snb-2520m/igt@amdgpu/amd_pr...@i915-to-amd.html * igt@gem_huc_copy@huc-copy: - fi-tgl-u2: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html - fi-kbl-x1275: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html * igt@kms_chamelium@dp-hpd-fast: - fi-tgl-u2: NOTRUN -> [SKIP][8] ([fdo#109284] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html * igt@kms_chamelium@hdmi-crc-fast: - fi-kbl-x1275: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-kbl-x1275/igt@kms_chamel...@hdmi-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-snb-2520m: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-snb-2520m/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-u2: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-u2: NOTRUN -> [SKIP][12] ([fdo#109285]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-kbl-x1275: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-kbl-x1275/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-userptr: - fi-tgl-u2: NOTRUN -> [SKIP][14] ([i915#3301]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - fi-tgl-u2: NOTRUN -> [FAIL][15] ([i915#1602] / [i915#2722]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-tgl-u2/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@execlists: - fi-bsw-kefka: [INCOMPLETE][16] ([i915#2940]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10683/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21247/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE]
Re: [Intel-gfx] [PATCH 17/28] drm/i915: use the new iterator in i915_gem_busy_ioctl v2
Am 05.10.21 um 14:40 schrieb Tvrtko Ursulin:
On 05/10/2021 12:37, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
Reviewed-by: Tvrtko Ursulin
Reminder - r-b was retracted until at least more text is added to
commit message about pros and cons. But really some discussion had
inside the i915 team on the topic.
Sure, going to move those to a different branch.
But I really only see the following options:
1. Grab the lock.
2. Use the _unlocked variant with get/put.
3. Add another _rcu iterator just for this case.
I'm fine with either, but Daniel pretty much already rejected #3 and
#2/#1 has more overhead then the original one.
Regards,
Christian.
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 35 ++--
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 6234e17259c1..dc72b36dae54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -82,8 +82,8 @@ i915_gem_busy_ioctl(struct drm_device *dev, void
*data,
{
struct drm_i915_gem_busy *args = data;
struct drm_i915_gem_object *obj;
- struct dma_resv_list *list;
- unsigned int seq;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
int err;
err = -ENOENT;
@@ -109,27 +109,20 @@ i915_gem_busy_ioctl(struct drm_device *dev,
void *data,
* to report the overall busyness. This is what the wait-ioctl
does.
*
*/
-retry:
- seq = raw_read_seqcount(&obj->base.resv->seq);
-
- /* Translate the exclusive fence to the READ *and* WRITE engine */
- args->busy =
busy_check_writer(dma_resv_excl_fence(obj->base.resv));
-
- /* Translate shared fences to READ set of engines */
- list = dma_resv_shared_list(obj->base.resv);
- if (list) {
- unsigned int shared_count = list->shared_count, i;
-
- for (i = 0; i < shared_count; ++i) {
- struct dma_fence *fence =
- rcu_dereference(list->shared[i]);
-
+ args->busy = 0;
+ dma_resv_iter_begin(&cursor, obj->base.resv, true);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
+ if (dma_resv_iter_is_restarted(&cursor))
+ args->busy = 0;
+
+ if (dma_resv_iter_is_exclusive(&cursor))
+ /* Translate the exclusive fence to the READ *and* WRITE
engine */
+ args->busy |= busy_check_writer(fence);
+ else
+ /* Translate shared fences to READ set of engines */
args->busy |= busy_check_reader(fence);
- }
}
-
- if (args->busy && read_seqcount_retry(&obj->base.resv->seq, seq))
- goto retry;
+ dma_resv_iter_end(&cursor);
err = 0;
out:
Re: [Intel-gfx] [PATCH 17/28] drm/i915: use the new iterator in i915_gem_busy_ioctl v2
On 05/10/2021 12:37, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
Reviewed-by: Tvrtko Ursulin
Reminder - r-b was retracted until at least more text is added to commit
message about pros and cons. But really some discussion had inside the
i915 team on the topic.
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 35 ++--
1 file changed, 14 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
index 6234e17259c1..dc72b36dae54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_busy.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_busy.c
@@ -82,8 +82,8 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
{
struct drm_i915_gem_busy *args = data;
struct drm_i915_gem_object *obj;
- struct dma_resv_list *list;
- unsigned int seq;
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
int err;
err = -ENOENT;
@@ -109,27 +109,20 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
* to report the overall busyness. This is what the wait-ioctl does.
*
*/
-retry:
- seq = raw_read_seqcount(&obj->base.resv->seq);
-
- /* Translate the exclusive fence to the READ *and* WRITE engine */
- args->busy = busy_check_writer(dma_resv_excl_fence(obj->base.resv));
-
- /* Translate shared fences to READ set of engines */
- list = dma_resv_shared_list(obj->base.resv);
- if (list) {
- unsigned int shared_count = list->shared_count, i;
-
- for (i = 0; i < shared_count; ++i) {
- struct dma_fence *fence =
- rcu_dereference(list->shared[i]);
-
+ args->busy = 0;
+ dma_resv_iter_begin(&cursor, obj->base.resv, true);
+ dma_resv_for_each_fence_unlocked(&cursor, fence) {
+ if (dma_resv_iter_is_restarted(&cursor))
+ args->busy = 0;
+
+ if (dma_resv_iter_is_exclusive(&cursor))
+ /* Translate the exclusive fence to the READ *and*
WRITE engine */
+ args->busy |= busy_check_writer(fence);
+ else
+ /* Translate shared fences to READ set of engines */
args->busy |= busy_check_reader(fence);
- }
}
-
- if (args->busy && read_seqcount_retry(&obj->base.resv->seq, seq))
- goto retry;
+ dma_resv_iter_end(&cursor);
err = 0;
out:
Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/dp: add drm_dp_phy_name() for getting DP PHY name
There was an issue with fd.o expired root cert, and that caused some issues during the weekend and yesterday, mostly with git fetches. I wonder if this is related. Can you re-test the patchset and see if the issue persists? Other patchsets nearby timewise seem to be unaffected by spurious sparses. Tomi > From: Nikula, Jani > > > I wonder what's going on here?! > > BR, > Jani. > > > On Tue, 05 Oct 2021, Patchwork > wrote: > > == Series Details == > > > > Series: series starting with [1/2] drm/dp: add drm_dp_phy_name() for > getting DP PHY name > > URL : https://patchwork.freedesktop.org/series/95447/ > > State : warning > > > > == Summary == > > > > $ dim sparse --fast origin/drm-tip > > Sparse version: v0.6.2 > > Fast mode used, each commit won't be checked separately. > > - > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + > > + >
