✓ Fi.CI.BAT: success for Enable Wa_14019159160 and Wa_16019325821 for MTL
== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL URL : https://patchwork.freedesktop.org/series/130335/ State : success == Summary == CI Bug Log - changes from CI_DRM_14330 -> Patchwork_130335v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130335v1/index.html Participating hosts (36 -> 35) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_130335v1 that come from known issues: ### CI changes ### Issues hit * boot: - bat-arls-2: [PASS][1] -> [FAIL][2] ([i915#10234]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/bat-arls-2/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130335v1/bat-arls-2/boot.html Possible fixes * boot: - fi-cfl-8109u: [FAIL][3] ([i915#8293]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/fi-cfl-8109u/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130335v1/fi-cfl-8109u/boot.html ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130335v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-8109u: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130335v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@kms_pm_backlight@basic-brightness: - fi-cfl-8109u: NOTRUN -> [SKIP][7] ([fdo#109271]) +11 other tests skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130335v1/fi-cfl-8109u/igt@kms_pm_backli...@basic-brightness.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#10234]: https://gitlab.freedesktop.org/drm/intel/issues/10234 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 Build changes - * Linux: CI_DRM_14330 -> Patchwork_130335v1 CI-20190529: 20190529 CI_DRM_14330: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7729: 7729 Patchwork_130335v1: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits bad74ae83b8d drm/i915/guc: Enable Wa_14019159160 37e96d480028 drm/i915/guc: Add support for w/a KLVs 5a7a1f96781d drm/i915: Enable Wa_16019325821 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130335v1/index.html
✗ Fi.CI.SPARSE: warning for Enable Wa_14019159160 and Wa_16019325821 for MTL
== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL URL : https://patchwork.freedesktop.org/series/130335/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
✗ Fi.CI.CHECKPATCH: warning for Enable Wa_14019159160 and Wa_16019325821 for MTL
== Series Details == Series: Enable Wa_14019159160 and Wa_16019325821 for MTL URL : https://patchwork.freedesktop.org/series/130335/ State : warning == Summary == Error: dim checkpatch failed 5e1af201c616 drm/i915: Enable Wa_16019325821 7c8b332ab8fd drm/i915/guc: Add support for w/a KLVs -:105: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #105: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c:829: + GEM_BUG_ON(iosys_map_is_null(>ads_map)); total: 0 errors, 1 warnings, 0 checks, 159 lines checked 1a89ed81e338 drm/i915/guc: Enable Wa_14019159160 -:101: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #101: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c:830: + GEM_BUG_ON(remain < size); total: 0 errors, 1 warnings, 0 checks, 99 lines checked
✓ Fi.CI.BAT: success for drm/i915/guc: Correct capture of EIR register on hang
== Series Details == Series: drm/i915/guc: Correct capture of EIR register on hang URL : https://patchwork.freedesktop.org/series/130330/ State : success == Summary == CI Bug Log - changes from CI_DRM_14330 -> Patchwork_130330v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130330v1/index.html Participating hosts (36 -> 34) -- Missing(2): fi-glk-j4005 fi-snb-2520m Known issues Here are the changes found in Patchwork_130330v1 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-cfl-8109u: [FAIL][1] ([i915#8293]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/fi-cfl-8109u/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130330v1/fi-cfl-8109u/boot.html ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130330v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-8109u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 other tests skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130330v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@kms_pm_backlight@basic-brightness: - fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271]) +11 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130330v1/fi-cfl-8109u/igt@kms_pm_backli...@basic-brightness.html Warnings * igt@i915_selftest@live@gem: - bat-arls-2: [DMESG-WARN][6] ([i915#10194]) -> [ABORT][7] ([i915#10194]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/bat-arls-2/igt@i915_selftest@l...@gem.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130330v1/bat-arls-2/igt@i915_selftest@l...@gem.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 Build changes - * Linux: CI_DRM_14330 -> Patchwork_130330v1 CI-20190529: 20190529 CI_DRM_14330: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7729: 7729 Patchwork_130330v1: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits b81c33687879 drm/i915/guc: Correct capture of EIR register on hang == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130330v1/index.html
✗ Fi.CI.BUILD: failure for tracing/treewide: Remove second parameter of __assign_str() (rev2)
== Series Details == Series: tracing/treewide: Remove second parameter of __assign_str() (rev2) URL : https://patchwork.freedesktop.org/series/130320/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/130320/revisions/2/mbox/ not applied Applying: tracing/treewide: Remove second parameter of __assign_str() error: sha1 information is lacking or useless (include/trace/stages/stage6_event_callback.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 tracing/treewide: Remove second parameter of __assign_str() 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". Build failed, no error log produced
✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Don't explode when the dig port we don't have an AUX CH
== Series Details == Series: series starting with [1/2] drm/i915: Don't explode when the dig port we don't have an AUX CH URL : https://patchwork.freedesktop.org/series/130329/ State : success == Summary == CI Bug Log - changes from CI_DRM_14330 -> Patchwork_130329v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130329v1/index.html Participating hosts (36 -> 34) -- Missing(2): fi-glk-j4005 fi-snb-2520m Known issues Here are the changes found in Patchwork_130329v1 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-cfl-8109u: [FAIL][1] ([i915#8293]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/fi-cfl-8109u/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130329v1/fi-cfl-8109u/boot.html ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130329v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-8109u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 other tests skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130329v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@kms_pm_backlight@basic-brightness: - fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271]) +11 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130329v1/fi-cfl-8109u/igt@kms_pm_backli...@basic-brightness.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 Build changes - * Linux: CI_DRM_14330 -> Patchwork_130329v1 CI-20190529: 20190529 CI_DRM_14330: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7729: 7729 Patchwork_130329v1: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 6d8c257975c1 drm/i915: Simplify aux_ch_to_digital_port() 2fcc36ca9688 drm/i915: Don't explode when the dig port we don't have an AUX CH == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130329v1/index.html
✗ Fi.CI.BAT: failure for drm/i915/guc: Simplify/extend platform check for Wa_14018913170 (rev2)
== Series Details == Series: drm/i915/guc: Simplify/extend platform check for Wa_14018913170 (rev2) URL : https://patchwork.freedesktop.org/series/130022/ State : failure == Summary == CI Bug Log - changes from CI_DRM_14330 -> Patchwork_130022v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_130022v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_130022v2, please notify your bug team (i915-ci-in...@lists.freedesktop.org) 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_130022v2/index.html Participating hosts (36 -> 35) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_130022v2: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - bat-dg2-8: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130022v2/bat-dg2-8/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_130022v2 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-cfl-8109u: [FAIL][3] ([i915#8293]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/fi-cfl-8109u/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130022v2/fi-cfl-8109u/boot.html ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130022v2/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-8109u: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 other tests skip [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130022v2/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][7] ([i915#9197]) +1 other test skip [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130022v2/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pm_backlight@basic-brightness: - fi-cfl-8109u: NOTRUN -> [SKIP][8] ([fdo#109271]) +11 other tests skip [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130022v2/fi-cfl-8109u/igt@kms_pm_backli...@basic-brightness.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 [i915#9197]: https://gitlab.freedesktop.org/drm/intel/issues/9197 Build changes - * Linux: CI_DRM_14330 -> Patchwork_130022v2 CI-20190529: 20190529 CI_DRM_14330: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7729: 7729 Patchwork_130022v2: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits ffaa11f2814e drm/i915/guc: Simplify/extend platform check for Wa_14018913170 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130022v2/index.html
✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/bios: bump expected child device size (rev3)
== Series Details == Series: series starting with [1/3] drm/i915/bios: bump expected child device size (rev3) URL : https://patchwork.freedesktop.org/series/129378/ State : success == Summary == CI Bug Log - changes from CI_DRM_14330 -> Patchwork_129378v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/index.html Participating hosts (36 -> 35) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_129378v3 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-cfl-8109u: [FAIL][1] ([i915#8293]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/fi-cfl-8109u/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/fi-cfl-8109u/boot.html ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-8109u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 other tests skip [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][5] -> [ABORT][6] ([i915#9662]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - bat-dg2-14: [PASS][7] -> [INCOMPLETE][8] ([i915#10137]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14330/bat-dg2-14/igt@i915_selftest@l...@hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/bat-dg2-14/igt@i915_selftest@l...@hangcheck.html * igt@kms_pm_backlight@basic-brightness: - fi-cfl-8109u: NOTRUN -> [SKIP][9] ([fdo#109271]) +11 other tests skip [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/fi-cfl-8109u/igt@kms_pm_backli...@basic-brightness.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#10137]: https://gitlab.freedesktop.org/drm/intel/issues/10137 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#8293]: https://gitlab.freedesktop.org/drm/intel/issues/8293 [i915#9662]: https://gitlab.freedesktop.org/drm/intel/issues/9662 Build changes - * Linux: CI_DRM_14330 -> Patchwork_129378v3 CI-20190529: 20190529 CI_DRM_14330: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7729: 7729 Patchwork_129378v3: 7291e2e67dff0ff573900266382c9c9248a7dea5 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits f5a23f106b63 drm/i915/bios: abstract child device expected size b9277c2c3299 drm/i915/bios: abstract child device size check 1b368d99d12f drm/i915/bios: bump expected child device size == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129378v3/index.html
✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/bios: bump expected child device size (rev3)
== Series Details == Series: series starting with [1/3] drm/i915/bios: bump expected child device size (rev3) URL : https://patchwork.freedesktop.org/series/129378/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:147:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:149:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:153:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:155:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:173:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:175:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:179:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:181:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:185:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:187:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:191:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:194:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:236:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:238:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
Re: [PATCH v2 00/21] drm/i915: Add Display Port tunnel BW allocation support
On Tue, Feb 20, 2024 at 11:18:20PM +0200, Imre Deak wrote: > This is v2 of [1], with the following changes: > > - Several functional/typo/formatting fixes, detailed in the patches. > - Move the BW allocation from encoder hooks to > intel_atomic_commit_tail() fixing the allocation for MST streams > enabled/disabled w/o a full modeset (i.e. w/o re-enabling the master > stream). > - Fix an MST mode restore issue during system resume, which also lead > to a tunnel BW allocation failure. (Patch 3) > - Ensure a DPCD DPRX cap read as required by the TBT CM any time a long > HPD pulse is detected. (Patch 20) > - Explicitly disable the BW allocation mode during system suspend. > > The patchset is also available at: > https://github.com/ideak/linux/commits/dp_tun_bw_alloc > > Cc: Mika Westerberg > Cc: Ville Syrjälä > Cc: Uma Shankar > Cc: Jouni Högander > Cc: Saranya Gopal > Cc: Rajaram Regupathy > Cc: Gil Fine > Cc: Naama Shachar > Cc: Pengfei Xu > > [1] https://lore.kernel.org/all/20240123102850.390126-1-imre.d...@intel.com > > Imre Deak (21): > drm/dp: Add drm_dp_max_dprx_data_rate() > drm/dp: Add support for DP tunneling > drm/i915: Fix display bpp limit computation during system resume > drm/i915/dp: Add support to notify MST connectors to retry modesets > drm/i915/dp: Use drm_dp_max_dprx_data_rate() > drm/i915/dp: Factor out intel_dp_config_required_rate() > drm/i915/dp: Export intel_dp_max_common_rate/lane_count() > drm/i915/dp: Factor out intel_dp_update_sink_caps() > drm/i915/dp: Factor out intel_dp_read_dprx_caps() > drm/i915/dp: Add intel_dp_max_link_data_rate() > drm/i915/dp: Add way to get active pipes with syncing commits > drm/i915/dp: Add support for DP tunnel BW allocation > drm/i915/dp: Add DP tunnel atomic state and check BW limit > drm/i915/dp: Account for tunnel BW limit in > intel_dp_max_link_data_rate() > drm/i915/dp: Compute DP tunnel BW during encoder state computation > drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable > hooks > drm/i915/dp: Handle DP tunnel IRQs > drm/i915/dp: Call intel_dp_sync_state() always for DDI DP encoders > drm/i915/dp: Suspend/resume DP tunnels > drm/i915/dp: Read DPRX for all long HPD pulses > drm/i915/dp: Enable DP tunnel BW allocation mode I think I eyeballed this sufficiently now. Only a few minor issues which I pointed out already. Otherwise this is: Reviewed-by: Ville Syrjälä > > drivers/gpu/drm/display/Kconfig | 21 + > drivers/gpu/drm/display/Makefile |2 + > drivers/gpu/drm/display/drm_dp_helper.c | 30 + > drivers/gpu/drm/display/drm_dp_tunnel.c | 1929 + > drivers/gpu/drm/i915/Kconfig | 14 + > drivers/gpu/drm/i915/Kconfig.debug|1 + > drivers/gpu/drm/i915/Makefile |3 + > drivers/gpu/drm/i915/display/intel_atomic.c | 10 + > drivers/gpu/drm/i915/display/intel_crtc.c | 52 + > drivers/gpu/drm/i915/display/intel_crtc.h |2 + > drivers/gpu/drm/i915/display/intel_ddi.c |3 +- > drivers/gpu/drm/i915/display/intel_display.c | 26 +- > .../gpu/drm/i915/display/intel_display_core.h |1 + > .../drm/i915/display/intel_display_driver.c | 20 +- > .../drm/i915/display/intel_display_types.h|9 + > drivers/gpu/drm/i915/display/intel_dp.c | 292 ++- > drivers/gpu/drm/i915/display/intel_dp.h | 13 +- > .../drm/i915/display/intel_dp_link_training.c | 33 +- > .../drm/i915/display/intel_dp_link_training.h |1 + > drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 +- > .../gpu/drm/i915/display/intel_dp_tunnel.c| 815 +++ > .../gpu/drm/i915/display/intel_dp_tunnel.h| 133 ++ > drivers/gpu/drm/i915/display/intel_link_bw.c | 27 +- > drivers/gpu/drm/i915/display/intel_link_bw.h |2 +- > drivers/gpu/drm/i915/display/intel_tc.c |7 + > include/drm/display/drm_dp.h | 61 + > include/drm/display/drm_dp_helper.h |2 + > include/drm/display/drm_dp_tunnel.h | 248 +++ > 28 files changed, 3650 insertions(+), 125 deletions(-) > create mode 100644 drivers/gpu/drm/display/drm_dp_tunnel.c > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.c > create mode 100644 drivers/gpu/drm/i915/display/intel_dp_tunnel.h > create mode 100644 include/drm/display/drm_dp_tunnel.h > > -- > 2.39.2 -- Ville Syrjälä Intel
Re: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
On Sat, Feb 24, 2024 at 12:09:41AM +0200, Imre Deak wrote:
> On Fri, Feb 23, 2024 at 11:11:45PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 20, 2024 at 11:18:31PM +0200, Imre Deak wrote:
> > > Add a way to get the active pipes through a given DP port by syncing
> > > against a related pending non-blocking commit. Atm
> > > intel_dp_get_active_pipes() will only try to sync a given pipe and if
> > > that would block ignore the pipe. A follow-up change enabling the DP
> > > tunnel BW allocation mode will need to ensure that all active pipes are
> > > returned.
> > >
> > > This change will use intel_crtc_state::uapi.commit instead of the
> > > corresponding commit in the connector state. This shouldn't make a
> > > difference, since the two commit objects match for an active pipe.
> >
> > There is a slight difference here in that a non-modeset/fastset commit
> > will not have the connector inluded in the state and thus
> > connector->state.commit will be updated.
> >
> > I think the original idea of the code was to just skip anything that
> > looks like it's already undergoing a full modeset. With this we might
> > skip the retrain if there happens to be any kind of commit happening
> > on the crtc. Althoguh it seems that the original code is already
> > broken in the same way when there's a fastset happening in parallel.
>
> Ok, didn't think of it. Are you ok to sync instead of try-sync the pipes
> in case of link re-training?
Yeah, I guess that should be safer option, and we do recheck the
condition after the sync anyway so it shouldn't cause too much
extra stuff to happen. We can think about optimizing it correctly
later if necessary.
>
> > > A follow-up patchset will remove syncing during TC port reset, which
> > > should reset a port/pipe even if syncing against a commit would block.
> > > Syncing OTOH is not needed there, since the commit used for the reset
> > > implies a sync already. For now add a TODO comment for this.
> > >
> > > v2:
> > > - Add a separate function to try-sync the pipes. (Ville)
> > >
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> > > drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> > > drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> > > drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> > > 4 files changed, 37 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > index 25593f6aae7de..17ed2e62cc66a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > > @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> > > *state,
> > > out:
> > > intel_psr_unlock(new_crtc_state);
> > > }
> > > +
> > > +/**
> > > + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of
> > > pipes
> > > + * @i915: i915 device object
> > > + * @pipe_mask: Mask of pipes to sync
> > > + *
> > > + * Try to sync a pending non-blocking commit for the provided pipes in
> > > + * @pipe_mask. The commit won't be synced if this would block.
> > > + *
> > > + * Return a mask of the pipes that got synced or didn't need syncing.
> > > + */
> > > +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> > > pipe_mask)
> > > +{
> > > + struct intel_crtc *crtc;
> > > + u32 synced = 0;
> > > +
> > > + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> > > + const struct intel_crtc_state *crtc_state =
> > > + to_intel_crtc_state(crtc->base.state);
> > > +
> > > + if (!crtc_state->uapi.commit ||
> > > + try_wait_for_completion(_state->uapi.commit->hw_done))
> > > + synced |= BIT(crtc->pipe);
> > > + }
> > > +
> > > + return synced;
> > > +}
> > > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> > > b/drivers/gpu/drm/i915/display/intel_crtc.h
> > > index 22d7993d1f0ba..71a5b93166da7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> > > @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
> > > drm_i915_private *i915,
> > > void intel_wait_for_vblank_if_active(struct drm_i915_private *i915,
> > >enum pipe pipe);
> > > void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
> > > +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> > > pipe_mask);
> > >
> > > #endif
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index d9e75922ff8f5..d0452d3e534a7 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp
> > > *intel_dp,
> > > if (!crtc_state->hw.active)
> > >
Re: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
On Fri, Feb 23, 2024 at 11:11:45PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 20, 2024 at 11:18:31PM +0200, Imre Deak wrote:
> > Add a way to get the active pipes through a given DP port by syncing
> > against a related pending non-blocking commit. Atm
> > intel_dp_get_active_pipes() will only try to sync a given pipe and if
> > that would block ignore the pipe. A follow-up change enabling the DP
> > tunnel BW allocation mode will need to ensure that all active pipes are
> > returned.
> >
> > This change will use intel_crtc_state::uapi.commit instead of the
> > corresponding commit in the connector state. This shouldn't make a
> > difference, since the two commit objects match for an active pipe.
>
> There is a slight difference here in that a non-modeset/fastset commit
> will not have the connector inluded in the state and thus
> connector->state.commit will be updated.
>
> I think the original idea of the code was to just skip anything that
> looks like it's already undergoing a full modeset. With this we might
> skip the retrain if there happens to be any kind of commit happening
> on the crtc. Althoguh it seems that the original code is already
> broken in the same way when there's a fastset happening in parallel.
Ok, didn't think of it. Are you ok to sync instead of try-sync the pipes
in case of link re-training?
> > A follow-up patchset will remove syncing during TC port reset, which
> > should reset a port/pipe even if syncing against a commit would block.
> > Syncing OTOH is not needed there, since the commit used for the reset
> > implies a sync already. For now add a TODO comment for this.
> >
> > v2:
> > - Add a separate function to try-sync the pipes. (Ville)
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> > drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> > drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> > drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> > 4 files changed, 37 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> > b/drivers/gpu/drm/i915/display/intel_crtc.c
> > index 25593f6aae7de..17ed2e62cc66a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> > @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> > *state,
> > out:
> > intel_psr_unlock(new_crtc_state);
> > }
> > +
> > +/**
> > + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of
> > pipes
> > + * @i915: i915 device object
> > + * @pipe_mask: Mask of pipes to sync
> > + *
> > + * Try to sync a pending non-blocking commit for the provided pipes in
> > + * @pipe_mask. The commit won't be synced if this would block.
> > + *
> > + * Return a mask of the pipes that got synced or didn't need syncing.
> > + */
> > +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask)
> > +{
> > + struct intel_crtc *crtc;
> > + u32 synced = 0;
> > +
> > + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> > + const struct intel_crtc_state *crtc_state =
> > + to_intel_crtc_state(crtc->base.state);
> > +
> > + if (!crtc_state->uapi.commit ||
> > + try_wait_for_completion(_state->uapi.commit->hw_done))
> > + synced |= BIT(crtc->pipe);
> > + }
> > +
> > + return synced;
> > +}
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> > b/drivers/gpu/drm/i915/display/intel_crtc.h
> > index 22d7993d1f0ba..71a5b93166da7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> > @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
> > drm_i915_private *i915,
> > void intel_wait_for_vblank_if_active(struct drm_i915_private *i915,
> > enum pipe pipe);
> > void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
> > +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> > pipe_mask);
> >
> > #endif
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d9e75922ff8f5..d0452d3e534a7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp
> > *intel_dp,
> > if (!crtc_state->hw.active)
> > continue;
> >
> > - if (conn_state->commit &&
> > - !try_wait_for_completion(_state->commit->hw_done))
> > - continue;
> > -
> > *pipe_mask |= BIT(crtc->pipe);
> > }
> > drm_connector_list_iter_end(_iter);
> > @@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder
> > *encoder,
> > if (ret)
> > return ret;
> >
> > + pipe_mask &=
Re: [PATCH v2 12/21] drm/i915/dp: Add support for DP tunnel BW allocation
On Tue, Feb 20, 2024 at 11:18:32PM +0200, Imre Deak wrote:
> +static void queue_retry_work(struct intel_atomic_state *state,
> + struct drm_dp_tunnel *tunnel,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + struct intel_encoder *encoder;
> +
> + encoder = intel_get_crtc_new_encoder(state, crtc_state);
I was pondering what happens if we have no encoder here?
But I guess crtc_state->tunnel_ref.tunnel should be NULL in
that case and so we should not end up here.
> +
> + if (!intel_digital_port_connected(encoder))
> + return;
> +
> + drm_dbg_kms(>drm,
> + "[DPTUN %s][ENCODER:%d:%s] BW allocation failed on a
> connected sink\n",
> + drm_dp_tunnel_name(tunnel),
> + encoder->base.base.id,
> + encoder->base.name);
> +
> + intel_dp_queue_modeset_retry_for_link(state, encoder, crtc_state);
> +}
> +
--
Ville Syrjälä
Intel
Re: [PATCH v2 02/21] drm/dp: Add support for DP tunneling
On Tue, Feb 20, 2024 at 11:18:22PM +0200, Imre Deak wrote:
> +static inline void drm_dp_tunnel_ref_put(struct drm_dp_tunnel_ref
> *tunnel_ref)
> +{
> + drm_dp_tunnel_put(tunnel_ref->tunnel, _ref->tracker);
Should we set tunnel_ref->tunnel=NULL here?
--
Ville Syrjälä
Intel
Re: [PATCH v2 16/21] drm/i915/dp: Allocate/free DP tunnel BW in the encoder enable/disable hooks
On Tue, Feb 20, 2024 at 11:18:36PM +0200, Imre Deak wrote: > Allocate and free the DP tunnel BW required by a stream while > enabling/disabling the stream during a modeset. > > v2: > - Move the allocation up from encoder hooks to > intel_atomic_commit_tail(). Subject should be adjusted to match. > > Signed-off-by: Imre Deak > Reviewed-by: Uma Shankar (v1) > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 1 + > drivers/gpu/drm/i915/display/intel_display.c | 2 ++ > 2 files changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index bea4415902044..ed7301808604d 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -54,6 +54,7 @@ > #include "intel_dp_aux.h" > #include "intel_dp_link_training.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_dpio_phy.h" > #include "intel_dsi.h" > #include "intel_fdi.h" > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 20647c97e86fa..445efe0087cde 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -7123,6 +7123,8 @@ static void intel_atomic_commit_tail(struct > intel_atomic_state *state) > > intel_commit_modeset_disables(state); > > + intel_dp_tunnel_atomic_alloc_bw(state); > + > /* FIXME: Eventually get rid of our crtc->config pointer */ > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) > crtc->config = new_crtc_state; > -- > 2.39.2 -- Ville Syrjälä Intel
Re: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
On Tue, Feb 20, 2024 at 11:18:31PM +0200, Imre Deak wrote:
> Add a way to get the active pipes through a given DP port by syncing
> against a related pending non-blocking commit. Atm
> intel_dp_get_active_pipes() will only try to sync a given pipe and if
> that would block ignore the pipe. A follow-up change enabling the DP
> tunnel BW allocation mode will need to ensure that all active pipes are
> returned.
>
> This change will use intel_crtc_state::uapi.commit instead of the
> corresponding commit in the connector state. This shouldn't make a
> difference, since the two commit objects match for an active pipe.
There is a slight difference here in that a non-modeset/fastset commit
will not have the connector inluded in the state and thus
connector->state.commit will be updated.
I think the original idea of the code was to just skip anything that
looks like it's already undergoing a full modeset. With this we might
skip the retrain if there happens to be any kind of commit happening
on the crtc. Althoguh it seems that the original code is already
broken in the same way when there's a fastset happening in parallel.
>
> A follow-up patchset will remove syncing during TC port reset, which
> should reset a port/pipe even if syncing against a commit would block.
> Syncing OTOH is not needed there, since the commit used for the reset
> implies a sync already. For now add a TODO comment for this.
>
> v2:
> - Add a separate function to try-sync the pipes. (Ville)
>
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> 4 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 25593f6aae7de..17ed2e62cc66a 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
> out:
> intel_psr_unlock(new_crtc_state);
> }
> +
> +/**
> + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of pipes
> + * @i915: i915 device object
> + * @pipe_mask: Mask of pipes to sync
> + *
> + * Try to sync a pending non-blocking commit for the provided pipes in
> + * @pipe_mask. The commit won't be synced if this would block.
> + *
> + * Return a mask of the pipes that got synced or didn't need syncing.
> + */
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask)
> +{
> + struct intel_crtc *crtc;
> + u32 synced = 0;
> +
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> + const struct intel_crtc_state *crtc_state =
> + to_intel_crtc_state(crtc->base.state);
> +
> + if (!crtc_state->uapi.commit ||
> + try_wait_for_completion(_state->uapi.commit->hw_done))
> + synced |= BIT(crtc->pipe);
> + }
> +
> + return synced;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> b/drivers/gpu/drm/i915/display/intel_crtc.h
> index 22d7993d1f0ba..71a5b93166da7 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
> drm_i915_private *i915,
> void intel_wait_for_vblank_if_active(struct drm_i915_private *i915,
>enum pipe pipe);
> void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32 pipe_mask);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d9e75922ff8f5..d0452d3e534a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp
> *intel_dp,
> if (!crtc_state->hw.active)
> continue;
>
> - if (conn_state->commit &&
> - !try_wait_for_completion(_state->commit->hw_done))
> - continue;
> -
> *pipe_mask |= BIT(crtc->pipe);
> }
> drm_connector_list_iter_end(_iter);
> @@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder *encoder,
> if (ret)
> return ret;
>
> + pipe_mask &= intel_crtc_try_sync_pipes(dev_priv, pipe_mask);
> +
> if (pipe_mask == 0)
> return 0;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 6b374d481cd9e..14d17903a81f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -7,6 +7,7 @@
> #include
[PATCH v3 0/3] Enable Wa_14019159160 and Wa_16019325821 for MTL
From: John Harrison Enable Wa_14019159160 and Wa_16019325821 for MTL RCS/CCS workarounds for MTL. v2: Fix bug in WA KLV implementation (offset not being reset to start of list). Add better comment to prep patch about how KLVs can be added. Add a module parameter override and disable the w/a by default as it causes performance regressions and is only required by very specific workloads. v3: Rebase to latest tree. Drop module parameter as performance regression is apparently not detectable after all and a bunch of more common workloads have been seen to hit the issue. Signed-off-by: John Harrison John Harrison (3): drm/i915: Enable Wa_16019325821 drm/i915/guc: Add support for w/a KLVs drm/i915/guc: Enable Wa_14019159160 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 22 +++-- drivers/gpu/drm/i915/gt/intel_engine_types.h | 8 +- .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 + drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 7 ++ drivers/gpu/drm/i915/gt/uc/intel_guc.c| 5 ++ drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 + drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 89 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 8 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +- 10 files changed, 141 insertions(+), 15 deletions(-) -- 2.43.0
[PATCH v3 2/3] drm/i915/guc: Add support for w/a KLVs
From: John Harrison
To prevent running out of bits, new w/a enable flags are being added
via a KLV system instead of a 32 bit flags word.
Signed-off-by: John Harrison
Reviewed-by: Vinay Belgaumkar
---
.../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 73 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 5 +-
5 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index dabeaf4f245f3..00d6402333f8e 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -36,6 +36,7 @@ enum intel_guc_load_status {
INTEL_GUC_LOAD_STATUS_INVALID_INIT_DATA_RANGE_START,
INTEL_GUC_LOAD_STATUS_MPU_DATA_INVALID = 0x73,
INTEL_GUC_LOAD_STATUS_INIT_MMIO_SAVE_RESTORE_INVALID = 0x74,
+ INTEL_GUC_LOAD_STATUS_KLV_WORKAROUND_INIT_ERROR= 0x75,
INTEL_GUC_LOAD_STATUS_INVALID_INIT_DATA_RANGE_END,
INTEL_GUC_LOAD_STATUS_READY= 0xF0,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index be70c46604b49..57b9031327767 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -204,6 +204,8 @@ struct intel_guc {
struct guc_mmio_reg *ads_regset;
/** @ads_golden_ctxt_size: size of the golden contexts in the ADS */
u32 ads_golden_ctxt_size;
+ /** @ads_waklv_size: size of workaround KLVs */
+ u32 ads_waklv_size;
/** @ads_capture_size: size of register lists in the ADS used for error
capture */
u32 ads_capture_size;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index f7372f736a776..6af3fa8b92e34 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -46,6 +46,10 @@
* +---+
* | padding |
* +---+ <== 4K aligned
+ * | w/a KLVs |
+ * +---+
+ * | padding |
+ * +---+ <== 4K aligned
* | capture lists |
* +---+
* | padding |
@@ -88,6 +92,11 @@ static u32 guc_ads_golden_ctxt_size(struct intel_guc *guc)
return PAGE_ALIGN(guc->ads_golden_ctxt_size);
}
+static u32 guc_ads_waklv_size(struct intel_guc *guc)
+{
+ return PAGE_ALIGN(guc->ads_waklv_size);
+}
+
static u32 guc_ads_capture_size(struct intel_guc *guc)
{
return PAGE_ALIGN(guc->ads_capture_size);
@@ -113,7 +122,7 @@ static u32 guc_ads_golden_ctxt_offset(struct intel_guc *guc)
return PAGE_ALIGN(offset);
}
-static u32 guc_ads_capture_offset(struct intel_guc *guc)
+static u32 guc_ads_waklv_offset(struct intel_guc *guc)
{
u32 offset;
@@ -123,6 +132,16 @@ static u32 guc_ads_capture_offset(struct intel_guc *guc)
return PAGE_ALIGN(offset);
}
+static u32 guc_ads_capture_offset(struct intel_guc *guc)
+{
+ u32 offset;
+
+ offset = guc_ads_waklv_offset(guc) +
+guc_ads_waklv_size(guc);
+
+ return PAGE_ALIGN(offset);
+}
+
static u32 guc_ads_private_data_offset(struct intel_guc *guc)
{
u32 offset;
@@ -796,6 +815,49 @@ guc_capture_prep_lists(struct intel_guc *guc)
return PAGE_ALIGN(total_size);
}
+static void guc_waklv_init(struct intel_guc *guc)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+ u32 offset, addr_ggtt, remain, size;
+
+ if (!intel_uc_uses_guc_submission(>uc))
+ return;
+
+ if (GUC_FIRMWARE_VER(guc) < MAKE_GUC_VER(70, 10, 0))
+ return;
+
+ GEM_BUG_ON(iosys_map_is_null(>ads_map));
+ offset = guc_ads_waklv_offset(guc);
+ remain = guc_ads_waklv_size(guc);
+
+ /*
+* Add workarounds here:
+*
+* if (want_wa_) {
+* size = guc_waklv_(guc, offset, remain);
+* offset += size;
+* remain -= size;
+* }
+*/
+
+ size = guc_ads_waklv_size(guc) - remain;
+ if (!size)
+ return;
+
+ offset = guc_ads_waklv_offset(guc);
+ addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
+
+ ads_blob_write(guc, ads.wa_klv_addr_lo, addr_ggtt);
+ ads_blob_write(guc, ads.wa_klv_addr_hi, 0);
+ ads_blob_write(guc, ads.wa_klv_size, size);
+}
+
+static int guc_prep_waklv(struct intel_guc *guc)
+{
+ /* Fudge something chunky for now: */
+
[PATCH v3 1/3] drm/i915: Enable Wa_16019325821
From: John Harrison
Some platforms require holding RCS context switches until CCS is idle
(the reverse w/a of Wa_14014475959). Some platforms require both
versions.
Signed-off-by: John Harrison
Reviewed-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 19 +++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 7 ---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 3 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ++-
5 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index e1bf13e3d3070..bb8e4c151a026 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -743,21 +743,23 @@ static u32 *gen12_emit_preempt_busywait(struct
i915_request *rq, u32 *cs)
}
/* Wa_14014475959:dg2 */
-#define CCS_SEMAPHORE_PPHWSP_OFFSET0x540
-static u32 ccs_semaphore_offset(struct i915_request *rq)
+/* Wa_16019325821 */
+#define HOLD_SWITCHOUT_SEMAPHORE_PPHWSP_OFFSET 0x540
+static u32 hold_switchout_semaphore_offset(struct i915_request *rq)
{
return i915_ggtt_offset(rq->context->state) +
- (LRC_PPHWSP_PN * PAGE_SIZE) + CCS_SEMAPHORE_PPHWSP_OFFSET;
+ (LRC_PPHWSP_PN * PAGE_SIZE) +
HOLD_SWITCHOUT_SEMAPHORE_PPHWSP_OFFSET;
}
/* Wa_14014475959:dg2 */
-static u32 *ccs_emit_wa_busywait(struct i915_request *rq, u32 *cs)
+/* Wa_16019325821 */
+static u32 *hold_switchout_emit_wa_busywait(struct i915_request *rq, u32 *cs)
{
int i;
*cs++ = MI_ATOMIC_INLINE | MI_ATOMIC_GLOBAL_GTT | MI_ATOMIC_CS_STALL |
MI_ATOMIC_MOVE;
- *cs++ = ccs_semaphore_offset(rq);
+ *cs++ = hold_switchout_semaphore_offset(rq);
*cs++ = 0;
*cs++ = 1;
@@ -773,7 +775,7 @@ static u32 *ccs_emit_wa_busywait(struct i915_request *rq,
u32 *cs)
MI_SEMAPHORE_POLL |
MI_SEMAPHORE_SAD_EQ_SDD;
*cs++ = 0;
- *cs++ = ccs_semaphore_offset(rq);
+ *cs++ = hold_switchout_semaphore_offset(rq);
*cs++ = 0;
return cs;
@@ -790,8 +792,9 @@ gen12_emit_fini_breadcrumb_tail(struct i915_request *rq,
u32 *cs)
cs = gen12_emit_preempt_busywait(rq, cs);
/* Wa_14014475959:dg2 */
- if (intel_engine_uses_wa_hold_ccs_switchout(rq->engine))
- cs = ccs_emit_wa_busywait(rq, cs);
+ /* Wa_16019325821 */
+ if (intel_engine_uses_wa_hold_switchout(rq->engine))
+ cs = hold_switchout_emit_wa_busywait(rq, cs);
rq->tail = intel_ring_offset(rq, cs);
assert_ring_tail_valid(rq->ring, rq->tail);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 960e6be2042fe..b519812ba120d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -586,7 +586,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_RCS_REG_STATE BIT(9)
#define I915_ENGINE_HAS_EU_PRIORITYBIT(10)
#define I915_ENGINE_FIRST_RENDER_COMPUTE BIT(11)
-#define I915_ENGINE_USES_WA_HOLD_CCS_SWITCHOUT BIT(12)
+#define I915_ENGINE_USES_WA_HOLD_SWITCHOUT BIT(12)
unsigned int flags;
/*
@@ -696,10 +696,11 @@ intel_engine_has_relative_mmio(const struct
intel_engine_cs * const engine)
}
/* Wa_14014475959:dg2 */
+/* Wa_16019325821 */
static inline bool
-intel_engine_uses_wa_hold_ccs_switchout(struct intel_engine_cs *engine)
+intel_engine_uses_wa_hold_switchout(struct intel_engine_cs *engine)
{
- return engine->flags & I915_ENGINE_USES_WA_HOLD_CCS_SWITCHOUT;
+ return engine->flags & I915_ENGINE_USES_WA_HOLD_SWITCHOUT;
}
#endif /* __INTEL_ENGINE_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2b450c43bbd7f..d5c856be31491 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -294,6 +294,10 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
IS_DG2(gt->i915))
flags |= GUC_WA_HOLD_CCS_SWITCHOUT;
+ /* Wa_16019325821 */
+ if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)))
+ flags |= GUC_WA_RCS_CCS_SWITCHOUT;
+
/*
* Wa_14012197797
* Wa_22011391025
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 8ae1846431da7..48863188a130e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -96,8 +96,9 @@
#define GUC_WA_GAM_CREDITS BIT(10)
#define GUC_WA_DUAL_QUEUEBIT(11)
#define GUC_WA_RCS_RESET_BEFORE_RC6 BIT(13)
-#define GUC_WA_CONTEXT_ISOLATION BIT(15)
#define GUC_WA_PRE_PARSERBIT(14)
+#define GUC_WA_CONTEXT_ISOLATION BIT(15)
+#define
[PATCH v3 3/3] drm/i915/guc: Enable Wa_14019159160
From: John Harrison
Use the new w/a KLV support to enable a MTL w/a. Note, this w/a is a
super-set of Wa_16019325821, so requires turning that one as well as
setting the new flag for Wa_14019159160 itself.
Signed-off-by: John Harrison
Reviewed-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 3 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 7
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 34 ++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
6 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index bb8e4c151a026..8cf58b29410bc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -744,6 +744,7 @@ static u32 *gen12_emit_preempt_busywait(struct i915_request
*rq, u32 *cs)
/* Wa_14014475959:dg2 */
/* Wa_16019325821 */
+/* Wa_14019159160 */
#define HOLD_SWITCHOUT_SEMAPHORE_PPHWSP_OFFSET 0x540
static u32 hold_switchout_semaphore_offset(struct i915_request *rq)
{
@@ -753,6 +754,7 @@ static u32 hold_switchout_semaphore_offset(struct
i915_request *rq)
/* Wa_14014475959:dg2 */
/* Wa_16019325821 */
+/* Wa_14019159160 */
static u32 *hold_switchout_emit_wa_busywait(struct i915_request *rq, u32 *cs)
{
int i;
@@ -793,6 +795,7 @@ gen12_emit_fini_breadcrumb_tail(struct i915_request *rq,
u32 *cs)
/* Wa_14014475959:dg2 */
/* Wa_16019325821 */
+ /* Wa_14019159160 */
if (intel_engine_uses_wa_hold_switchout(rq->engine))
cs = hold_switchout_emit_wa_busywait(rq, cs);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index b519812ba120d..ba55c059063db 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -697,6 +697,7 @@ intel_engine_has_relative_mmio(const struct intel_engine_cs
* const engine)
/* Wa_14014475959:dg2 */
/* Wa_16019325821 */
+/* Wa_14019159160 */
static inline bool
intel_engine_uses_wa_hold_switchout(struct intel_engine_cs *engine)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
index 58012edd4eb0e..bebf28e3c4794 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h
@@ -101,4 +101,11 @@ enum {
GUC_CONTEXT_POLICIES_KLV_NUM_IDS = 5,
};
+/*
+ * Workaround keys:
+ */
+enum {
+ GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE =
0x9001,
+};
+
#endif /* _ABI_GUC_KLVS_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index d5c856be31491..db3cb628f40dc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -295,6 +295,7 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
flags |= GUC_WA_HOLD_CCS_SWITCHOUT;
/* Wa_16019325821 */
+ /* Wa_14019159160 */
if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)))
flags |= GUC_WA_RCS_CCS_SWITCHOUT;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 6af3fa8b92e34..68d9e277eca8b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -815,6 +815,25 @@ guc_capture_prep_lists(struct intel_guc *guc)
return PAGE_ALIGN(total_size);
}
+/* Wa_14019159160 */
+static u32 guc_waklv_ra_mode(struct intel_guc *guc, u32 offset, u32 remain)
+{
+ u32 size;
+ u32 klv_entry[] = {
+ /* 16:16 key/length */
+ FIELD_PREP(GUC_KLV_0_KEY,
GUC_WORKAROUND_KLV_SERIALIZED_RA_MODE) |
+ FIELD_PREP(GUC_KLV_0_LEN, 0),
+ /* 0 dwords data */
+ };
+
+ size = sizeof(klv_entry);
+ GEM_BUG_ON(remain < size);
+
+ iosys_map_memcpy_to(>ads_map, offset, klv_entry, size);
+
+ return size;
+}
+
static void guc_waklv_init(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
@@ -830,15 +849,12 @@ static void guc_waklv_init(struct intel_guc *guc)
offset = guc_ads_waklv_offset(guc);
remain = guc_ads_waklv_size(guc);
- /*
-* Add workarounds here:
-*
-* if (want_wa_) {
-* size = guc_waklv_(guc, offset, remain);
-* offset += size;
-* remain -= size;
-* }
-*/
+ /* Wa_14019159160 */
+ if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71))) {
+ size = guc_waklv_ra_mode(guc, offset, remain);
+ offset += size;
+ remain -= size;
+ }
size = guc_ads_waklv_size(guc) - remain;
if (!size)
diff --git
Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()
On Fri, 23 Feb 2024 13:46:53 -0500
Steven Rostedt wrote:
> Now one thing I could do is to not remove the parameter, but just add:
>
> WARN_ON_ONCE((src) != __data_offsets->item##_ptr_);
>
> in the __assign_str() macro to make sure that it's still the same that is
> assigned. But I'm not sure how useful that is, and still causes burden to
> have it. I never really liked the passing of the string in two places to
> begin with.
Hmm, maybe I'll just add this patch for 6.9 and then in 6.10 do the
parameter removal.
-- Steve
diff --git a/include/trace/stages/stage6_event_callback.h
b/include/trace/stages/stage6_event_callback.h
index 0c0f50bcdc56..7372e2c2a0c4 100644
--- a/include/trace/stages/stage6_event_callback.h
+++ b/include/trace/stages/stage6_event_callback.h
@@ -35,6 +35,7 @@ #define __assign_str(dst, src)
do {\
char *__str__ = __get_str(dst); \
int __len__ = __get_dynamic_array_len(dst) - 1; \
+ WARN_ON_ONCE((src) != __data_offsets.dst##_ptr_); \
memcpy(__str__, __data_offsets.dst##_ptr_ ? : \
EVENT_NULL_STR, __len__);\
__str__[__len__] = '\0';\
[PATCH] drm/i915/guc: Correct capture of EIR register on hang
From: John Harrison
The EIR register (0x20B0) was being included in the engine class list
for render and compute as the absolute register address. However, it
is actually a ring register available on all engines at an offset of
(base) + 0xB0. As it was included as an RCS engine but with the
absolute address, GuC was adding on another 0x2000 and coming out at
an invalid location. Thus it would reject the register and complain
about only managing a partial capture.
So update the list to use the RING_EIR version of the register and
include it for all engines.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index a1cd40d805178..0cb5f22a173cb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -51,6 +51,7 @@
{ RING_ESR(0), 0, 0, "ESR" }, \
{ RING_DMA_FADD(0), 0, 0, "RING_DMA_FADD_LDW" }, \
{ RING_DMA_FADD_UDW(0), 0, 0, "RING_DMA_FADD_UDW" }, \
+ { RING_EIR(0), 0, 0, "EIR" }, \
{ RING_IPEIR(0),0, 0, "IPEIR" }, \
{ RING_IPEHR(0),0, 0, "IPEHR" }, \
{ RING_INSTPS(0), 0, 0, "INSTPS" }, \
@@ -80,9 +81,6 @@
{ GEN8_RING_PDP_LDW(0, 3), 0, 0, "PDP3_LDW" }, \
{ GEN8_RING_PDP_UDW(0, 3), 0, 0, "PDP3_UDW" }
-#define COMMON_BASE_HAS_EU \
- { EIR, 0, 0, "EIR" }
-
#define COMMON_BASE_RENDER \
{ GEN7_SC_INSTDONE, 0, 0, "GEN7_SC_INSTDONE" }
@@ -105,7 +103,6 @@ static const struct __guc_mmio_reg_descr
xe_lp_global_regs[] = {
/* XE_LP Render / Compute Per-Class */
static const struct __guc_mmio_reg_descr xe_lp_rc_class_regs[] = {
- COMMON_BASE_HAS_EU,
COMMON_BASE_RENDER,
COMMON_GEN12BASE_RENDER,
};
@@ -148,7 +145,6 @@ static const struct __guc_mmio_reg_descr gen8_global_regs[]
= {
};
static const struct __guc_mmio_reg_descr gen8_rc_class_regs[] = {
- COMMON_BASE_HAS_EU,
COMMON_BASE_RENDER,
};
--
2.43.0
[PATCH 2/2] drm/i915: Simplify aux_ch_to_digital_port()
From: Ville Syrjälä
Just return the correct thing from within the loop to make
the code more readable. We have no ref counts/etc. to deal
with here so no point in breaking from the loop just to return
something.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_power_well.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 06900ff307b2..b61b571a850a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -217,27 +217,22 @@ static struct intel_digital_port *
aux_ch_to_digital_port(struct drm_i915_private *dev_priv,
enum aux_ch aux_ch)
{
- struct intel_digital_port *dig_port = NULL;
struct intel_encoder *encoder;
for_each_intel_encoder(_priv->drm, encoder) {
+ struct intel_digital_port *dig_port;
+
/* We'll check the MST primary port */
if (encoder->type == INTEL_OUTPUT_DP_MST)
continue;
dig_port = enc_to_dig_port(encoder);
- if (!dig_port)
- continue;
- if (dig_port->aux_ch != aux_ch) {
- dig_port = NULL;
- continue;
- }
-
- break;
+ if (dig_port && dig_port->aux_ch == aux_ch)
+ return dig_port;
}
- return dig_port;
+ return NULL;
}
static enum phy icl_aux_pw_to_phy(struct drm_i915_private *i915,
--
2.43.0
[PATCH 1/2] drm/i915: Don't explode when the dig port we don't have an AUX CH
From: Ville Syrjälä
The icl+ power well code currently assumes that every AUX power
well maps to an encoder which is using said power well. That is
by no menas guaranteed as we:
- only register encoders for ports declared in the VBT
- combo PHY HDMI-only encoder no longer get an AUX CH since
commit 9856308c94ca ("drm/i915: Only populate aux_ch if really needed")
However we have places such as intel_power_domains_sanitize_state()
that blindly traverse all the possible power wells. So these bits
of code may very well encounbter an aux power well with no associated
encoder.
In this particular case the BIOS seems to have left one AUX power
well enabled even though we're dealing with a HDMI only encoder
on a combo PHY. We then proceed to turn off said power well and
explode when we can't find a matching encoder. As a short term fix
we should be able to just skip the PHY related parts of the power
well programming since we know this situation can only happen with
combo PHYs.
Another option might be to go back to always picking an AUX CH for
all encoders. However I'm a bit wary about that since we might in
theory end up conflicting with the VBT AUX CH assignment. Also
that wouldn't help with encoders not declared in the VBT, should
we ever need to poke the corresponding power wells.
Longer term we need to figure out what the actual relationship
is between the PHY vs. AUX CH vs. AUX power well. Currently this
is entirely unclear.
Cc: sta...@vger.kernel.org
Fixes: 9856308c94ca ("drm/i915: Only populate aux_ch if really needed")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10184
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_power_well.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 47cd6bb04366..06900ff307b2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -246,7 +246,14 @@ static enum phy icl_aux_pw_to_phy(struct drm_i915_private
*i915,
enum aux_ch aux_ch = icl_aux_pw_to_ch(power_well);
struct intel_digital_port *dig_port = aux_ch_to_digital_port(i915,
aux_ch);
- return intel_port_to_phy(i915, dig_port->base.port);
+ /*
+* FIXME should we care about the (VBT defined) dig_port->aux_ch
+* relationship or should this be purely defined by the hardware layout?
+* Currently if the port doesn't appear in the VBT, or if it's declared
+* as HDMI-only and routed to a combo PHY, the encoder either won't be
+* present at all or it will not have an aux_ch assigned.
+*/
+ return dig_port ? intel_port_to_phy(i915, dig_port->base.port) :
PHY_NONE;
}
static void hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
@@ -414,7 +421,8 @@ icl_combo_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
intel_de_rmw(dev_priv, regs->driver, 0, HSW_PWR_WELL_CTL_REQ(pw_idx));
- if (DISPLAY_VER(dev_priv) < 12)
+ /* FIXME this is a mess */
+ if (phy != PHY_NONE)
intel_de_rmw(dev_priv, ICL_PORT_CL_DW12(phy),
0, ICL_LANE_ENABLE_AUX);
@@ -437,7 +445,10 @@ icl_combo_phy_aux_power_well_disable(struct
drm_i915_private *dev_priv,
drm_WARN_ON(_priv->drm, !IS_ICELAKE(dev_priv));
- intel_de_rmw(dev_priv, ICL_PORT_CL_DW12(phy), ICL_LANE_ENABLE_AUX, 0);
+ /* FIXME this is a mess */
+ if (phy != PHY_NONE)
+ intel_de_rmw(dev_priv, ICL_PORT_CL_DW12(phy),
+ICL_LANE_ENABLE_AUX, 0);
intel_de_rmw(dev_priv, regs->driver, HSW_PWR_WELL_CTL_REQ(pw_idx), 0);
--
2.43.0
[PATCH v3] drm/i915/guc: Simplify/extend platform check for Wa_14018913170
From: John Harrison
The above w/a is required for every platform that the i915 driver
supports. It is fixed on the latest platforms but they are only
supported by Xe instead of i915. So just remove the platform check
completely and keep the code simple.
v2: Add extra comment (review feedback from Rodrigo).
Signed-off-by: John Harrison
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2b450c43bbd7f..d2b7425bbdcc2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -319,10 +319,12 @@ static u32 guc_ctl_wa_flags(struct intel_guc *guc)
if (!RCS_MASK(gt))
flags |= GUC_WA_RCS_REGS_IN_CCS_REGS_LIST;
- /* Wa_14018913170 */
+ /*
+* Wa_14018913170: Applicable to all platforms supported by i915 so
+* don't bother testing for all X/Y/Z platforms explicitly.
+*/
if (GUC_FIRMWARE_VER(guc) >= MAKE_GUC_VER(70, 7, 0)) {
- if (IS_DG2(gt->i915) || IS_METEORLAKE(gt->i915) ||
IS_PONTEVECCHIO(gt->i915))
- flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
+ flags |= GUC_WA_ENABLE_TSC_CHECK_ON_RC6;
}
return flags;
--
2.43.0
Re: i915 build error on drm-misc-next
On 2/23/2024 11:35 AM, Rodrigo Vivi wrote:
On Fri, Feb 23, 2024 at 09:47:11AM -0800, Abhinav Kumar wrote:
CC Dmitry
Hi Rodrigo
On 2/23/2024 9:00 AM, Rodrigo Vivi wrote:
On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
With the x86_64_defconfig I see the following when building drm-misc-next:
CC drivers/gpu/drm/i915/display/intel_crt.o
CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
CC drivers/gpu/drm/i915/display/intel_ddi.o
CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
CC drivers/gpu/drm/i915/display/intel_display_device.o
CC drivers/gpu/drm/i915/display/intel_display_trace.o
CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
CC drivers/gpu/drm/i915/display/intel_dp.o
CC drivers/gpu/drm/i915/display/intel_dp_aux.o
CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
CC drivers/gpu/drm/i915/display/intel_dp_mst.o
CC drivers/gpu/drm/i915/display/intel_dsi.o
CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
CC drivers/gpu/drm/i915/display/intel_dvo.o
CC drivers/gpu/drm/i915/display/intel_gmbus.o
CC drivers/gpu/drm/i915/display/intel_hdmi.o
CC drivers/gpu/drm/i915/display/intel_lspcon.o
CC drivers/gpu/drm/i915/display/intel_lvds.o
CC drivers/gpu/drm/i915/display/intel_panel.o
CC drivers/gpu/drm/i915/display/intel_pps.o
drivers/gpu/drm/i915/display/intel_dp.c: In function
‘intel_write_dp_vsc_sdp’:
drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit declaration
of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
[-Werror=implicit-function-declaration]
4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
| ^
| drm_dp_vsc_sdp_pack
Is this a known issue?
o.O - what a mistery!
it looks that drm-misc-next has only part of the patch:
31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
without the patch itself...
I couldn't even trace back to understand how the declaration is
gone from the drm-misc-next...
Looks like the issue here is that the below patch which landed in
drm-misc-next
https://patchwork.freedesktop.org/patch/579128/?series=130145=1
was based on top of drm-tip because the intel CI runs on drm-tip and not
drm-misc-next.
But, https://patchwork.freedesktop.org/patch/572622/ is not present in
drm-misc-next.
Hence this broke the compilation.
How would you prefer to fix this? We revert
https://patchwork.freedesktop.org/series/130145/ from drm-misc and land it
through i915 tree and can you provide us a tag from the i915 tree to rebase
our msm-next tree on?
The revert from drm-misc is a possibility, then you squash
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
in and merge it again.
or if drm-misc and drm maintainers are okay we can simply add
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
on top of drm-misc-next
I am totally fine with this second option. Have given my R-b.
and on any conflict later the resolution is simply deleting this line
anyway.
-Jeff
Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()
On Fri, 23 Feb 2024 14:50:49 -0500
Kent Overstreet wrote:
> Tangentially related though, what would make me really happy is if we
> could create the string with in the TP__fast_assign() section. I have to
> have a bunch of annoying wrappers right now because the string length
> has to be known when we invoke the tracepoint.
You can use __string_len() to determine the string length in the tracepoint
(which is executed in the TP_fast_assign() section).
My clean up patches will make __assign_str_len() obsolete too (I'm working
on them now), and you can just use __assign_str().
I noticed that I don't have a string_len example in the sample code and I'm
actually writing it now.
// cutting out everything else:
TRACE_EVENT(foo_bar,
TP_PROTO(const char *foo, int bar),
TP_ARGS(foo, bar),
TP_STRUCT__entry(
__string_len( lstr, foo,bar < strlen(foo) ? bar :
strlen(foo) )
),
TP_fast_assign(
__assign_str(lstr, foo);
// Note, the above is with my updates, without them, you need to duplicate the
logic
// __assign_str_len(lstr, foo, bar < strlen(foo) ? bar :
strlen(foo));
),
TP_printk("%s", __get_str(lstr))
);
The above will allocate "bar < strlen(foo) ? bar : strlen(foo)" size on the
ring buffer. As the size is already stored, my clean up code uses that
instead of requiring duplicating the logic again.
-- Steve
Re: [PATCH 07/12] drm/i915: Use drm_printer more extensively in intel_crtc_state_dump()
On Thu, Feb 22, 2024 at 04:57:21PM -0500, Rodrigo Vivi wrote: > On Thu, Feb 15, 2024 at 06:40:50PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Convert all the direct drm_dbg_kms() stuff in intel_crtc_state_dump() > > over to drm_printf() since we now have the drm_printer around. > > looking all this I ask myself if it is really a good idea > to move from the debug helpers to the printf... we need > to keep coming back to where the printer was defined to > know what level we are printing... The debug level is not really interesting at all. And it's all the same anyway. Also we're going to need to go for the printer anyway if we want to hook into the .atomic_state_print() stuff. And at that point the printer will be provided by the caller. -- Ville Syrjälä Intel
Re: [PATCH 06/12] drm/i915: Convert intel_dpll_dump_hw_state() to drm_printer
On Thu, Feb 22, 2024 at 04:54:07PM -0500, Rodrigo Vivi wrote:
> On Thu, Feb 15, 2024 at 06:40:49PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Utilize drm_printer in pipe_config_pll_mismatch() to avoid
> > a bit of code duplication.
> >
> > To achieve this we need to plumb the printer all way to the
> > dpll_mgr .dump_hw_state() functions. Those are also used by
> > intel_crtc_state_dump() which needs to be adjusted as well.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../drm/i915/display/intel_crtc_state_dump.c | 5 +-
> > drivers/gpu/drm/i915/display/intel_display.c | 27 ++---
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 105 --
> > drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 2 +
> > 4 files changed, 67 insertions(+), 72 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> > b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> > index 4bcf446c75f4..59d2b3d39951 100644
> > --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> > +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
> > @@ -205,9 +205,12 @@ void intel_crtc_state_dump(const struct
> > intel_crtc_state *pipe_config,
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > const struct intel_plane_state *plane_state;
> > struct intel_plane *plane;
> > + struct drm_printer p;
> > char buf[64];
> > int i;
> >
> > + p = drm_dbg_printer(>drm, DRM_UT_KMS, NULL);
> > +
> > drm_dbg_kms(>drm, "[CRTC:%d:%s] enable: %s [%s]\n",
> > crtc->base.base.id, crtc->base.name,
> > str_yes_no(pipe_config->hw.enable), context);
> > @@ -356,7 +359,7 @@ void intel_crtc_state_dump(const struct
> > intel_crtc_state *pipe_config,
> > pipe_config->ips_enabled, pipe_config->double_wide,
> > pipe_config->has_drrs);
> >
> > - intel_dpll_dump_hw_state(i915, _config->dpll_hw_state);
> > + intel_dpll_dump_hw_state(i915, , _config->dpll_hw_state);
> >
> > if (IS_CHERRYVIEW(i915))
> > drm_dbg_kms(>drm,
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index e5010049d52e..d7f39ad84138 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -4927,26 +4927,27 @@ pipe_config_pll_mismatch(bool fastset,
> > const struct intel_dpll_hw_state *b)
> > {
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > + struct drm_printer p;
> >
> > if (fastset) {
> > if (!drm_debug_enabled(DRM_UT_KMS))
> > return;
> >
> > - drm_dbg_kms(>drm,
> > - "[CRTC:%d:%s] fastset requirement not met in %s\n",
> > - crtc->base.base.id, crtc->base.name, name);
> > - drm_dbg_kms(>drm, "expected:\n");
> > - intel_dpll_dump_hw_state(i915, a);
> > - drm_dbg_kms(>drm, "found:\n");
> > - intel_dpll_dump_hw_state(i915, b);
> > + p = drm_dbg_printer(>drm, DRM_UT_KMS, NULL);
> > +
> > + drm_printf(, "[CRTC:%d:%s] fastset requirement not met in
> > %s\n",
> > + crtc->base.base.id, crtc->base.name, name);
> > } else {
> > - drm_err(>drm, "[CRTC:%d:%s] mismatch in %s buffer\n",
> > - crtc->base.base.id, crtc->base.name, name);
> > - drm_err(>drm, "expected:\n");
> > - intel_dpll_dump_hw_state(i915, a);
> > - drm_err(>drm, "found:\n");
> > - intel_dpll_dump_hw_state(i915, b);
> > + p = drm_err_printer(>drm, NULL);
> > +
> > + drm_printf(, "[CRTC:%d:%s] mismatch in %s\n",
> > + crtc->base.base.id, crtc->base.name, name);
> > }
> > +
> > + drm_dbg_kms(>drm, "expected:\n");
> > + intel_dpll_dump_hw_state(i915, , a);
> > + drm_dbg_kms(>drm, "found:\n");
> > + intel_dpll_dump_hw_state(i915, , b);
>
> forgot to convert here?
Looks like that part ended up in the last patch. Probably
a rebase fail on my part. I'll shuffle it back over here.
--
Ville Syrjälä
Intel
Re: [PATCH 02/12] drm/i915: Include CRTC info in infoframe mismatch prints
On Thu, Feb 22, 2024 at 04:47:39PM -0500, Rodrigo Vivi wrote:
> On Thu, Feb 15, 2024 at 06:40:45PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Most crtc state mismatches include the CRTC id+name in the
> > prints. Also include it in the infoframe mismatches.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 14 +-
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index a7f487f5c2b2..e3520a3da468 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -4788,23 +4788,27 @@ intel_compare_buffer(const u8 *a, const u8 *b,
> > size_t len)
> > }
> >
> > static void
> > -pipe_config_infoframe_mismatch(struct drm_i915_private *dev_priv,
> > - bool fastset, const char *name,
> > +pipe_config_infoframe_mismatch(bool fastset, const struct intel_crtc *crtc,
>
> why not crtc, fastset? having the main struct as the first
> argument seems more natural imho
Consistency. This order was already used by some other
mismatch() functions. So if we want to reorder we should
change all of them.
>
> anyway,
>
> Reviewed-by: Rodrigo Vivi
>
> > + const char *name,
> >const union hdmi_infoframe *a,
> >const union hdmi_infoframe *b)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +
> > if (fastset) {
> > if (!drm_debug_enabled(DRM_UT_KMS))
> > return;
> >
> > drm_dbg_kms(_priv->drm,
> > - "fastset requirement not met in %s infoframe\n",
> > name);
> > + "[CRTC:%d:%s] fastset requirement not met in %s
> > infoframe\n",
> > + crtc->base.base.id, crtc->base.name, name);
> > drm_dbg_kms(_priv->drm, "expected:\n");
> > hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, a);
> > drm_dbg_kms(_priv->drm, "found:\n");
> > hdmi_infoframe_log(KERN_DEBUG, dev_priv->drm.dev, b);
> > } else {
> > - drm_err(_priv->drm, "mismatch in %s infoframe\n", name);
> > + drm_err(_priv->drm, "[CRTC:%d:%s] mismatch in %s
> > infoframe\n",
> > + crtc->base.base.id, crtc->base.name, name);
> > drm_err(_priv->drm, "expected:\n");
> > hdmi_infoframe_log(KERN_ERR, dev_priv->drm.dev, a);
> > drm_err(_priv->drm, "found:\n");
> > @@ -5072,7 +5076,7 @@ intel_pipe_config_compare(const struct
> > intel_crtc_state *current_config,
> > #define PIPE_CONF_CHECK_INFOFRAME(name) do { \
> > if (!intel_compare_infoframe(_config->infoframes.name, \
> > _config->infoframes.name)) { \
> > - pipe_config_infoframe_mismatch(dev_priv, fastset,
> > __stringify(name), \
> > + pipe_config_infoframe_mismatch(fastset, crtc,
> > __stringify(name), \
> >
> > _config->infoframes.name, \
> >_config->infoframes.name); \
> > ret = false; \
> > --
> > 2.43.0
> >
--
Ville Syrjälä
Intel
Re: [PATCH 01/12] drm/i915: Indicate which pipe failed the fastset check overall
On Thu, Feb 22, 2024 at 04:46:12PM -0500, Rodrigo Vivi wrote:
> On Thu, Feb 15, 2024 at 06:40:44PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > intel_crtc_check_fastset() is done per-pipe, so it would be nice
> > to know which pipe it was that failed its checkup.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 00ac65a14029..a7f487f5c2b2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -5562,14 +5562,16 @@ static int intel_modeset_checks(struct
> > intel_atomic_state *state)
> > static void intel_crtc_check_fastset(const struct intel_crtc_state
> > *old_crtc_state,
> > struct intel_crtc_state *new_crtc_state)
> > {
> > - struct drm_i915_private *i915 = to_i915(old_crtc_state->uapi.crtc->dev);
> > + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> >
> > /* only allow LRR when the timings stay within the VRR range */
> > if (old_crtc_state->vrr.in_range != new_crtc_state->vrr.in_range)
> > new_crtc_state->update_lrr = false;
> >
> > if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state, true))
> > - drm_dbg_kms(>drm, "fastset requirement not met, forcing
> > full modeset\n");
> > + drm_dbg_kms(>drm, "[CRTC:%d:%s] fastset requirement not
> > met, forcing full modeset\n",
> > + crtc->base.base.id, crtc->base.name);
>
> looking to other patches in this same series, I wonder
> if we shouldn't benefit of a crct_dbg(crtc, "message") that would print
> [CRTC:%d:%s] underneath.
There has been some discussion on this topic recently, but
I don't think that particular approach is good because:
a) it only works when you need to talk about one partiuclar
object and often we need to talk about more than one
b) different debug function for every little thing is just ugly,
and we'd probably end up with dozens of differently named
variants which takes up too many slots in my brain's pattern
matcher
I think Jani proposed that drm_dbg_kms() could take different kinds
of objects as its first parameter to do this, but I don't like that
either because of point a).
One idea that was floating about was that each object would embed
a .debug_string or somesuch thing which would include the preferred
formatting. With that you could prints with just a simple %s. The
downside is that when you then read the format string you have no
idea what kind of thing each %s refers to unless you also parse
the full argument list to figure out which is which.
And one basic idea I was mulling over at some point was simply
to define DRM_CRTC_FMT/ARGS/etc. macros and use those. But that
makes the format string super ugly and hard to read.
I think the proper solution would be to have actually
sensible conversion specifiers in the format string.
So instead of % we'd have something
more like %{drm_crtc} (or whatever color you want to throw
on that particular bikeshed).
Adding vsprintf.c folks to cc in case they have some ideas...
--
Ville Syrjälä
Intel
Re: i915 build error on drm-misc-next
On Fri, Feb 23, 2024 at 09:47:11AM -0800, Abhinav Kumar wrote:
> CC Dmitry
>
> Hi Rodrigo
>
> On 2/23/2024 9:00 AM, Rodrigo Vivi wrote:
> > On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
> > > With the x86_64_defconfig I see the following when building drm-misc-next:
> > >
> > >CC drivers/gpu/drm/i915/display/intel_crt.o
> > >CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
> > >CC drivers/gpu/drm/i915/display/intel_ddi.o
> > >CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
> > >CC drivers/gpu/drm/i915/display/intel_display_device.o
> > >CC drivers/gpu/drm/i915/display/intel_display_trace.o
> > >CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
> > >CC drivers/gpu/drm/i915/display/intel_dp.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_aux.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
> > >CC drivers/gpu/drm/i915/display/intel_dp_mst.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
> > >CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
> > >CC drivers/gpu/drm/i915/display/intel_dvo.o
> > >CC drivers/gpu/drm/i915/display/intel_gmbus.o
> > >CC drivers/gpu/drm/i915/display/intel_hdmi.o
> > >CC drivers/gpu/drm/i915/display/intel_lspcon.o
> > >CC drivers/gpu/drm/i915/display/intel_lvds.o
> > >CC drivers/gpu/drm/i915/display/intel_panel.o
> > >CC drivers/gpu/drm/i915/display/intel_pps.o
> > > drivers/gpu/drm/i915/display/intel_dp.c: In function
> > > ‘intel_write_dp_vsc_sdp’:
> > > drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit
> > > declaration
> > > of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
> > > [-Werror=implicit-function-declaration]
> > > 4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> > >| ^
> > >| drm_dp_vsc_sdp_pack
> > >
> > > Is this a known issue?
> >
> > o.O - what a mistery!
> >
> > it looks that drm-misc-next has only part of the patch:
> > 31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
> >
> > without the patch itself...
> >
> > I couldn't even trace back to understand how the declaration is
> > gone from the drm-misc-next...
> >
>
> Looks like the issue here is that the below patch which landed in
> drm-misc-next
>
> https://patchwork.freedesktop.org/patch/579128/?series=130145=1
>
> was based on top of drm-tip because the intel CI runs on drm-tip and not
> drm-misc-next.
>
> But, https://patchwork.freedesktop.org/patch/572622/ is not present in
> drm-misc-next.
>
> Hence this broke the compilation.
>
> How would you prefer to fix this? We revert
> https://patchwork.freedesktop.org/series/130145/ from drm-misc and land it
> through i915 tree and can you provide us a tag from the i915 tree to rebase
> our msm-next tree on?
The revert from drm-misc is a possibility, then you squash
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
in and merge it again.
or if drm-misc and drm maintainers are okay we can simply add
https://lore.kernel.org/all/20240223191548.392185-1-rodrigo.v...@intel.com/
on top of drm-misc-next
and on any conflict later the resolution is simply deleting this line
anyway.
>
> > >
> > > -Jeff
Re: [PATCH] drm/i915/guc: Add Compute context hint
On Fri, Feb 23, 2024 at 10:31:41AM -0800, Belgaumkar, Vinay wrote:
>
> On 2/23/2024 12:51 AM, Tvrtko Ursulin wrote:
> >
> > On 22/02/2024 23:31, Belgaumkar, Vinay wrote:
> > >
> > > On 2/22/2024 7:32 AM, Tvrtko Ursulin wrote:
> > > >
> > > > On 21/02/2024 21:28, Rodrigo Vivi wrote:
> > > > > On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
> > > > > >
> > > > > > On 21/02/2024 00:14, Vinay Belgaumkar wrote:
> > > > > > > Allow user to provide a context hint. When this is set, KMD will
> > > > > > > send a hint to GuC which results in special handling for this
> > > > > > > context. SLPC will ramp the GT frequency aggressively every time
> > > > > > > it switches to this context. The down freq threshold will also be
> > > > > > > lower so GuC will ramp down the GT freq for this
> > > > > > > context more slowly.
> > > > > > > We also disable waitboost for this context as that
> > > > > > > will interfere with
> > > > > > > the strategy.
> > > > > > >
> > > > > > > We need to enable the use of Compute strategy during SLPC init,
> > > > > > > but
> > > > > > > it will apply only to contexts that set this bit during context
> > > > > > > creation.
> > > > > > >
> > > > > > > Userland can check whether this feature is supported
> > > > > > > using a new param-
> > > > > > > I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true
> > > > > > > for all guc submission
> > > > > > > enabled platforms since they use SLPC for freq management.
> > > > > > >
> > > > > > > The Mesa usage model for this flag is here -
> > > > > > > https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
> > > > > >
> > > > > > This allows for setting it for the whole application,
> > > > > > correct? Upsides,
> > > > > > downsides? Are there any plans for per context?
> > > > >
> > > > > Currently there's no extension on a high level API
> > > > > (Vulkan/OpenGL/OpenCL/etc)
> > > > > that would allow the application to hint for
> > > > > power/freq/latency. So Mesa cannot
> > > > > decide when to hint. So their solution was to use .drirc and
> > > > > make per-application
> > > > > decision.
> > > > >
> > > > > I would prefer a high level extension for a more granular
> > > > > and informative
> > > > > decision. We need to work with that goal, but for now I don't see any
> > > > > cons on this approach.
> > > >
> > > > In principle yeah I doesn't harm to have the option. I am just
> > > > not sure how useful this intermediate step this is with its lack
> > > > of intra-process granularity.
> > > >
> > > > > > > Cc: Rodrigo Vivi
> > > > > > > Signed-off-by: Vinay Belgaumkar
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
> > > > > > > .../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
> > > > > > > drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
> > > > > > > .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h |
> > > > > > > 21 +++
> > > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c |
> > > > > > > 17 +++
> > > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
> > > > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
> > > > > > > drivers/gpu/drm/i915/i915_getparam.c | 11 ++
> > > > > > > include/uapi/drm/i915_drm.h | 15
> > > > > > > +
> > > > > > > 9 files changed, 89 insertions(+)
> > > > > > >
> > > > > > > diff --git
> > > > > > > a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > > > index dcbfe32fd30c..ceab7dbe9b47 100644
> > > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > > > @@ -879,6 +879,7 @@ static int
> > > > > > > set_proto_ctx_param(struct drm_i915_file_private
> > > > > > > *fpriv,
> > > > > > > struct i915_gem_proto_context *pc,
> > > > > > > struct drm_i915_gem_context_param *args)
> > > > > > > {
> > > > > > > + struct drm_i915_private *i915 = fpriv->i915;
> > > > > > > int ret = 0;
> > > > > > > switch (args->param) {
> > > > > > > @@ -904,6 +905,13 @@ static int
> > > > > > > set_proto_ctx_param(struct drm_i915_file_private
> > > > > > > *fpriv,
> > > > > > > pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
> > > > > > > break;
> > > > > > > + case I915_CONTEXT_PARAM_IS_COMPUTE:
> > > > > > > + if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
> > > > > > > + ret = -EINVAL;
> > > > > > > + else
> > > > > > > + pc->user_flags |= BIT(UCONTEXT_COMPUTE);
> > > > > > > + break;
> > > > > > > +
> > > > > > > case I915_CONTEXT_PARAM_RECOVERABLE:
> > > > > > > if (args->size)
> > > > > > > ret = -EINVAL;
> > > > > > > diff --git
> > > > > > >
Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()
On Fri, 23 Feb 2024 10:30:45 -0800 Jeff Johnson wrote: > On 2/23/2024 9:56 AM, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > [ > >This is a treewide change. I will likely re-create this patch again in > >the second week of the merge window of v6.9 and submit it then. Hoping > >to keep the conflicts that it will cause to a minimum. > > ] > > > > With the rework of how the __string() handles dynamic strings where it > > saves off the source string in field in the helper structure[1], the > > assignment of that value to the trace event field is stored in the helper > > value and does not need to be passed in again. > > Just curious if this could be done piecemeal by first changing the > macros to be variadic macros which allows you to ignore the extra > argument. The callers could then be modified in their separate trees. > And then once all the callers have be merged, the macros could be > changed to no longer be variadic. I weighed doing that, but I think ripping off the band-aid is a better approach. One thing I found is that leaving unused parameters in the macros can cause bugs itself. I found one case doing my clean up, where an unused parameter in one of the macros was bogus, and when I made it a used parameter, it broke the build. I think for tree-wide changes, the preferred approach is to do one big patch at once. And since this only affects TRACE_EVENT() macros, it hopefully would not be too much of a burden (although out of tree users may suffer from this, but do we care?) Now one thing I could do is to not remove the parameter, but just add: WARN_ON_ONCE((src) != __data_offsets->item##_ptr_); in the __assign_str() macro to make sure that it's still the same that is assigned. But I'm not sure how useful that is, and still causes burden to have it. I never really liked the passing of the string in two places to begin with. -- Steve
Re: [PATCH] drm/i915/guc: Add Compute context hint
On 2/23/2024 12:51 AM, Tvrtko Ursulin wrote:
On 22/02/2024 23:31, Belgaumkar, Vinay wrote:
On 2/22/2024 7:32 AM, Tvrtko Ursulin wrote:
On 21/02/2024 21:28, Rodrigo Vivi wrote:
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Vinay Belgaumkar wrote:
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq for this context more
slowly.
We also disable waitboost for this context as that will interfere
with
the strategy.
We need to enable the use of Compute strategy during SLPC init, but
it will apply only to contexts that set this bit during context
creation.
Userland can check whether this feature is supported using a new
param-
I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc
submission
enabled platforms since they use SLPC for freq management.
The Mesa usage model for this flag is here -
https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
This allows for setting it for the whole application, correct?
Upsides,
downsides? Are there any plans for per context?
Currently there's no extension on a high level API
(Vulkan/OpenGL/OpenCL/etc)
that would allow the application to hint for power/freq/latency. So
Mesa cannot
decide when to hint. So their solution was to use .drirc and make
per-application
decision.
I would prefer a high level extension for a more granular and
informative
decision. We need to work with that goal, but for now I don't see any
cons on this approach.
In principle yeah I doesn't harm to have the option. I am just not
sure how useful this intermediate step this is with its lack of
intra-process granularity.
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21
+++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17
+++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
drivers/gpu/drm/i915/i915_getparam.c | 11 ++
include/uapi/drm/i915_drm.h | 15 +
9 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..ceab7dbe9b47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
struct i915_gem_proto_context *pc,
struct drm_i915_gem_context_param *args)
{
+ struct drm_i915_private *i915 = fpriv->i915;
int ret = 0;
switch (args->param) {
@@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
break;
+ case I915_CONTEXT_PARAM_IS_COMPUTE:
+ if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
+ ret = -EINVAL;
+ else
+ pc->user_flags |= BIT(UCONTEXT_COMPUTE);
+ break;
+
case I915_CONTEXT_PARAM_RECOVERABLE:
if (args->size)
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 03bc7f9d191b..db86d6f6245f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -338,6 +338,7 @@ struct i915_gem_context {
#define UCONTEXT_BANNABLE 2
#define UCONTEXT_RECOVERABLE 3
#define UCONTEXT_PERSISTENCE 4
+#define UCONTEXT_COMPUTE 5
What is the GuC behaviour when SLPC_CTX_FREQ_REQ_IS_COMPUTE is set
for
non-compute engines? Wondering if per intel_context is what we
want instead.
(Which could then be the i915_context_param_engines extension to mark
individual contexts as compute strategy.)
Perhaps we should rename this? This is a freq-decision-strategy inside
GuC that is there mostly targeting compute workloads that needs lower
latency with short burst execution. But the engine itself doesn't
matter.
It can be applied to any engine.
I have no idea if it makes sense for other engines, such as video,
and what would be pros and cons in terms of PnP. But in the case we
end up allowing it on any engine, then at least userspace name
shouldn't be compute. :)
Yes, one of the suggestions from Daniele was to have something along
the lines of UCONTEXT_HIFREQ or something along those lines so we
don't confuse it with the Compute
✗ Fi.CI.BUILD: failure for tracing/treewide: Remove second parameter of __assign_str()
== Series Details == Series: tracing/treewide: Remove second parameter of __assign_str() URL : https://patchwork.freedesktop.org/series/130320/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/130320/revisions/1/mbox/ not applied Applying: tracing/treewide: Remove second parameter of __assign_str() error: sha1 information is lacking or useless (fs/nfsd/trace.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 tracing/treewide: Remove second parameter of __assign_str() 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". Build failed, no error log produced
Re: [FYI][PATCH] tracing/treewide: Remove second parameter of __assign_str()
On Fri, 23 Feb 2024 12:56:34 -0500 Steven Rostedt wrote: > Note, the same updates will need to be done for: > > __assign_str_len() > __assign_rel_str() > __assign_rel_str_len() Correction: The below macros do not pass in their source to the entry macros, so they will not need to be updated. -- Steve > __assign_bitmask() > __assign_rel_bitmask() > __assign_cpumask() > __assign_rel_cpumask()
✓ Fi.CI.BAT: success for drm/i915/display: Save a few bytes of memory in intel_backlight_device_register()
== Series Details == Series: drm/i915/display: Save a few bytes of memory in intel_backlight_device_register() URL : https://patchwork.freedesktop.org/series/130319/ State : success == Summary == CI Bug Log - changes from CI_DRM_14328 -> Patchwork_130319v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130319v1/index.html Participating hosts (37 -> 35) -- Missing(2): fi-snb-2520m bat-arls-3 Known issues Here are the changes found in Patchwork_130319v1 that come from known issues: ### IGT changes ### Warnings * igt@i915_selftest@live@memory_region: - bat-arls-2: [DMESG-WARN][1] ([i915#10194]) -> [ABORT][2] ([i915#10194]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14328/bat-arls-2/igt@i915_selftest@live@memory_region.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130319v1/bat-arls-2/igt@i915_selftest@live@memory_region.html [i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194 Build changes - * Linux: CI_DRM_14328 -> Patchwork_130319v1 CI-20190529: 20190529 CI_DRM_14328: aed3f498154b240f09098da53b8fd5639ee54ecf @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7729: 7729 Patchwork_130319v1: aed3f498154b240f09098da53b8fd5639ee54ecf @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits ae6b78ecab42 drm/i915/display: Save a few bytes of memory in intel_backlight_device_register() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130319v1/index.html
Re: i915 build error on drm-misc-next
CC Dmitry
Hi Rodrigo
On 2/23/2024 9:00 AM, Rodrigo Vivi wrote:
On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
With the x86_64_defconfig I see the following when building drm-misc-next:
CC drivers/gpu/drm/i915/display/intel_crt.o
CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
CC drivers/gpu/drm/i915/display/intel_ddi.o
CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
CC drivers/gpu/drm/i915/display/intel_display_device.o
CC drivers/gpu/drm/i915/display/intel_display_trace.o
CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
CC drivers/gpu/drm/i915/display/intel_dp.o
CC drivers/gpu/drm/i915/display/intel_dp_aux.o
CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
CC drivers/gpu/drm/i915/display/intel_dp_mst.o
CC drivers/gpu/drm/i915/display/intel_dsi.o
CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
CC drivers/gpu/drm/i915/display/intel_dvo.o
CC drivers/gpu/drm/i915/display/intel_gmbus.o
CC drivers/gpu/drm/i915/display/intel_hdmi.o
CC drivers/gpu/drm/i915/display/intel_lspcon.o
CC drivers/gpu/drm/i915/display/intel_lvds.o
CC drivers/gpu/drm/i915/display/intel_panel.o
CC drivers/gpu/drm/i915/display/intel_pps.o
drivers/gpu/drm/i915/display/intel_dp.c: In function
‘intel_write_dp_vsc_sdp’:
drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit declaration
of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
[-Werror=implicit-function-declaration]
4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
| ^
| drm_dp_vsc_sdp_pack
Is this a known issue?
o.O - what a mistery!
it looks that drm-misc-next has only part of the patch:
31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
without the patch itself...
I couldn't even trace back to understand how the declaration is
gone from the drm-misc-next...
Looks like the issue here is that the below patch which landed in
drm-misc-next
https://patchwork.freedesktop.org/patch/579128/?series=130145=1
was based on top of drm-tip because the intel CI runs on drm-tip and not
drm-misc-next.
But, https://patchwork.freedesktop.org/patch/572622/ is not present in
drm-misc-next.
Hence this broke the compilation.
How would you prefer to fix this? We revert
https://patchwork.freedesktop.org/series/130145/ from drm-misc and land
it through i915 tree and can you provide us a tag from the i915 tree to
rebase our msm-next tree on?
-Jeff
[PATCH] drm/i915/display: Save a few bytes of memory in intel_backlight_device_register()
'name' may still be "intel_backlight" when backlight_device_register() is
called.
In such a case, using kstrdup_const() saves a memory duplication when
dev_set_name() is called in backlight_device_register().
Use kfree_const() accordingly.
Signed-off-by: Christophe JAILLET
---
Compile tested only
---
drivers/gpu/drm/i915/display/intel_backlight.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 1946d7fb3c2e..9e4a9d4f1585 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -949,7 +949,7 @@ int intel_backlight_device_register(struct intel_connector
*connector)
else
props.power = FB_BLANK_POWERDOWN;
- name = kstrdup("intel_backlight", GFP_KERNEL);
+ name = kstrdup_const("intel_backlight", GFP_KERNEL);
if (!name)
return -ENOMEM;
@@ -963,7 +963,7 @@ int intel_backlight_device_register(struct intel_connector
*connector)
* compatibility. Use unique names for subsequent backlight
devices as a
* fallback when the default name already exists.
*/
- kfree(name);
+ kfree_const(name);
name = kasprintf(GFP_KERNEL, "card%d-%s-backlight",
i915->drm.primary->index,
connector->base.name);
if (!name)
@@ -987,7 +987,7 @@ int intel_backlight_device_register(struct intel_connector
*connector)
connector->base.base.id, connector->base.name, name);
out:
- kfree(name);
+ kfree_const(name);
return ret;
}
--
2.43.2
Re: [PATCH v2 2/4] ASoC: codecs: hda: Skip HDMI/DP registration if i915 is missing
On 2024-02-23 3:44 PM, Takashi Iwai wrote:
On Fri, 23 Feb 2024 12:46:24 +0100,
Cezary Rojewski wrote:
If i915 does not support given platform but the hardware i.e.: HDAudio
codec is still there, the codec-probing procedure will succeed for such
device but the follow up initialization will always end up with -ENODEV.
While bus could filter out address '2' which Intel's HDMI/DP codecs
always enumerate on, more robust approach is to check for i915 presence
before registering display codecs.
Signed-off-by: Cezary Rojewski
---
sound/soc/codecs/hda.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/sound/soc/codecs/hda.c b/sound/soc/codecs/hda.c
index d2117e36ddd1..d9e7cd8aada2 100644
--- a/sound/soc/codecs/hda.c
+++ b/sound/soc/codecs/hda.c
@@ -350,6 +350,11 @@ static int hda_hdev_attach(struct hdac_device *hdev)
struct hda_codec *codec = dev_to_hda_codec(>dev);
struct snd_soc_component_driver *comp_drv;
+ if (hda_codec_is_display(codec) && !hdev->bus->audio_component) {
+ dev_dbg(>dev, "no i915, skip registration for 0x%08x\n",
hdev->vendor_id);
+ return 0;
Should we return success here, or would it better with -ENODEV?
IIUC, the code path is from the early hda_codec_driver_probe() hook,
so returning an error can work.
Good suggestion. Indeed attach() is called by probe() which treats
-ENODEV just fine.
There is a consequence to that though. Logs from LKF show:
snd_soc_hda_codec:hda_hdev_attach: snd_hda_codec_hdmi hdaudioB0D2: no
i915, skip registration for 0x80862811
snd_soc_hda_codec:hda_hdev_attach: snd_hda_codec_generic hdaudioB0D2: no
i915, skip registration for 0x80862811
snd_soc_hda_codec:hda_hdev_attach: snd_hda_codec_generic hdaudioB0D2: no
i915, skip registration for 0x80862811
snd_hda_codec:snd_hda_codec_configure: hdaudio hdaudioB0D2: Unable to
bind the codec
snd_soc_avs :00:1f.3: failed to config codec -19
snd_soc_avs :00:1f.3: Codec #2 probe error; disabling it...
i.e.: three attempts. One for HDMI via codec_bind_module() and two from
codec_bind_generic(). Situation on CNL-based is different - two logs, no
error. The reason for this is lack of codec->preset in LKF case.
Should I add stub entries for ICL-HP/LKF to patch_hdmi.c to address this?
HDA_CODEC_ENTRY(0x80862810, "Icelake-P HDMI", NULL),
HDA_CODEC_ENTRY(0x80862811, "Lakefield HDMI", NULL),
Czarek
Re: i915 build error on drm-misc-next
On Fri, Feb 23, 2024 at 08:50:06AM -0700, Jeffrey Hugo wrote:
> With the x86_64_defconfig I see the following when building drm-misc-next:
>
> CC drivers/gpu/drm/i915/display/intel_crt.o
> CC drivers/gpu/drm/i915/display/intel_cx0_phy.o
> CC drivers/gpu/drm/i915/display/intel_ddi.o
> CC drivers/gpu/drm/i915/display/intel_ddi_buf_trans.o
> CC drivers/gpu/drm/i915/display/intel_display_device.o
> CC drivers/gpu/drm/i915/display/intel_display_trace.o
> CC drivers/gpu/drm/i915/display/intel_dkl_phy.o
> CC drivers/gpu/drm/i915/display/intel_dp.o
> CC drivers/gpu/drm/i915/display/intel_dp_aux.o
> CC drivers/gpu/drm/i915/display/intel_dp_aux_backlight.o
> CC drivers/gpu/drm/i915/display/intel_dp_hdcp.o
> CC drivers/gpu/drm/i915/display/intel_dp_link_training.o
> CC drivers/gpu/drm/i915/display/intel_dp_mst.o
> CC drivers/gpu/drm/i915/display/intel_dsi.o
> CC drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.o
> CC drivers/gpu/drm/i915/display/intel_dsi_vbt.o
> CC drivers/gpu/drm/i915/display/intel_dvo.o
> CC drivers/gpu/drm/i915/display/intel_gmbus.o
> CC drivers/gpu/drm/i915/display/intel_hdmi.o
> CC drivers/gpu/drm/i915/display/intel_lspcon.o
> CC drivers/gpu/drm/i915/display/intel_lvds.o
> CC drivers/gpu/drm/i915/display/intel_panel.o
> CC drivers/gpu/drm/i915/display/intel_pps.o
> drivers/gpu/drm/i915/display/intel_dp.c: In function
> ‘intel_write_dp_vsc_sdp’:
> drivers/gpu/drm/i915/display/intel_dp.c:4232:15: error: implicit declaration
> of function ‘intel_dp_vsc_sdp_pack’; did you mean ‘drm_dp_vsc_sdp_pack’?
> [-Werror=implicit-function-declaration]
> 4232 | len = intel_dp_vsc_sdp_pack(vsc, , sizeof(sdp));
> | ^
> | drm_dp_vsc_sdp_pack
>
> Is this a known issue?
o.O - what a mistery!
it looks that drm-misc-next has only part of the patch:
31a5b6ed88c7 ("drm/i915/display: Unify VSC SPD preparation")
without the patch itself...
I couldn't even trace back to understand how the declaration is
gone from the drm-misc-next...
>
> -Jeff
✓ Fi.CI.IGT: success for drm/i915: Add missing ; to __assign_str() macros in tracepoint code
== Series Details ==
Series: drm/i915: Add missing ; to __assign_str() macros in tracepoint code
URL : https://patchwork.freedesktop.org/series/130279/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14322_full -> Patchwork_130279v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_130279v1_full:
### IGT changes ###
Possible regressions
* {igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-rc-ccs@pipe-d-hdmi-a-2}
(NEW):
- shard-dg2: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-dg2-2/igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-rc-...@pipe-d-hdmi-a-2.html
New tests
-
New tests have been introduced between CI_DRM_14322_full and
Patchwork_130279v1_full:
### New IGT tests (1) ###
* igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-rc-ccs@pipe-d-hdmi-a-2:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_130279v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-glk: ([PASS][2], [PASS][3], [PASS][4], [PASS][5],
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [FAIL][22]) ([i915#8293]) -> ([PASS][23],
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41],
[PASS][42], [PASS][43], [PASS][44])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk9/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk9/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk9/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk8/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk8/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk8/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk8/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk5/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk5/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk5/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk4/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk4/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk4/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk4/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk3/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk3/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk3/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-glk1/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk2/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk9/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk9/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk9/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk8/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk8/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk8/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk7/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130279v1/shard-glk7/boot.html
[36]:
✓ Fi.CI.IGT: success for drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector()
== Series Details ==
Series: drm/i915/panelreplay: Move out psr_init_dpcd() from init_connector()
URL : https://patchwork.freedesktop.org/series/130276/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14322_full -> Patchwork_130276v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/index.html
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_130276v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@crc-primary-rotation-180-4-tiled-mtl-mc-ccs@pipe-d-hdmi-a-2}:
- shard-dg2: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg2-2/igt@kms_ccs@crc-primary-rotation-180-4-tiled-mtl-mc-...@pipe-d-hdmi-a-2.html
Known issues
Here are the changes found in Patchwork_130276v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- shard-rkl: NOTRUN -> [SKIP][2] ([i915#9318])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-rkl-4/igt@debugfs_t...@basic-hwmon.html
* igt@drm_fdinfo@all-busy-idle-check-all:
- shard-dg1: NOTRUN -> [SKIP][3] ([i915#8414])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg1-12/igt@drm_fdi...@all-busy-idle-check-all.html
* igt@drm_fdinfo@isolation@vcs1:
- shard-dg2: NOTRUN -> [SKIP][4] ([i915#8414]) +10 other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg2-5/igt@drm_fdinfo@isolat...@vcs1.html
* igt@gem_busy@semaphore:
- shard-dg2: NOTRUN -> [SKIP][5] ([i915#3936])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg2-5/igt@gem_b...@semaphore.html
* igt@gem_ccs@block-copy-compressed:
- shard-rkl: NOTRUN -> [SKIP][6] ([i915#3555] / [i915#9323])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-rkl-1/igt@gem_...@block-copy-compressed.html
* igt@gem_ccs@ctrl-surf-copy-new-ctx:
- shard-rkl: NOTRUN -> [SKIP][7] ([i915#9323])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-rkl-4/igt@gem_...@ctrl-surf-copy-new-ctx.html
* igt@gem_ccs@suspend-resume@linear-compressed-compfmt0-lmem0-lmem0:
- shard-dg2: [PASS][8] -> [INCOMPLETE][9] ([i915#7297])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-dg2-1/igt@gem_ccs@suspend-res...@linear-compressed-compfmt0-lmem0-lmem0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg2-10/igt@gem_ccs@suspend-res...@linear-compressed-compfmt0-lmem0-lmem0.html
* igt@gem_eio@hibernate:
- shard-dg2: NOTRUN -> [ABORT][10] ([i915#10030] / [i915#7975] /
[i915#8213])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg2-2/igt@gem_...@hibernate.html
* igt@gem_exec_fair@basic-deadline:
- shard-rkl: [PASS][11] -> [FAIL][12] ([i915#2846])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-rkl-5/igt@gem_exec_f...@basic-deadline.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-rkl-5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none:
- shard-dg2: NOTRUN -> [SKIP][13] ([i915#3539] / [i915#4852]) +2
other tests skip
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg2-7/igt@gem_exec_f...@basic-none.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-tglu: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14322/shard-tglu-6/igt@gem_exec_fair@basic-p...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-tglu-8/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_params@secure-non-master:
- shard-rkl: NOTRUN -> [SKIP][16] ([fdo#112283])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-rkl-4/igt@gem_exec_par...@secure-non-master.html
* igt@gem_exec_params@secure-non-root:
- shard-dg2: NOTRUN -> [SKIP][17] ([fdo#112283])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-dg2-7/igt@gem_exec_par...@secure-non-root.html
* igt@gem_exec_reloc@basic-softpin:
- shard-rkl: NOTRUN -> [SKIP][18] ([i915#3281]) +2 other tests skip
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130276v1/shard-rkl-4/igt@gem_exec_re...@basic-softpin.html
* igt@gem_exec_reloc@basic-write-cpu:
- shard-dg2: NOTRUN ->
Re: [PATCH v2 0/4] ALSA/ASoC: Conditionally skip i915 init and cleanups
On Fri, 23 Feb 2024 12:46:22 +0100,
Cezary Rojewski wrote:
>
> A small set of changes to improve initialization of the audio stack on
> HDAudio devices and pair of cleanups.
>
> As the first change is the most important one here, following is the
> technical background for it:
>
> Commit 78f613ba1efb ("drm/i915: finish removal of CNL") and its friends
> removed support for i915 for all CNL-based platforms. HDAudio library,
> however, still treats such platforms as valid candidates for i915
> binding. Update query mechanism to reflect changes made in drm tree.
>
> At the same time, i915 support for LKF-based platforms has not been
> provided so remove them from valid binding candidates.
>
> The snd_soc_hda change is a follow up for the above and the cleanup
> patches do not bring any functional changes.
>
> Changes in v2:
> - list of problematic VGA devices is now declared locally, no more
> touching drm stuff
>
> Cezary Rojewski (4):
> ALSA: hda: Skip i915 initialization on CNL/LKF-based platforms
> ASoC: codecs: hda: Skip HDMI/DP registration if i915 is missing
> ASoC: codecs: hda: Cleanup error messages
> ALSA: hda: Reuse for_each_pcm_streams()
As far as I see, all those 4 patches are rather individually
applicable, right?
The essential change is the first patch, and the patch 2 is rather an
improvement (the driver gives -ENODEV as of now).
And the rest two are merely cleanups.
Takashi
Re: [PATCH v2 2/4] ASoC: codecs: hda: Skip HDMI/DP registration if i915 is missing
On Fri, 23 Feb 2024 12:46:24 +0100,
Cezary Rojewski wrote:
>
> If i915 does not support given platform but the hardware i.e.: HDAudio
> codec is still there, the codec-probing procedure will succeed for such
> device but the follow up initialization will always end up with -ENODEV.
>
> While bus could filter out address '2' which Intel's HDMI/DP codecs
> always enumerate on, more robust approach is to check for i915 presence
> before registering display codecs.
>
> Signed-off-by: Cezary Rojewski
> ---
> sound/soc/codecs/hda.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/sound/soc/codecs/hda.c b/sound/soc/codecs/hda.c
> index d2117e36ddd1..d9e7cd8aada2 100644
> --- a/sound/soc/codecs/hda.c
> +++ b/sound/soc/codecs/hda.c
> @@ -350,6 +350,11 @@ static int hda_hdev_attach(struct hdac_device *hdev)
> struct hda_codec *codec = dev_to_hda_codec(>dev);
> struct snd_soc_component_driver *comp_drv;
>
> + if (hda_codec_is_display(codec) && !hdev->bus->audio_component) {
> + dev_dbg(>dev, "no i915, skip registration for 0x%08x\n",
> hdev->vendor_id);
> + return 0;
Should we return success here, or would it better with -ENODEV?
IIUC, the code path is from the early hda_codec_driver_probe() hook,
so returning an error can work.
Takashi
Re: [PATCH v2 02/21] drm/dp: Add support for DP tunneling
On Fri, Feb 23, 2024 at 08:25:38AM +0200, Shankar, Uma wrote:
> [...]
> > diff --git a/drivers/gpu/drm/display/Kconfig
> > b/drivers/gpu/drm/display/Kconfig
> > index 09712b88a5b83..c0f56888c3280 100644
> > --- a/drivers/gpu/drm/display/Kconfig
> > +++ b/drivers/gpu/drm/display/Kconfig
> [...]
> > +struct drm_dp_tunnel {
> > + struct drm_dp_tunnel_group *group;
> > +
> > + struct list_head node;
> > +
> > + struct kref kref;
> > + struct ref_tracker *tracker;
> > + struct drm_dp_aux *aux;
> > + char name[8];
> > +
> > + int bw_granularity;
> > + int estimated_bw;
> > + int allocated_bw;
> > +
> > + int max_dprx_rate;
> > + u8 max_dprx_lane_count;
> > +
> > + u8 adapter_id;
> > +
> > + bool bw_alloc_supported:1;
> > + bool bw_alloc_enabled:1;
> > + bool has_io_error:1;
> > + bool destroyed:1;
> > +};
> > +
> > +struct drm_dp_tunnel_group_state;
> > +
> > +struct drm_dp_tunnel_state {
> > + struct drm_dp_tunnel_group_state *group_state;
> > +
> > + struct drm_dp_tunnel_ref tunnel_ref;
> > +
> > + struct list_head node;
> > +
> > + u32 stream_mask;
> > + int *stream_bw;
> > +};
> > +
> > +struct drm_dp_tunnel_group_state {
> > + struct drm_private_state base;
> > +
> > + struct list_head tunnel_states;
> > +};
> > +
> > +struct drm_dp_tunnel_group {
> > + struct drm_private_obj base;
> > + struct drm_dp_tunnel_mgr *mgr;
> > +
> > + struct list_head tunnels;
> > +
> > + /* available BW including the allocated_bw of all tunnels in the
> > group */
> > + int available_bw;
> > + u8 drv_group_id;
> > +
> > + char name[8];
> > +
>
> We can drop these line gaps.
Those are used in general to keep related fields together, but the above
three fields could be better grouped, can do that.
> > + bool active:1;
> > +};
> > +
> > +struct drm_dp_tunnel_mgr {
> > + struct drm_device *dev;
> > +
> > + int group_count;
> > + struct drm_dp_tunnel_group *groups;
> > + wait_queue_head_t bw_req_queue;
> > +
> > +#ifdef CONFIG_DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE
> > + struct ref_tracker_dir ref_tracker;
> > +#endif
> > +};
> > +
> > + [...]
> > +/* Return granularity in kB/s units */
> > +static int tunnel_reg_bw_granularity(const struct drm_dp_tunnel_regs *regs)
> > +{
> > + int gr = tunnel_reg(regs, DP_BW_GRANULARITY) &
> > DP_BW_GRANULARITY_MASK;
> > +
> > + WARN_ON(gr > 2);
> > +
>
> I think it should fail as well along with WARN, > 2 is not supported.
> However, this situation is highly unlikely though.
Yes, validating this in tunnel_regs_are_valid() is missing, will add
that.
> > + return (25 << gr) / 8;
> [...]
> > +
> > +static int check_and_clear_status_change(struct drm_dp_tunnel *tunnel)
> > +{
> > + u8 mask = DP_BW_ALLOCATION_CAPABILITY_CHANGED |
> > DP_ESTIMATED_BW_CHANGED;
> > + u8 val;
> > +
> > + if (drm_dp_dpcd_readb(tunnel->aux, DP_TUNNELING_STATUS, ) < 0)
> > + goto out_err;
> > +
> > + val &= mask;
> > +
> > + if (val) {
> > + if (drm_dp_dpcd_writeb(tunnel->aux, DP_TUNNELING_STATUS, val)
> > < 0)
> > + goto out_err;
> > +
> > + return 1;
>
> Seems this return value is not considered by the caller.
It indicates a status change and handled accordingly by the caller.
Probably it's better to document this, can add that.
> Hi Imre,
> Overall changes look good to me.
> It would be ideal if we can break this patch down, no major concern though.
> Leaving to your judgment.
The current way adds the DRM/i915 specific support separately, each
adding one .c file, the rest of the patchset taking these into use, each
patch doing this for a given scope of functionality. Didn't have a
better idea, maybe the DPCD registers could be added separately, but not
sure if that would make reviewing easier.
> With some above minor nits addressed, this is
> Reviewed-by: Uma Shankar
>
> Note: Have checked the register definitions/addresses, offsets. Have
> Logically checked the code
> in general, as well. It would be good if tunnel manager and tunnel groups
> related logic can be double
> confirmed by someone. Having said that, no issue I could spot there.
Thanks.
> Regards,
> Uma Shankar
>
> > + }
> > +
> > + if (!drm_dp_tunnel_bw_alloc_is_enabled(tunnel))
> > + return 0;
> > +
> > + /*
> > + * Check for estimated BW changes explicitly to account for lost
> > + * BW change notifications.
> > + */
> > + if (drm_dp_dpcd_readb(tunnel->aux, DP_ESTIMATED_BW, ) < 0)
> > + goto out_err;
> > +
> > + if (val * tunnel->bw_granularity != tunnel->estimated_bw)
> > + return 1;
> > +
> > + return 0;
> > +
> > +out_err:
> > + drm_dp_tunnel_set_io_error(tunnel);
> > +
> > + return -EIO;
> > +}
> > +
> > +/**
> > + * drm_dp_tunnel_update_state - Update DP tunnel SW state with the HW state
> > + * @tunnel: Tunnel object
> >
Re: [PATCH 1/2] drm/ttm: improve idle/busy handling v4
Am 06.02.24 um 13:56 schrieb Christian König:
Am 06.02.24 um 13:53 schrieb Thomas Hellström:
Hi, Christian,
On Fri, 2024-01-26 at 15:09 +0100, Christian König wrote:
Previously we would never try to move a BO into the preferred
placements
when it ever landed in a busy placement since those were considered
compatible.
Rework the whole handling and finally unify the idle and busy
handling.
ttm_bo_validate() is now responsible to try idle placement first and
then
use the busy placement if that didn't worked.
Drawback is that we now always try the idle placement first for each
validation which might cause some additional CPU overhead on
overcommit.
v2: fix kerneldoc warning and coding style
v3: take care of XE as well
v4: keep the ttm_bo_mem_space functionality as it is for now, only
add
new handling for ttm_bo_validate as suggested by Thomas
Signed-off-by: Christian König
Reviewed-by: Zack Rusin v3
Sending this through xe CI, will try to review asap.
Take your time. At the moment people are bombarding me with work and I
have only two hands and one head as well :(
So I've digged myself out of that hole and would rather like to get this
new feature into 6.9.
Any time to review it? I can also plan some time to review your LRU
changes next week.
Thanks,
Christian.
Christian.
/Thomas
---
drivers/gpu/drm/ttm/ttm_bo.c | 231 +--
--
drivers/gpu/drm/ttm/ttm_resource.c | 16 +-
include/drm/ttm/ttm_resource.h | 3 +-
3 files changed, 121 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
b/drivers/gpu/drm/ttm/ttm_bo.c
index ba3f09e2d7e6..b12f435542a9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -724,64 +724,36 @@ static int ttm_bo_add_move_fence(struct
ttm_buffer_object *bo,
return ret;
}
-/*
- * Repeatedly evict memory from the LRU for @mem_type until we
create enough
- * space, or we've evicted everything and there isn't enough space.
- */
-static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
- const struct ttm_place *place,
- struct ttm_resource **mem,
- struct ttm_operation_ctx *ctx)
-{
- struct ttm_device *bdev = bo->bdev;
- struct ttm_resource_manager *man;
- struct ww_acquire_ctx *ticket;
- int ret;
-
- man = ttm_manager_type(bdev, place->mem_type);
- ticket = dma_resv_locking_ctx(bo->base.resv);
- do {
- ret = ttm_resource_alloc(bo, place, mem);
- if (likely(!ret))
- break;
- if (unlikely(ret != -ENOSPC))
- return ret;
- ret = ttm_mem_evict_first(bdev, man, place, ctx,
- ticket);
- if (unlikely(ret != 0))
- return ret;
- } while (1);
-
- return ttm_bo_add_move_fence(bo, man, *mem, ctx-
no_wait_gpu);
-}
-
/**
- * ttm_bo_mem_space
+ * ttm_bo_alloc_resource - Allocate backing store for a BO
*
- * @bo: Pointer to a struct ttm_buffer_object. the data of which
- * we want to allocate space for.
- * @placement: Proposed new placement for the buffer object.
- * @mem: A struct ttm_resource.
+ * @bo: Pointer to a struct ttm_buffer_object of which we want a
resource for
+ * @placement: Proposed new placement for the buffer object
* @ctx: if and how to sleep, lock buffers and alloc memory
+ * @force_space: If we should evict buffers to force space
+ * @res: The resulting struct ttm_resource.
*
- * Allocate memory space for the buffer object pointed to by @bo,
using
- * the placement flags in @placement, potentially evicting other
idle buffer objects.
- * This function may sleep while waiting for space to become
available.
+ * Allocates a resource for the buffer object pointed to by @bo,
using the
+ * placement flags in @placement, potentially evicting other buffer
objects when
+ * @force_space is true.
+ * This function may sleep while waiting for resources to become
available.
* Returns:
- * -EBUSY: No space available (only if no_wait == 1).
+ * -EBUSY: No space available (only if no_wait == true).
* -ENOSPC: Could not allocate space for the buffer object, either
due to
* fragmentation or concurrent allocators.
* -ERESTARTSYS: An interruptible sleep was interrupted by a signal.
*/
-int ttm_bo_mem_space(struct ttm_buffer_object *bo,
- struct ttm_placement *placement,
- struct ttm_resource **mem,
- struct ttm_operation_ctx *ctx)
+static int ttm_bo_alloc_resource(struct ttm_buffer_object *bo,
+ struct ttm_placement *placement,
+ struct ttm_operation_ctx *ctx,
+ bool force_space,
+ struct ttm_resource **res)
{
struct ttm_device *bdev = bo->bdev;
- bool type_found = false;
+ struct ww_acquire_ctx *ticket;
int i, ret;
+ ticket = dma_resv_locking_ctx(bo->base.resv);
ret = dma_resv_reserve_fences(bo->base.resv, 1);
if (unlikely(ret))
return
Re: [PATCH v2 1/4] ALSA: hda: Skip i915 initialization on CNL/LKF-based platforms
On Fri, Feb 23, 2024 at 12:46:23PM +0100, Cezary Rojewski wrote:
> Commit 78f613ba1efb ("drm/i915: finish removal of CNL") and its friends
> removed support for i915 for all CNL-based platforms. HDAudio library,
> however, still treats such platforms as valid candidates for i915
> binding. Update query mechanism to reflect changes made in drm tree.
>
> At the same time, i915 support for LKF-based platforms has not been
> provided so remove them from valid binding candidates.
>
> Link:
> https://lore.kernel.org/all/20210728215946.1573015-1-lucas.demar...@intel.com/
> Signed-off-by: Cezary Rojewski
Reviewed-by: Rodrigo Vivi
> ---
> sound/hda/hdac_i915.c | 32 +---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> index 365c36fdf205..afee87bd0f2e 100644
> --- a/sound/hda/hdac_i915.c
> +++ b/sound/hda/hdac_i915.c
> @@ -127,15 +127,41 @@ static int i915_component_master_match(struct device
> *dev, int subcomponent,
> /* check whether Intel graphics is present and reachable */
> static int i915_gfx_present(struct pci_dev *hdac_pci)
> {
> + /* List of known platforms with no i915 support. */
> + static struct pci_device_id denylist[] = {
> + /* CNL */
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a40), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a41), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a42), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a44), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a49), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a4a), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a4c), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a50), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a51), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a52), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a54), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a59), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a5a), 0x03, 0xff },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a5c), 0x03, 0xff },
> + /* LKF */
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9840), 0x03, 0xff },
> + { 0 }
> + };
> struct pci_dev *display_dev = NULL;
>
> if (!gpu_bind || (gpu_bind < 0 && video_firmware_drivers_only()))
> return false;
>
> for_each_pci_dev(display_dev) {
> - if (display_dev->vendor == PCI_VENDOR_ID_INTEL &&
> - (display_dev->class >> 16) == PCI_BASE_CLASS_DISPLAY &&
> - connectivity_check(display_dev, hdac_pci)) {
> + if (display_dev->vendor != PCI_VENDOR_ID_INTEL ||
> + (display_dev->class >> 16) != PCI_BASE_CLASS_DISPLAY)
> + continue;
> +
> + if (pci_match_id(denylist, display_dev))
> + continue;
> +
> + if (connectivity_check(display_dev, hdac_pci)) {
> pci_dev_put(display_dev);
> return true;
> }
> --
> 2.25.1
>
✗ Fi.CI.BAT: failure for ALSA/ASoC: Conditionally skip i915 init and cleanups (rev2)
== Series Details ==
Series: ALSA/ASoC: Conditionally skip i915 init and cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/130271/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14325 -> Patchwork_130271v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_130271v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_130271v2, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) 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_130271v2/index.html
Participating hosts (36 -> 35)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_130271v2:
### IGT changes ###
Possible regressions
* igt@gem_exec_fence@basic-busy@vcs1:
- bat-arls-1: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14325/bat-arls-1/igt@gem_exec_fence@basic-b...@vcs1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130271v2/bat-arls-1/igt@gem_exec_fence@basic-b...@vcs1.html
Known issues
Here are the changes found in Patchwork_130271v2 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_create@basic@smem:
- bat-arls-1: [DMESG-WARN][3] ([i915#10194]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14325/bat-arls-1/igt@gem_exec_create@ba...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130271v2/bat-arls-1/igt@gem_exec_create@ba...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][5] ([i915#7911]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14325/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130271v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#10194]: https://gitlab.freedesktop.org/drm/intel/issues/10194
[i915#5591]: https://gitlab.freedesktop.org/drm/intel/issues/5591
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
Build changes
-
* Linux: CI_DRM_14325 -> Patchwork_130271v2
CI-20190529: 20190529
CI_DRM_14325: 115d0ed85f58e87d2d7a057426350fec5b217cc9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7728: 7728
Patchwork_130271v2: 115d0ed85f58e87d2d7a057426350fec5b217cc9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
0b83f358f4bf ALSA: hda: Reuse for_each_pcm_streams()
aa841f78b78e ASoC: codecs: hda: Cleanup error messages
8c5caf70cad5 ASoC: codecs: hda: Skip HDMI/DP registration if i915 is missing
710017466247 ALSA: hda: Skip i915 initialization on CNL/LKF-based platforms
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130271v2/index.html
[PATCH v2 4/4] ALSA: hda: Reuse for_each_pcm_streams()
Use the macro to improve readability.
Signed-off-by: Cezary Rojewski
---
sound/pci/hda/hda_codec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index 12f02cdc9659..2cac337f5263 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3313,7 +3313,7 @@ int snd_hda_codec_parse_pcms(struct hda_codec *codec)
list_for_each_entry(cpcm, >pcm_list_head, list) {
int stream;
- for (stream = 0; stream < 2; stream++) {
+ for_each_pcm_streams(stream) {
struct hda_pcm_stream *info = >stream[stream];
if (!info->substreams)
--
2.25.1
[PATCH v2 3/4] ASoC: codecs: hda: Cleanup error messages
Be cohesive and use same pattern in each error message.
Signed-off-by: Cezary Rojewski
---
sound/soc/codecs/hda.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/codecs/hda.c b/sound/soc/codecs/hda.c
index d9e7cd8aada2..8a9d0674555e 100644
--- a/sound/soc/codecs/hda.c
+++ b/sound/soc/codecs/hda.c
@@ -198,19 +198,19 @@ static int hda_codec_probe(struct snd_soc_component
*component)
ret = snd_hda_codec_device_new(codec->bus, component->card->snd_card,
hdev->addr, codec,
false);
if (ret < 0) {
- dev_err(>dev, "create hda codec failed: %d\n", ret);
+ dev_err(>dev, "codec create failed: %d\n", ret);
goto device_new_err;
}
ret = snd_hda_codec_set_name(codec, codec->preset->name);
if (ret < 0) {
- dev_err(>dev, "name failed %s\n", codec->preset->name);
+ dev_err(>dev, "set name: %s failed: %d\n",
codec->preset->name, ret);
goto err;
}
ret = snd_hdac_regmap_init(>core);
if (ret < 0) {
- dev_err(>dev, "regmap init failed\n");
+ dev_err(>dev, "regmap init failed: %d\n", ret);
goto err;
}
@@ -223,13 +223,13 @@ static int hda_codec_probe(struct snd_soc_component
*component)
ret = patch(codec);
if (ret < 0) {
- dev_err(>dev, "patch failed %d\n", ret);
+ dev_err(>dev, "codec init failed: %d\n", ret);
goto err;
}
ret = snd_hda_codec_parse_pcms(codec);
if (ret < 0) {
- dev_err(>dev, "unable to map pcms to dai %d\n", ret);
+ dev_err(>dev, "unable to map pcms to dai: %d\n", ret);
goto parse_pcms_err;
}
--
2.25.1
[PATCH v2 2/4] ASoC: codecs: hda: Skip HDMI/DP registration if i915 is missing
If i915 does not support given platform but the hardware i.e.: HDAudio
codec is still there, the codec-probing procedure will succeed for such
device but the follow up initialization will always end up with -ENODEV.
While bus could filter out address '2' which Intel's HDMI/DP codecs
always enumerate on, more robust approach is to check for i915 presence
before registering display codecs.
Signed-off-by: Cezary Rojewski
---
sound/soc/codecs/hda.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/sound/soc/codecs/hda.c b/sound/soc/codecs/hda.c
index d2117e36ddd1..d9e7cd8aada2 100644
--- a/sound/soc/codecs/hda.c
+++ b/sound/soc/codecs/hda.c
@@ -350,6 +350,11 @@ static int hda_hdev_attach(struct hdac_device *hdev)
struct hda_codec *codec = dev_to_hda_codec(>dev);
struct snd_soc_component_driver *comp_drv;
+ if (hda_codec_is_display(codec) && !hdev->bus->audio_component) {
+ dev_dbg(>dev, "no i915, skip registration for 0x%08x\n",
hdev->vendor_id);
+ return 0;
+ }
+
comp_drv = devm_kzalloc(>dev, sizeof(*comp_drv), GFP_KERNEL);
if (!comp_drv)
return -ENOMEM;
--
2.25.1
[PATCH v2 1/4] ALSA: hda: Skip i915 initialization on CNL/LKF-based platforms
Commit 78f613ba1efb ("drm/i915: finish removal of CNL") and its friends
removed support for i915 for all CNL-based platforms. HDAudio library,
however, still treats such platforms as valid candidates for i915
binding. Update query mechanism to reflect changes made in drm tree.
At the same time, i915 support for LKF-based platforms has not been
provided so remove them from valid binding candidates.
Link:
https://lore.kernel.org/all/20210728215946.1573015-1-lucas.demar...@intel.com/
Signed-off-by: Cezary Rojewski
---
sound/hda/hdac_i915.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index 365c36fdf205..afee87bd0f2e 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -127,15 +127,41 @@ static int i915_component_master_match(struct device
*dev, int subcomponent,
/* check whether Intel graphics is present and reachable */
static int i915_gfx_present(struct pci_dev *hdac_pci)
{
+ /* List of known platforms with no i915 support. */
+ static struct pci_device_id denylist[] = {
+ /* CNL */
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a40), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a41), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a42), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a44), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a49), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a4a), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a4c), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a50), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a51), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a52), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a54), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a59), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a5a), 0x03, 0xff },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x5a5c), 0x03, 0xff },
+ /* LKF */
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9840), 0x03, 0xff },
+ { 0 }
+ };
struct pci_dev *display_dev = NULL;
if (!gpu_bind || (gpu_bind < 0 && video_firmware_drivers_only()))
return false;
for_each_pci_dev(display_dev) {
- if (display_dev->vendor == PCI_VENDOR_ID_INTEL &&
- (display_dev->class >> 16) == PCI_BASE_CLASS_DISPLAY &&
- connectivity_check(display_dev, hdac_pci)) {
+ if (display_dev->vendor != PCI_VENDOR_ID_INTEL ||
+ (display_dev->class >> 16) != PCI_BASE_CLASS_DISPLAY)
+ continue;
+
+ if (pci_match_id(denylist, display_dev))
+ continue;
+
+ if (connectivity_check(display_dev, hdac_pci)) {
pci_dev_put(display_dev);
return true;
}
--
2.25.1
[PATCH v2 0/4] ALSA/ASoC: Conditionally skip i915 init and cleanups
A small set of changes to improve initialization of the audio stack on
HDAudio devices and pair of cleanups.
As the first change is the most important one here, following is the
technical background for it:
Commit 78f613ba1efb ("drm/i915: finish removal of CNL") and its friends
removed support for i915 for all CNL-based platforms. HDAudio library,
however, still treats such platforms as valid candidates for i915
binding. Update query mechanism to reflect changes made in drm tree.
At the same time, i915 support for LKF-based platforms has not been
provided so remove them from valid binding candidates.
The snd_soc_hda change is a follow up for the above and the cleanup
patches do not bring any functional changes.
Changes in v2:
- list of problematic VGA devices is now declared locally, no more
touching drm stuff
Cezary Rojewski (4):
ALSA: hda: Skip i915 initialization on CNL/LKF-based platforms
ASoC: codecs: hda: Skip HDMI/DP registration if i915 is missing
ASoC: codecs: hda: Cleanup error messages
ALSA: hda: Reuse for_each_pcm_streams()
sound/hda/hdac_i915.c | 32 +---
sound/pci/hda/hda_codec.c | 2 +-
sound/soc/codecs/hda.c| 15 ++-
3 files changed, 40 insertions(+), 9 deletions(-)
--
2.25.1
✗ Fi.CI.IGT: failure for LNL display
== Series Details ==
Series: LNL display
URL : https://patchwork.freedesktop.org/series/130255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14320_full -> Patchwork_130255v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_130255v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_130255v1_full, please notify your bug team
(i915-ci-in...@lists.freedesktop.org) 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_130255v1/index.html
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_130255v1_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_schedule@wide@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14320/shard-glk4/igt@gem_exec_schedule@w...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-glk2/igt@gem_exec_schedule@w...@rcs0.html
* {igt@kms_ccs@missing-ccs-buffer-yf-tiled-ccs@pipe-d-hdmi-a-2} (NEW):
- shard-dg2: NOTRUN -> [SKIP][3] +1 other test skip
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-dg2-2/igt@kms_ccs@missing-ccs-buffer-yf-tiled-...@pipe-d-hdmi-a-2.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@crc-sprite-planes-basic-4-tiled-mtl-rc-ccs-cc@pipe-d-hdmi-a-2}:
- shard-dg2: NOTRUN -> [SKIP][4] +12 other tests skip
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-dg2-2/igt@kms_ccs@crc-sprite-planes-basic-4-tiled-mtl-rc-ccs...@pipe-d-hdmi-a-2.html
New tests
-
New tests have been introduced between CI_DRM_14320_full and
Patchwork_130255v1_full:
### New IGT tests (4) ###
* igt@kms_ccs@bad-pixel-format-4-tiled-dg2-mc-ccs@pipe-d-hdmi-a-2:
- Statuses : 1 pass(s)
- Exec time: [0.00] s
* igt@kms_ccs@crc-primary-basic-4-tiled-dg2-rc-ccs-cc@pipe-d-hdmi-a-2:
- Statuses : 1 pass(s)
- Exec time: [0.32] s
* igt@kms_ccs@crc-primary-rotation-180-y-tiled-gen12-rc-ccs@pipe-d-hdmi-a-2:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_ccs@missing-ccs-buffer-yf-tiled-ccs@pipe-d-hdmi-a-2:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_130255v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@blit-reloc-keep-cache:
- shard-mtlp: NOTRUN -> [SKIP][5] ([i915#8411])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-mtlp-3/igt@api_intel...@blit-reloc-keep-cache.html
* igt@drm_fdinfo@all-busy-check-all:
- shard-mtlp: NOTRUN -> [SKIP][6] ([i915#8414]) +1 other test skip
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-mtlp-3/igt@drm_fdi...@all-busy-check-all.html
* igt@drm_fdinfo@most-busy-idle-check-all@vecs1:
- shard-dg2: NOTRUN -> [SKIP][7] ([i915#8414]) +9 other tests skip
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-dg2-10/igt@drm_fdinfo@most-busy-idle-check-...@vecs1.html
* igt@gem_ccs@ctrl-surf-copy:
- shard-mtlp: NOTRUN -> [SKIP][8] ([i915#3555] / [i915#9323])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-mtlp-3/igt@gem_...@ctrl-surf-copy.html
* igt@gem_create@create-ext-cpu-access-big:
- shard-dg2: NOTRUN -> [ABORT][9] ([i915#10183])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-dg2-1/igt@gem_cre...@create-ext-cpu-access-big.html
* igt@gem_ctx_persistence@heartbeat-stop:
- shard-dg2: NOTRUN -> [SKIP][10] ([i915#8555])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-dg2-3/igt@gem_ctx_persiste...@heartbeat-stop.html
* igt@gem_ctx_sseu@invalid-args:
- shard-dg2: NOTRUN -> [SKIP][11] ([i915#280])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-dg2-10/igt@gem_ctx_s...@invalid-args.html
* igt@gem_eio@reset-stress:
- shard-dg1: [PASS][12] -> [FAIL][13] ([i915#5784])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14320/shard-dg1-17/igt@gem_...@reset-stress.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_130255v1/shard-dg1-18/igt@gem_...@reset-stress.html
* igt@gem_exec_balancer@bonded-dual:
- shard-dg2: NOTRUN -> [SKIP][14] ([i915#4771])
[14]:
✓ Fi.CI.BAT: success for Enable Adaptive Sync SDP Support for DP (rev10)
== Series Details == Series: Enable Adaptive Sync SDP Support for DP (rev10) URL : https://patchwork.freedesktop.org/series/126829/ State : success == Summary == CI Bug Log - changes from CI_DRM_14319 -> Patchwork_126829v10 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/index.html Participating hosts (38 -> 36) -- Missing(2): bat-mtlp-8 fi-snb-2520m Known issues Here are the changes found in Patchwork_126829v10 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@ccs0: - bat-arls-1: [PASS][1] -> [DMESG-WARN][2] ([i915#10194]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14319/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html * igt@gem_lmem_swapping@verify-random: - bat-arls-2: NOTRUN -> [SKIP][3] ([i915#10213]) +3 other tests skip [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_pread_basic: - bat-arls-2: NOTRUN -> [SKIP][4] ([i915#10206] / [i915#4079]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@gem_tiled_pread_basic.html * igt@i915_module_load@load: - fi-elk-e7500: [PASS][5] -> [INCOMPLETE][6] ([i915#10311]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14319/fi-elk-e7500/igt@i915_module_l...@load.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/fi-elk-e7500/igt@i915_module_l...@load.html - fi-bsw-nick:[PASS][7] -> [INCOMPLETE][8] ([i915#10311]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14319/fi-bsw-nick/igt@i915_module_l...@load.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/fi-bsw-nick/igt@i915_module_l...@load.html * igt@i915_pm_rpm@module-reload: - bat-arls-2: NOTRUN -> [DMESG-WARN][9] ([i915#10194] / [i915#10215]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@i915_pm_...@module-reload.html * igt@i915_pm_rps@basic-api: - bat-arls-2: NOTRUN -> [SKIP][10] ([i915#10209]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@coherency: - bat-arls-2: NOTRUN -> [DMESG-WARN][11] ([i915#10194]) +28 other tests dmesg-warn [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@i915_selftest@l...@coherency.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - bat-arls-2: NOTRUN -> [SKIP][12] ([i915#10200]) +9 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-arls-2: NOTRUN -> [SKIP][13] ([i915#10202]) +1 other test skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_dsc@dsc-basic: - bat-arls-2: NOTRUN -> [SKIP][14] ([i915#9886]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@kms_...@dsc-basic.html * igt@kms_force_connector_basic@force-load-detect: - bat-arls-2: NOTRUN -> [SKIP][15] ([i915#10207]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_hdmi_inject@inject-audio: - fi-ilk-650: [PASS][16] -> [INCOMPLETE][17] ([i915#10312]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14319/fi-ilk-650/igt@kms_hdmi_inj...@inject-audio.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/fi-ilk-650/igt@kms_hdmi_inj...@inject-audio.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][18] ([i915#9197]) +1 other test skip [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_psr@psr-primary-mmap-gtt@edp-1: - bat-arls-2: NOTRUN -> [SKIP][19] ([i915#10196] / [i915#4077] / [i915#9688]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@kms_psr@psr-primary-mmap-...@edp-1.html * igt@kms_setmode@basic-clone-single-crtc: - bat-arls-2: NOTRUN -> [SKIP][20] ([i915#10208] / [i915#8809]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126829v10/bat-arls-2/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-mmap:
RE: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 21/21] drm/i915/dp: Enable DP tunnel BW allocation mode
>
> Detect DP tunnels and enable the BW allocation mode on them. Send a hotplug
> notification to userspace in response to a BW change.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> .../drm/i915/display/intel_display_driver.c | 20 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +++--
> 2 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 4f7ba7eb03d27..87dd07e0d138d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -35,6 +35,7 @@
> #include "intel_dkl_phy.h"
> #include "intel_dmc.h"
> #include "intel_dp.h"
> +#include "intel_dp_tunnel.h"
> #include "intel_dpll.h"
> #include "intel_dpll_mgr.h"
> #include "intel_fb.h"
> @@ -434,10 +435,8 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
>
> for_each_pipe(i915, pipe) {
> ret = intel_crtc_init(i915, pipe);
> - if (ret) {
> - intel_mode_config_cleanup(i915);
> - return ret;
> - }
> + if (ret)
> + goto err_mode_config;
> }
>
> intel_plane_possible_crtcs_init(i915);
> @@ -457,6 +456,10 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
> intel_vga_disable(i915);
> intel_setup_outputs(i915);
>
> + ret = intel_dp_tunnel_mgr_init(i915);
> + if (ret)
> + goto err_hdcp;
> +
> intel_display_driver_disable_user_access(i915);
>
> drm_modeset_lock_all(dev);
> @@ -475,6 +478,13 @@ int intel_display_driver_probe_nogem(struct
> drm_i915_private *i915)
> ilk_wm_sanitize(i915);
>
> return 0;
> +
> +err_hdcp:
> + intel_hdcp_component_fini(i915);
> +err_mode_config:
> + intel_mode_config_cleanup(i915);
> +
> + return ret;
> }
>
> /* part #3: call after gem init */
> @@ -599,6 +609,8 @@ void intel_display_driver_remove_noirq(struct
> drm_i915_private *i915)
>
> intel_mode_config_cleanup(i915);
>
> + intel_dp_tunnel_mgr_cleanup(i915);
> +
> intel_overlay_cleanup(i915);
>
> intel_gmbus_teardown(i915);
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f7f8bd5742ad4..789b5fa074fd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5726,6 +5726,7 @@ intel_dp_detect(struct drm_connector *connector,
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct intel_encoder *encoder = _port->base;
> enum drm_connector_status status;
> + int ret;
>
> drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name); @@ -5761,9 +5762,18
> @@ intel_dp_detect(struct drm_connector *connector,
> intel_dp->is_mst);
> }
>
> + intel_dp_tunnel_disconnect(intel_dp);
> +
> goto out;
> }
>
> + ret = intel_dp_tunnel_detect(intel_dp, ctx);
> + if (ret == -EDEADLK)
> + return ret;
> +
> + if (ret == 1)
> + intel_connector->base.epoch_counter++;
> +
> intel_dp_detect_dsc_caps(intel_dp, intel_connector);
>
> intel_dp_configure_mst(intel_dp);
> @@ -5794,8 +5804,6 @@ intel_dp_detect(struct drm_connector *connector,
>* with an IRQ_HPD, so force a link status check.
>*/
> if (!intel_dp_is_edp(intel_dp)) {
> - int ret;
> -
> ret = intel_dp_retrain_link(encoder, ctx);
> if (ret)
> return ret;
> @@ -5935,6 +5943,8 @@ void intel_dp_encoder_flush_work(struct
> drm_encoder *encoder)
>
> intel_dp_mst_encoder_cleanup(dig_port);
>
> + intel_dp_tunnel_destroy(intel_dp);
> +
> intel_pps_vdd_off_sync(intel_dp);
>
> /*
> --
> 2.39.2
RE: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 20/21] drm/i915/dp: Read DPRX for all long HPD pulses
>
> The TBT DP tunnel BW request logic in the Thunderbolt Connection Manager
> depends on the GFX driver reading out the sink's DPRX capabilities in
> response to
> a long HPD pulse. Since in i915 this read-out can be blocked by another
> connector's/encoder's hotplug event handling (which is serialized by
> drm_mode_config::connection_mutex), do a dummy DPRX read-out in the
> encoder's HPD pulse handler (which is not blocked by other encoders).
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 35ef17439038a..f7f8bd5742ad4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6162,6 +6162,7 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
> bool long_hpd) {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> struct intel_dp *intel_dp = _port->dp;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
>
> if (dig_port->base.type == INTEL_OUTPUT_EDP &&
> (long_hpd || !intel_pps_have_panel_power_or_vdd(intel_dp))) { @@ -
> 6184,6 +6185,17 @@ intel_dp_hpd_pulse(struct intel_digital_port *dig_port,
> bool long_hpd)
> dig_port->base.base.name,
> long_hpd ? "long" : "short");
>
> + /*
> + * TBT DP tunnels require the GFX driver to read out the DPRX caps in
> + * response to long HPD pulses. The DP hotplug handler does that,
> + * however the hotplug handler may be blocked by another
> + * connector's/encoder's hotplug handler. Since the TBT CM may not
> + * complete the DP tunnel BW request for the latter connector/encoder
> + * waiting for this encoder's DPRX read, perform a dummy read here.
> + */
> + if (long_hpd)
> + intel_dp_read_dprx_caps(intel_dp, dpcd);
> +
> if (long_hpd) {
> intel_dp->reset_link_params = true;
> return IRQ_NONE;
> --
> 2.39.2
Re: [PATCH 1/4] ALSA: hda: Skip i915 initialization on CNL/LKF-based platforms
On 2024-02-23 9:47 AM, Takashi Iwai wrote:
On Thu, 22 Feb 2024 21:54:42 +0100,
Rodrigo Vivi wrote:
...
@@ -127,15 +128,26 @@ static int i915_component_master_match(struct device
*dev, int subcomponent,
/* check whether Intel graphics is present and reachable */
static int i915_gfx_present(struct pci_dev *hdac_pci)
{
+ /* List of known platforms with no i915 support. */
+ static struct pci_device_id denylist[] = {
+ INTEL_CNL_IDS(NULL),
+ INTEL_LKF_IDS(NULL),
+ { 0 }
+ };
I thought these don't actually exist in the wild?
To my knowledge the opposite is true - while LKFs were shipped in limited
number, they still were. I did ask few weeks ago my friends from Windows
side about the support and they're still running full-scopes on HDMI
endpoints on LKF platforms in their CIs. It seems the drm support is there
though. Once you re-boot to linux we get -19 during probe().
In regard to CNL, the commit removing CNL-support left the IDs intact what's
I would prefer to go the other way around and remove the unused/unsupported
IDs entirely and for good.
very handy to us - we have a lot of spare CNL boards for our validation
purposes - CNL-based AudioDSP spans multiple platforms, e.g.:
CNL/CFL/WHL/CML. The number of newer boards is lower, unfortunately.
Well, I do see your point here and you are not asking for us to add gfx
support back, but only help to have this protection here.
However I'm afraid that these entries in the list would only cause
further confusion. Couldn't they get defined inside your .c directly as
a const deny_list? so when we go there and remove the missing bits
of CNL we don't conflict or cause undersired issues to you.
That makes sense. Maybe drm people would get rid of the dead CNL*()
definitions from the header as a cleanup in near future, and we'll hit
a trouble.
Another, more robust solution could be to expose list of recognized
devices by drivers/gpu/drm/i915/i915_pci.c in a header. Rather than
guess, as we do in i915_gfx_present(), we would just loop over IDs in
such list.
As I'm unsure if such solution is viable, what I'll do for now is: send
v2 with relevant IDs moved over to sound/ tree, leaving the i915 header
alone. Incremental update can be provided later if a neater solution
appears on the horizon.
Kind regards,
Czarek
RE: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 19/21] drm/i915/dp: Suspend/resume DP tunnels
>
> Suspend and resume DP tunnels during system suspend/resume, disabling the BW
> allocation mode during suspend, re-enabling it after resume. This reflects the
> link's BW management component (Thunderbolt CM) disabling BWA during
> suspend. Before any BW requests the driver must read the sink's DPRX
> capabilities (since the BW manager requires this information, so snoops for
> it on
> AUX), so ensure this read takes place.
Looks Good to me.
Reviewed-by: Uma Shankar
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index a3dfcbb710027..35ef17439038a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -36,6 +36,7 @@
> #include
>
> #include
> +#include
> #include #include
> #include @@ -
> 3313,18 +3314,21 @@ void intel_dp_sync_state(struct intel_encoder *encoder,
>const struct intel_crtc_state *crtc_state) {
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> -
> - if (!crtc_state)
> - return;
> + bool dpcd_updated = false;
>
> /*
>* Don't clobber DPCD if it's been already read out during output
>* setup (eDP) or detect.
>*/
> - if (intel_dp->dpcd[DP_DPCD_REV] == 0)
> + if (crtc_state && intel_dp->dpcd[DP_DPCD_REV] == 0) {
> intel_dp_get_dpcd(intel_dp);
> + dpcd_updated = true;
> + }
>
> - intel_dp_reset_max_link_params(intel_dp);
> + intel_dp_tunnel_resume(intel_dp, crtc_state, dpcd_updated);
> +
> + if (crtc_state)
> + intel_dp_reset_max_link_params(intel_dp);
> }
>
> bool intel_dp_initial_fastset_check(struct intel_encoder *encoder, @@ -5947,6
> +5951,8 @@ void intel_dp_encoder_suspend(struct intel_encoder
> *intel_encoder)
> struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
>
> intel_pps_vdd_off_sync(intel_dp);
> +
> + intel_dp_tunnel_suspend(intel_dp);
> }
>
> void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
> --
> 2.39.2
RE: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [PATCH v2 17/21] drm/i915/dp: Handle DP tunnel IRQs
>
> Handle DP tunnel IRQs a sink (or rather a BW management component like the
> Thunderbolt Connection Manager) raises to signal the completion of a BW
> request by the driver, or to signal any state change related to the link BW.
Looks Good to me.
Reviewed-by: Uma Shankar
X`
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 37 +++--
> include/drm/display/drm_dp.h| 1 +
> 2 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 5ad7808788745..a3dfcbb710027 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4904,13 +4904,15 @@ static bool intel_dp_mst_link_status(struct intel_dp
> *intel_dp)
> * - %true if pending interrupts were serviced (or no interrupts were
> * pending) w/o detecting an error condition.
> * - %false if an error condition - like AUX failure or a loss of link - is
> - * detected, which needs servicing from the hotplug work.
> + * detected, or another condition - like a DP tunnel BW state change -
> needs
> + * servicing from the hotplug work.
> */
> static bool
> intel_dp_check_mst_status(struct intel_dp *intel_dp) {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> bool link_ok = true;
> + bool reprobe_needed = false;
>
> drm_WARN_ON_ONCE(>drm, intel_dp->active_mst_links < 0);
>
> @@ -4937,6 +4939,13 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
>
> intel_dp_mst_hpd_irq(intel_dp, esi, ack);
>
> + if (esi[3] & DP_TUNNELING_IRQ) {
> + if (drm_dp_tunnel_handle_irq(i915-
> >display.dp_tunnel_mgr,
> + _dp->aux))
> + reprobe_needed = true;
> + ack[3] |= DP_TUNNELING_IRQ;
> + }
> +
> if (!memchr_inv(ack, 0, sizeof(ack)))
> break;
>
> @@ -4947,7 +4956,7 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> drm_dp_mst_hpd_irq_send_new_request(_dp-
> >mst_mgr);
> }
>
> - return link_ok;
> + return link_ok && !reprobe_needed;
> }
>
> static void
> @@ -5304,23 +5313,32 @@ static void
> intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
> drm_dbg_kms(>drm, "Sink specific irq unhandled\n"); }
>
> -static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> +static bool intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool reprobe_needed = false;
> u8 val;
>
> if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
> - return;
> + return false;
>
> if (drm_dp_dpcd_readb(_dp->aux,
> DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
> !val)
> - return;
> + return false;
> +
> + if ((val & DP_TUNNELING_IRQ) &&
> + drm_dp_tunnel_handle_irq(i915->display.dp_tunnel_mgr,
> + _dp->aux))
> + reprobe_needed = true;
>
> if (drm_dp_dpcd_writeb(_dp->aux,
> DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
> - return;
> + return reprobe_needed;
>
> if (val & HDMI_LINK_STATUS_CHANGED)
> intel_dp_handle_hdmi_link_status_change(intel_dp);
> +
> + return reprobe_needed;
> }
>
> /*
> @@ -5341,6 +5359,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp) {
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> u8 old_sink_count = intel_dp->sink_count;
> + bool reprobe_needed = false;
> bool ret;
>
> /*
> @@ -5363,7 +5382,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> }
>
> intel_dp_check_device_service_irq(intel_dp);
> - intel_dp_check_link_service_irq(intel_dp);
> + reprobe_needed = intel_dp_check_link_service_irq(intel_dp);
>
> /* Handle CEC interrupts, if any */
> drm_dp_cec_irq(_dp->aux);
> @@ -5390,10 +5409,10 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>* FIXME get rid of the ad-hoc phy test modeset code
>* and properly incorporate it into the normal modeset.
>*/
> - return false;
> + reprobe_needed = true;
> }
>
> - return true;
> + return !reprobe_needed;
> }
>
> /* XXX this is probably wrong for multiple downstream ports */ diff --git
> a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index
> 8bfd5d007be8d..4891bd916d26a 100644
>
✓ Fi.CI.BAT: success for HDCP MST Type1 fixes (rev5)
== Series Details == Series: HDCP MST Type1 fixes (rev5) URL : https://patchwork.freedesktop.org/series/129925/ State : success == Summary == CI Bug Log - changes from CI_DRM_14324 -> Patchwork_129925v5 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/index.html Participating hosts (35 -> 36) -- Additional (3): fi-glk-j4005 bat-adlm-1 bat-arls-3 Missing(2): bat-mtlp-8 fi-snb-2520m Known issues Here are the changes found in Patchwork_129925v5 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-cfl-8109u: [FAIL][1] ([i915#8293]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14324/fi-cfl-8109u/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/fi-cfl-8109u/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlm-1: NOTRUN -> [SKIP][3] ([i915#3826]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html - bat-arls-3: NOTRUN -> [SKIP][4] ([i915#9318]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-3/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@eof: - bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#2582]) +3 other tests skip [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-adlm-1/igt@fb...@eof.html * igt@fbdev@info: - bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#1849] / [i915#2582]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-adlm-1/igt@fb...@info.html * igt@gem_exec_fence@basic-busy@ccs0: - bat-arls-1: [PASS][7] -> [DMESG-WARN][8] ([i915#10194]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14324/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-1/igt@gem_exec_fence@basic-b...@ccs0.html * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html - fi-glk-j4005: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/fi-glk-j4005/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-glk-j4005: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 other tests skip [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/fi-glk-j4005/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#4613]) +3 other tests skip [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html - bat-arls-3: NOTRUN -> [SKIP][13] ([i915#10213]) +3 other tests skip [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-3/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-8109u: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +3 other tests skip [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-arls-3: NOTRUN -> [SKIP][15] ([i915#4083]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-3/igt@gem_m...@basic.html * igt@gem_render_tiled_blits@basic: - bat-arls-3: NOTRUN -> [SKIP][16] ([i915#10197] / [i915#10211] / [i915#4079]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-3/igt@gem_render_tiled_bl...@basic.html * igt@gem_tiled_blits@basic: - bat-arls-3: NOTRUN -> [SKIP][17] ([i915#10196] / [i915#4077]) +2 other tests skip [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-3/igt@gem_tiled_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-adlm-1: NOTRUN -> [SKIP][18] ([i915#3282]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-adlm-1/igt@gem_tiled_pread_basic.html - bat-arls-3: NOTRUN -> [SKIP][19] ([i915#10206] / [i915#4079]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-3/igt@gem_tiled_pread_basic.html * igt@i915_pm_rpm@module-reload: - bat-arls-3: NOTRUN -> [DMESG-WARN][20] ([i915#10194] / [i915#10215]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129925v5/bat-arls-3/igt@i915_pm_...@module-reload.html * igt@i915_pm_rps@basic-api: - bat-adlm-1: NOTRUN -> [SKIP][21] ([i915#6621]) [21]:
RE: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check BW limit
> -Original Message- > From: dri-devel On Behalf Of Imre > Deak > Sent: Wednesday, February 21, 2024 2:49 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: [PATCH v2 13/21] drm/i915/dp: Add DP tunnel atomic state and check > BW limit > > Add the atomic state during a modeset required to enable the DP tunnel BW > allocation mode on links where such a tunnel was detected. This state applies > to > an already enabled output, the state added for a newly enabled output will be > computed and added/cleared to/from the atomic state in a follow-up patch. > > v2: > - s/old_crtc_state/crtc_state in intel_crtc_duplicate_state(). > - Move intel_dp_tunnel_atomic_cleanup_inherited_state() to a follow-up > patch adding the corresponding state. (Ville) > - Move intel_dp_tunnel_atomic_clear_stream_bw() to a follow-up > patch adding the corresponding state. Looks Good to me. Reviewed-by: Uma Shankar > Cc: Ville Syrjälä > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++ > drivers/gpu/drm/i915/display/intel_display.c | 12 > drivers/gpu/drm/i915/display/intel_link_bw.c | 5 + > 3 files changed, 23 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c > b/drivers/gpu/drm/i915/display/intel_atomic.c > index 96ab37e158995..798cb90361a83 100644 > --- a/drivers/gpu/drm/i915/display/intel_atomic.c > +++ b/drivers/gpu/drm/i915/display/intel_atomic.c > @@ -260,6 +260,10 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc) > if (crtc_state->post_csc_lut) > drm_property_blob_get(crtc_state->post_csc_lut); > > + if (crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_get(crtc_state->dp_tunnel_ref.tunnel, > + _state->dp_tunnel_ref); > + > crtc_state->update_pipe = false; > crtc_state->update_m_n = false; > crtc_state->update_lrr = false; > @@ -311,6 +315,8 @@ intel_crtc_destroy_state(struct drm_crtc *crtc, > > __drm_atomic_helper_crtc_destroy_state(_state->uapi); > intel_crtc_free_hw_state(crtc_state); > + if (crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_put(_state->dp_tunnel_ref); > kfree(crtc_state); > } > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index e1a4200f67a7e..16973ebb7865d 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -33,6 +33,7 @@ > #include > > #include > +#include > #include > #include > #include > @@ -73,6 +74,7 @@ > #include "intel_dp.h" > #include "intel_dp_link_training.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_dpll.h" > #include "intel_dpll_mgr.h" > #include "intel_dpt.h" > @@ -4490,6 +4492,8 @@ copy_bigjoiner_crtc_state_modeset(struct > intel_atomic_state *state, > saved_state->crc_enabled = slave_crtc_state->crc_enabled; > > intel_crtc_free_hw_state(slave_crtc_state); > + if (slave_crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_put(_crtc_state->dp_tunnel_ref); > memcpy(slave_crtc_state, saved_state, sizeof(*slave_crtc_state)); > kfree(saved_state); > > @@ -4505,6 +4509,10 @@ copy_bigjoiner_crtc_state_modeset(struct > intel_atomic_state *state, > _crtc_state->hw.adjusted_mode); > slave_crtc_state->hw.scaling_filter = master_crtc_state- > >hw.scaling_filter; > > + if (master_crtc_state->dp_tunnel_ref.tunnel) > + drm_dp_tunnel_ref_get(master_crtc_state- > >dp_tunnel_ref.tunnel, > + _crtc_state->dp_tunnel_ref); > + > copy_bigjoiner_crtc_state_nomodeset(state, slave_crtc); > > slave_crtc_state->uapi.mode_changed = master_crtc_state- > >uapi.mode_changed; > @@ -5365,6 +5373,10 @@ static int intel_modeset_pipe(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_add_state_for_crtc(state, crtc); > + if (ret) > + return ret; > + > ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/i915/display/intel_link_bw.c > b/drivers/gpu/drm/i915/display/intel_link_bw.c > index 27ea858897c9f..dfd7d5e23f3fa 100644 > --- a/drivers/gpu/drm/i915/display/intel_link_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_link_bw.c > @@ -9,6 +9,7 @@ > #include "intel_crtc.h" > #include "intel_display_types.h" > #include "intel_dp_mst.h" > +#include "intel_dp_tunnel.h" > #include "intel_fdi.h" > #include "intel_link_bw.h" > > @@ -163,6 +164,10 @@ static int check_all_link_config(struct > intel_atomic_state *state, > if (ret) > return ret; > > + ret = intel_dp_tunnel_atomic_check_link(state, limits); > + if (ret) > +
✗ Fi.CI.SPARSE: warning for HDCP MST Type1 fixes (rev5)
== Series Details == Series: HDCP MST Type1 fixes (rev5) URL : https://patchwork.freedesktop.org/series/129925/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:116:1: warning: unreplaced symbol 'return'
Re: [PATCH] drm/i915/guc: Add Compute context hint
On 22/02/2024 23:31, Belgaumkar, Vinay wrote:
On 2/22/2024 7:32 AM, Tvrtko Ursulin wrote:
On 21/02/2024 21:28, Rodrigo Vivi wrote:
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Vinay Belgaumkar wrote:
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will also be
lower so GuC will ramp down the GT freq for this context more slowly.
We also disable waitboost for this context as that will interfere with
the strategy.
We need to enable the use of Compute strategy during SLPC init, but
it will apply only to contexts that set this bit during context
creation.
Userland can check whether this feature is supported using a new
param-
I915_PARAM_HAS_COMPUTE_CONTEXT. This flag is true for all guc
submission
enabled platforms since they use SLPC for freq management.
The Mesa usage model for this flag is here -
https://gitlab.freedesktop.org/sushmave/mesa/-/commits/compute_hint
This allows for setting it for the whole application, correct? Upsides,
downsides? Are there any plans for per context?
Currently there's no extension on a high level API
(Vulkan/OpenGL/OpenCL/etc)
that would allow the application to hint for power/freq/latency. So
Mesa cannot
decide when to hint. So their solution was to use .drirc and make
per-application
decision.
I would prefer a high level extension for a more granular and
informative
decision. We need to work with that goal, but for now I don't see any
cons on this approach.
In principle yeah I doesn't harm to have the option. I am just not
sure how useful this intermediate step this is with its lack of
intra-process granularity.
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8 +++
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_rps.c | 8 +++
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 21
+++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 +++
drivers/gpu/drm/i915/i915_getparam.c | 11 ++
include/uapi/drm/i915_drm.h | 15 +
9 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dcbfe32fd30c..ceab7dbe9b47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
struct i915_gem_proto_context *pc,
struct drm_i915_gem_context_param *args)
{
+ struct drm_i915_private *i915 = fpriv->i915;
int ret = 0;
switch (args->param) {
@@ -904,6 +905,13 @@ static int set_proto_ctx_param(struct
drm_i915_file_private *fpriv,
pc->user_flags &= ~BIT(UCONTEXT_BANNABLE);
break;
+ case I915_CONTEXT_PARAM_IS_COMPUTE:
+ if (!intel_uc_uses_guc_submission(_gt(i915)->uc))
+ ret = -EINVAL;
+ else
+ pc->user_flags |= BIT(UCONTEXT_COMPUTE);
+ break;
+
case I915_CONTEXT_PARAM_RECOVERABLE:
if (args->size)
ret = -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 03bc7f9d191b..db86d6f6245f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -338,6 +338,7 @@ struct i915_gem_context {
#define UCONTEXT_BANNABLE 2
#define UCONTEXT_RECOVERABLE 3
#define UCONTEXT_PERSISTENCE 4
+#define UCONTEXT_COMPUTE 5
What is the GuC behaviour when SLPC_CTX_FREQ_REQ_IS_COMPUTE is set for
non-compute engines? Wondering if per intel_context is what we want
instead.
(Which could then be the i915_context_param_engines extension to mark
individual contexts as compute strategy.)
Perhaps we should rename this? This is a freq-decision-strategy inside
GuC that is there mostly targeting compute workloads that needs lower
latency with short burst execution. But the engine itself doesn't
matter.
It can be applied to any engine.
I have no idea if it makes sense for other engines, such as video, and
what would be pros and cons in terms of PnP. But in the case we end up
allowing it on any engine, then at least userspace name shouldn't be
compute. :)
Yes, one of the suggestions from Daniele was to have something along the
lines of UCONTEXT_HIFREQ or something along those lines so we don't
confuse it with the Compute Engine.
Okay, but additional question is would anyone
Re: [PATCH 1/4] ALSA: hda: Skip i915 initialization on CNL/LKF-based platforms
On Thu, 22 Feb 2024 21:54:42 +0100,
Rodrigo Vivi wrote:
>
> On Thu, Feb 22, 2024 at 06:53:12PM +0100, Cezary Rojewski wrote:
> > On 2024-02-22 6:24 PM, Ville Syrjälä wrote:
> > > On Thu, Feb 22, 2024 at 06:06:11PM +0100, Cezary Rojewski wrote:
> > > > Commit 78f613ba1efb ("drm/i915: finish removal of CNL") and its friends
> > > > removed support for i915 for all CNL-based platforms. HDAudio library,
> > > > however, still treats such platforms as valid candidates for i915
> > > > binding. Update query mechanism to reflect changes made in drm tree.
> > > >
> > > > At the same time, i915 support for LKF-based platforms has not been
> > > > provided so remove them from valid binding candidates.
> >
> > ...
> >
> > > > @@ -127,15 +128,26 @@ static int i915_component_master_match(struct
> > > > device *dev, int subcomponent,
> > > > /* check whether Intel graphics is present and reachable */
> > > > static int i915_gfx_present(struct pci_dev *hdac_pci)
> > > > {
> > > > + /* List of known platforms with no i915 support. */
> > > > + static struct pci_device_id denylist[] = {
> > > > + INTEL_CNL_IDS(NULL),
> > > > + INTEL_LKF_IDS(NULL),
> > > > + { 0 }
> > > > + };
> > >
> > > I thought these don't actually exist in the wild?
> >
> > To my knowledge the opposite is true - while LKFs were shipped in limited
> > number, they still were. I did ask few weeks ago my friends from Windows
> > side about the support and they're still running full-scopes on HDMI
> > endpoints on LKF platforms in their CIs. It seems the drm support is there
> > though. Once you re-boot to linux we get -19 during probe().
> >
> > In regard to CNL, the commit removing CNL-support left the IDs intact what's
>
> I would prefer to go the other way around and remove the unused/unsupported
> IDs entirely and for good.
>
> > very handy to us - we have a lot of spare CNL boards for our validation
> > purposes - CNL-based AudioDSP spans multiple platforms, e.g.:
> > CNL/CFL/WHL/CML. The number of newer boards is lower, unfortunately.
>
> Well, I do see your point here and you are not asking for us to add gfx
> support back, but only help to have this protection here.
>
> However I'm afraid that these entries in the list would only cause
> further confusion. Couldn't they get defined inside your .c directly as
> a const deny_list? so when we go there and remove the missing bits
> of CNL we don't conflict or cause undersired issues to you.
That makes sense. Maybe drm people would get rid of the dead CNL*()
definitions from the header as a cleanup in near future, and we'll hit
a trouble.
thanks,
Takashi
[PATCH 12/13] drm/i915/hdcp: Allocate stream id after HDCP AKE stage
Allocate stream id after HDCP AKE stage and not before so that it
can also be done during link integrity check.
Right now for MST scenarios LIC fails after hdcp enablement for this
reason.
--v2
-no need for else block in prepare_streams function [Ankit]
--v3
-remove intel_hdcp argument from required_content_stream function
[Ankit]
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 137 ++
1 file changed, 65 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 321c6dd8dbf5..9edac27bab26 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -30,7 +30,7 @@
#define KEY_LOAD_TRIES 5
#define HDCP2_LC_RETRY_CNT 3
-static int intel_conn_to_vcpi(struct drm_atomic_state *state,
+static int intel_conn_to_vcpi(struct intel_atomic_state *state,
struct intel_connector *connector)
{
struct drm_dp_mst_topology_mgr *mgr;
@@ -43,7 +43,7 @@ static int intel_conn_to_vcpi(struct drm_atomic_state *state,
return 0;
mgr = connector->port->mgr;
- drm_modeset_lock(>base.lock, state->acquire_ctx);
+ drm_modeset_lock(>base.lock, state->base.acquire_ctx);
mst_state = to_drm_dp_mst_topology_state(mgr->base.state);
payload = drm_atomic_get_mst_payload_state(mst_state, connector->port);
if (drm_WARN_ON(mgr->dev, !payload))
@@ -68,19 +68,51 @@ static int intel_conn_to_vcpi(struct drm_atomic_state
*state,
* DP MST topology. Though it is not compulsory, security fw should change its
* policy to mark different content_types for different streams.
*/
-static void
-intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
+static int
+intel_hdcp_required_content_stream(struct intel_atomic_state *state,
+ struct intel_digital_port *dig_port)
{
+ struct drm_connector_list_iter conn_iter;
+ struct intel_digital_port *conn_dig_port;
+ struct intel_connector *connector;
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct hdcp_port_data *data = _port->hdcp_port_data;
bool enforce_type0 = false;
int k;
if (dig_port->hdcp_auth_status)
- return;
+ return 0;
+
+ data->k = 0;
if (!dig_port->hdcp_mst_type1_capable)
enforce_type0 = true;
+ drm_connector_list_iter_begin(>drm, _iter);
+ for_each_intel_connector_iter(connector, _iter) {
+ if (connector->base.status == connector_status_disconnected)
+ continue;
+
+ if (!intel_encoder_is_mst(intel_attached_encoder(connector)))
+ continue;
+
+ conn_dig_port = intel_attached_dig_port(connector);
+ if (conn_dig_port != dig_port)
+ continue;
+
+ data->streams[data->k].stream_id =
+ intel_conn_to_vcpi(state, connector);
+ data->k++;
+
+ /* if there is only one active stream */
+ if (dig_port->dp.active_mst_links <= 1)
+ break;
+ }
+ drm_connector_list_iter_end(_iter);
+
+ if (drm_WARN_ON(>drm, data->k > INTEL_NUM_PIPES(i915) || data->k
== 0))
+ return -EINVAL;
+
/*
* Apply common protection level across all streams in DP MST Topology.
* Use highest supported content type for all streams in DP MST
Topology.
@@ -88,19 +120,25 @@ intel_hdcp_required_content_stream(struct
intel_digital_port *dig_port)
for (k = 0; k < data->k; k++)
data->streams[k].stream_type =
enforce_type0 ? DRM_MODE_HDCP_CONTENT_TYPE0 :
DRM_MODE_HDCP_CONTENT_TYPE1;
+
+ return 0;
}
-static void intel_hdcp_prepare_streams(struct intel_connector *connector)
+static int intel_hdcp_prepare_streams(struct intel_atomic_state *state,
+ struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct hdcp_port_data *data = _port->hdcp_port_data;
struct intel_hdcp *hdcp = >hdcp;
- if (!intel_encoder_is_mst(intel_attached_encoder(connector))) {
- data->streams[0].stream_type = hdcp->content_type;
- } else {
- intel_hdcp_required_content_stream(dig_port);
- }
+ if (intel_encoder_is_mst(intel_attached_encoder(connector)))
+ return intel_hdcp_required_content_stream(state, dig_port);
+
+ data->k = 1;
+ data->streams[0].stream_id = 0;
+ data->streams[0].stream_type = hdcp->content_type;
+
+ return 0;
}
static
@@ -1895,7 +1933,8 @@ hdcp2_propagate_stream_management_info(struct
[PATCH 07/13] drm/i915/hdcp: HDCP Capability for the downstream device
Currently we are only checking capability of remote device and not
immediate downstream device but during capability check we need are
concerned with only the HDCP capability of downstream device.
During i915_display_info reporting we need HDCP Capability for both
the monitors and downstream branch device if any this patch adds that.
--v2
-Use MST Hub HDCP version [Ankit]
--v3
-Redefined how we seprate remote and direct read to make sure HDMI
shim functions are not touched [Ankit]
--v4
- Fix the conditions so that hdcp_info with remote_req true is sent
only when encoder is mst [Ankit]
--v5
-No need to have the MST Hub version in i915_hdcp_sink_capability[Ankit]
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_debugfs.c | 21 ++-
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d8f1a23ac2b1..b99c024b0934 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -188,7 +188,8 @@ static void intel_panel_info(struct seq_file *m,
}
static void intel_hdcp_info(struct seq_file *m,
- struct intel_connector *intel_connector)
+ struct intel_connector *intel_connector,
+ bool remote_req)
{
bool hdcp_cap, hdcp2_cap;
@@ -197,8 +198,14 @@ static void intel_hdcp_info(struct seq_file *m,
goto out;
}
- hdcp_cap = intel_hdcp_get_capability(intel_connector);
- hdcp2_cap = intel_hdcp2_get_capability(intel_connector);
+ if (remote_req) {
+ intel_hdcp_get_remote_capability(intel_connector,
+_cap,
+_cap);
+ } else {
+ hdcp_cap = intel_hdcp_get_capability(intel_connector);
+ hdcp2_cap = intel_hdcp2_get_capability(intel_connector);
+ }
if (hdcp_cap)
seq_puts(m, "HDCP1.4 ");
@@ -285,7 +292,11 @@ static void intel_connector_info(struct seq_file *m,
}
seq_puts(m, "\tHDCP version: ");
- intel_hdcp_info(m, intel_connector);
+ if (intel_encoder_is_mst(encoder)) {
+ intel_hdcp_info(m, intel_connector, true);
+ seq_puts(m, "\tMST Hub HDCP version: ");
+ }
+ intel_hdcp_info(m, intel_connector, false);
seq_printf(m, "\tmax bpc: %u\n", connector->display_info.bpc);
@@ -1131,7 +1142,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file
*m, void *data)
seq_printf(m, "%s:%d HDCP version: ", connector->base.name,
connector->base.base.id);
- intel_hdcp_info(m, connector);
+ intel_hdcp_info(m, connector, false);
out:
drm_modeset_unlock(>drm.mode_config.connection_mutex);
--
2.43.2
[PATCH 11/13] drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link
Whenever LIC fails instead of moving from ENABLED to DESIRED
CP property we directly enable HDCP1.4 without informing the userspace
of this failure in link integrity check.
Now we will just update the value to DESIRED send the event to
userspace and then continue with the normal flow of HDCP enablement.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 1023153ba9d4..321c6dd8dbf5 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1088,15 +1088,9 @@ static int intel_hdcp_check_link(struct intel_connector
*connector)
goto out;
}
- ret = intel_hdcp1_enable(connector);
- if (ret) {
- drm_err(>drm, "Failed to enable hdcp (%d)\n", ret);
- intel_hdcp_update_value(connector,
- DRM_MODE_CONTENT_PROTECTION_DESIRED,
- true);
- goto out;
- }
-
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED,
+ true);
out:
mutex_unlock(_port->hdcp_mutex);
mutex_unlock(>mutex);
--
2.43.2
[PATCH 13/13] drm/i915/hdcp: Read Rxcaps for robustibility
We see some monitors and docks report incorrect hdcp version
and capability in first few reads so we read rx_caps three times
before we conclude the monitor's or docks HDCP capability
--v2
-Add comment to justify the 3 time read loop for hdcp capability[Ankit]
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 29 ++--
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 99220f970039..b98a87883fef 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -644,18 +644,29 @@ int _intel_dp_hdcp2_get_capability(struct drm_dp_aux *aux,
bool *capable)
{
u8 rx_caps[3];
- int ret;
+ int ret, i;
*capable = false;
- ret = drm_dp_dpcd_read(aux,
- DP_HDCP_2_2_REG_RX_CAPS_OFFSET,
- rx_caps, HDCP_2_2_RXCAPS_LEN);
- if (ret != HDCP_2_2_RXCAPS_LEN)
- return ret >= 0 ? -EIO : ret;
- if (rx_caps[0] == HDCP_2_2_RX_CAPS_VERSION_VAL &&
- HDCP_2_2_DP_HDCP_CAPABLE(rx_caps[2]))
- *capable = true;
+ /*
+* Some HDCP monitors act really shady by not giving the correct hdcp
+* capability on the first rx_caps read and usually take an extra read
+* to give the capability. We read rx_caps three times before we
+* declare a monitor not capable of HDCP 2.2.
+*/
+ for (i = 0; i < 3; i++) {
+ ret = drm_dp_dpcd_read(aux,
+ DP_HDCP_2_2_REG_RX_CAPS_OFFSET,
+ rx_caps, HDCP_2_2_RXCAPS_LEN);
+ if (ret != HDCP_2_2_RXCAPS_LEN)
+ return ret >= 0 ? -EIO : ret;
+
+ if (rx_caps[0] == HDCP_2_2_RX_CAPS_VERSION_VAL &&
+ HDCP_2_2_DP_HDCP_CAPABLE(rx_caps[2])) {
+ *capable = true;
+ break;
+ }
+ }
return 0;
}
--
2.43.2
[PATCH 09/13] drm/i915/hdcp: Extract hdcp structure from correct connector
Currently intel_hdcp is not being extracted from primary connector
this patch fixes that.
Fixes: 524240b231ea ("drm/i915/hdcp: Propagate aux info in DP HDCP functions")
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 16ed489e09ec..99220f970039 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -395,7 +395,9 @@ intel_dp_hdcp2_wait_for_msg(struct intel_connector
*connector,
const struct hdcp2_dp_msg_data *hdcp2_msg_data)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
- struct intel_hdcp *hdcp = >hdcp;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct intel_dp *dp = _port->dp;
+ struct intel_hdcp *hdcp = >attached_connector->hdcp;
u8 msg_id = hdcp2_msg_data->msg_id;
int ret, timeout;
bool msg_ready = false;
@@ -511,8 +513,9 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_hdcp *hdcp = >hdcp;
struct drm_dp_aux *aux = _port->dp.aux;
+ struct intel_dp *dp = _port->dp;
+ struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
--
2.43.2
[PATCH 10/13] drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link
Whenever LIC fails instead of moving from ENABLED to DESIRED
CP property we directly enable HDCP2.2 without informing the userspace
of this failure in link integrity check.
Now we will just update the value to DESIRED send the event to
userspace and then continue with the normal flow of HDCP enablement.
--v2
-Don't change the function prototype in this function [Ankit]
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 25 ++-
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 801b8f0495bb..1023153ba9d4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2068,17 +2068,6 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
drm_dbg_kms(>drm,
"HDCP2.2 Downstream topology change\n");
- ret = hdcp2_authenticate_repeater_topology(connector);
- if (!ret) {
- intel_hdcp_update_value(connector,
- DRM_MODE_CONTENT_PROTECTION_ENABLED,
- true);
- goto out;
- }
- drm_dbg_kms(>drm,
- "[CONNECTOR:%d:%s] Repeater topology auth
failed.(%d)\n",
- connector->base.base.id, connector->base.name,
- ret);
} else {
drm_dbg_kms(>drm,
"[CONNECTOR:%d:%s] HDCP2.2 link failed, retrying
auth\n",
@@ -2095,18 +2084,8 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
goto out;
}
- ret = _intel_hdcp2_enable(connector);
- if (ret) {
- drm_dbg_kms(>drm,
- "[CONNECTOR:%d:%s] Failed to enable hdcp2.2 (%d)\n",
- connector->base.base.id, connector->base.name,
- ret);
- intel_hdcp_update_value(connector,
- DRM_MODE_CONTENT_PROTECTION_DESIRED,
- true);
- goto out;
- }
-
+ intel_hdcp_update_value(connector,
+ DRM_MODE_CONTENT_PROTECTION_DESIRED, true);
out:
mutex_unlock(_port->hdcp_mutex);
mutex_unlock(>mutex);
--
2.43.2
[PATCH 08/13] drm/i915/hdcp: Remove additional timing for reading mst hdcp message
Now that we have moved back to direct reads the additional timing
is not required hence this can be removed.
--v2
-Add Fixes tag [Ankit]
Fixes: 3974f9c17bb9 ("drm/i915/hdcp: Adjust timeout for read in DPMST Scenario")
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index eab6e9fab4e6..16ed489e09ec 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -555,13 +555,8 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
/* Entire msg read timeout since initiate of msg read */
if (bytes_to_recv == size - 1 &&
hdcp2_msg_data->msg_read_timeout > 0) {
- if (intel_encoder_is_mst(connector->encoder))
- msg_end = ktime_add_ms(ktime_get_raw(),
-
hdcp2_msg_data->msg_read_timeout *
-
connector->port->parent->num_ports);
- else
- msg_end = ktime_add_ms(ktime_get_raw(),
-
hdcp2_msg_data->msg_read_timeout);
+ msg_end = ktime_add_ms(ktime_get_raw(),
+
hdcp2_msg_data->msg_read_timeout);
}
ret = drm_dp_dpcd_read(aux, offset,
--
2.43.2
[PATCH 05/13] drm/i915/hdcp: Rename hdcp capable functions
Rename hdcp_capable and hdcp_2_2_capable to hdcp_get_capability
and hdcp_2_2_get_capability to properly reflect what these functions
are doing.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_debugfs.c | 4 ++--
.../drm/i915/display/intel_display_types.h| 8 +++
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 22 +--
drivers/gpu/drm/i915/display/intel_hdcp.c | 18 +++
drivers/gpu/drm/i915/display/intel_hdcp.h | 4 ++--
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++---
6 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index a962b48bcf13..d8f1a23ac2b1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -197,8 +197,8 @@ static void intel_hdcp_info(struct seq_file *m,
goto out;
}
- hdcp_cap = intel_hdcp_capable(intel_connector);
- hdcp2_cap = intel_hdcp2_capable(intel_connector);
+ hdcp_cap = intel_hdcp_get_capability(intel_connector);
+ hdcp2_cap = intel_hdcp2_get_capability(intel_connector);
if (hdcp_cap)
seq_puts(m, "HDCP1.4 ");
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 578763e202c0..b6f86129c0bc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -498,15 +498,15 @@ struct intel_hdcp_shim {
struct intel_connector *connector);
/* Detects panel's hdcp capability. This is optional for HDMI. */
- int (*hdcp_capable)(struct intel_digital_port *dig_port,
- bool *hdcp_capable);
+ int (*hdcp_get_capability)(struct intel_digital_port *dig_port,
+ bool *hdcp_capable);
/* HDCP adaptation(DP/HDMI) required on the port */
enum hdcp_wired_protocol protocol;
/* Detects whether sink is HDCP2.2 capable */
- int (*hdcp_2_2_capable)(struct intel_connector *connector,
- bool *capable);
+ int (*hdcp_2_2_get_capability)(struct intel_connector *connector,
+ bool *capable);
/* Write HDCP2.2 messages */
int (*write_2_2_msg)(struct intel_connector *connector,
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 5394391acbe1..bf90e9024feb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -269,8 +269,8 @@ bool intel_dp_hdcp_check_link(struct intel_digital_port
*dig_port,
}
static
-int intel_dp_hdcp_capable(struct intel_digital_port *dig_port,
- bool *hdcp_capable)
+int intel_dp_hdcp_get_capability(struct intel_digital_port *dig_port,
+bool *hdcp_capable)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
ssize_t ret;
@@ -642,8 +642,8 @@ int intel_dp_hdcp2_check_link(struct intel_digital_port
*dig_port,
}
static
-int _intel_dp_hdcp2_capable(struct drm_dp_aux *aux,
- bool *capable)
+int _intel_dp_hdcp2_get_capability(struct drm_dp_aux *aux,
+ bool *capable)
{
u8 rx_caps[3];
int ret;
@@ -663,13 +663,13 @@ int _intel_dp_hdcp2_capable(struct drm_dp_aux *aux,
}
static
-int intel_dp_hdcp2_capable(struct intel_connector *connector,
- bool *capable)
+int intel_dp_hdcp2_get_capability(struct intel_connector *connector,
+ bool *capable)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_dp_aux *aux = _port->dp.aux;
- return _intel_dp_hdcp2_capable(aux, capable);
+ return _intel_dp_hdcp2_get_capability(aux, capable);
}
static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
@@ -683,12 +683,12 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
.toggle_signalling = intel_dp_hdcp_toggle_signalling,
.check_link = intel_dp_hdcp_check_link,
- .hdcp_capable = intel_dp_hdcp_capable,
+ .hdcp_get_capability = intel_dp_hdcp_get_capability,
.write_2_2_msg = intel_dp_hdcp2_write_msg,
.read_2_2_msg = intel_dp_hdcp2_read_msg,
.config_stream_type = intel_dp_hdcp2_config_stream_type,
.check_2_2_link = intel_dp_hdcp2_check_link,
- .hdcp_2_2_capable = intel_dp_hdcp2_capable,
+ .hdcp_2_2_get_capability = intel_dp_hdcp2_get_capability,
.protocol = HDCP_PROTOCOL_DP,
};
@@ -813,13 +813,13 @@ static const struct intel_hdcp_shim
[PATCH 02/13] drm/i915/hdcp: Move source hdcp2 checks into its own function
Move checks on the source side for HDCP2.2 into its own function
so that they can be used in the HDCP remote capability check
function.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c3e692e7f790..4593ac10e2fa 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -160,12 +160,14 @@ bool intel_hdcp_capable(struct intel_connector *connector)
return capable;
}
-/* Is HDCP2.2 capable on Platform and Sink */
-bool intel_hdcp2_capable(struct intel_connector *connector)
+/*
+ * Check if the source has all the building blocks ready to make
+ * HDCP 2.2 work
+ */
+static bool intel_hdcp2_prerequisite(struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
- bool capable = false;
/* I915 support for HDCP2.2 */
if (!hdcp->hdcp2_supported)
@@ -185,6 +187,18 @@ bool intel_hdcp2_capable(struct intel_connector *connector)
}
mutex_unlock(>display.hdcp.hdcp_mutex);
+ return true;
+}
+
+/* Is HDCP2.2 capable on Platform and Sink */
+bool intel_hdcp2_capable(struct intel_connector *connector)
+{
+ struct intel_hdcp *hdcp = >hdcp;
+ bool capable = false;
+
+ if (!intel_hdcp2_prerequisite(connector))
+ return false;
+
/* Sink's capability for HDCP2.2 */
hdcp->shim->hdcp_2_2_capable(connector, );
--
2.43.2
[PATCH 06/13] drm/i915/hdcp: Add new remote capability check shim function
Create a remote HDCP capability shim function which can read the
remote monitor HDCP capability when in MST configuration.
--v2
-Add an assertion to make sure only mst encoder call this remote_cap
function [Ankit]
--v3
-rename remote_hdcp_cap to remote_hdcp_capability [Jani]
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 4 +++
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 27 +++
drivers/gpu/drm/i915/display/intel_hdcp.c | 16 +++
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 +++
4 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b6f86129c0bc..8ce986fadd9a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -531,6 +531,10 @@ struct intel_hdcp_shim {
/* HDCP2.2 Link Integrity Check */
int (*check_2_2_link)(struct intel_digital_port *dig_port,
struct intel_connector *connector);
+
+ /* HDCP remote sink cap */
+ int (*get_remote_hdcp_capability)(struct intel_connector *connector,
+ bool *hdcp_capable, bool
*hdcp2_capable);
};
struct intel_hdcp {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index bf90e9024feb..eab6e9fab4e6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -672,6 +672,32 @@ int intel_dp_hdcp2_get_capability(struct intel_connector
*connector,
return _intel_dp_hdcp2_get_capability(aux, capable);
}
+static
+int intel_dp_hdcp_get_remote_capability(struct intel_connector *connector,
+ bool *hdcp_capable,
+ bool *hdcp2_capable)
+{
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct drm_dp_aux *aux = >port->aux;
+ u8 bcaps;
+ int ret;
+
+ if (!intel_encoder_is_mst(connector->encoder))
+ return -EINVAL;
+
+ ret = _intel_dp_hdcp2_get_capability(aux, hdcp2_capable);
+ if (ret)
+ return ret;
+
+ ret = intel_dp_hdcp_read_bcaps(aux, i915, );
+ if (ret)
+ return ret;
+
+ *hdcp_capable = bcaps & DP_BCAPS_HDCP_CAPABLE;
+
+ return 0;
+}
+
static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
@@ -820,6 +846,7 @@ static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim
= {
.stream_2_2_encryption = intel_dp_mst_hdcp2_stream_encryption,
.check_2_2_link = intel_dp_mst_hdcp2_check_link,
.hdcp_2_2_get_capability = intel_dp_hdcp2_get_capability,
+ .get_remote_hdcp_capability = intel_dp_hdcp_get_remote_capability,
.protocol = HDCP_PROTOCOL_DP,
};
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index c1a32f9f1199..801b8f0495bb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -205,6 +205,22 @@ bool intel_hdcp2_get_capability(struct intel_connector
*connector)
return capable;
}
+void intel_hdcp_get_remote_capability(struct intel_connector *connector,
+ bool *hdcp_capable,
+ bool *hdcp2_capable)
+{
+ struct intel_hdcp *hdcp = >hdcp;
+
+ if (!hdcp->shim->get_remote_hdcp_capability)
+ return;
+
+ hdcp->shim->get_remote_hdcp_capability(connector, hdcp_capable,
+ hdcp2_capable);
+
+ if (!intel_hdcp2_prerequisite(connector))
+ *hdcp2_capable = false;
+}
+
static bool intel_hdcp_in_use(struct drm_i915_private *i915,
enum transcoder cpu_transcoder, enum port port)
{
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index aeefb3c13d2c..477f2d2bb120 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -40,6 +40,9 @@ void intel_hdcp_update_pipe(struct intel_atomic_state *state,
bool is_hdcp_supported(struct drm_i915_private *i915, enum port port);
bool intel_hdcp_get_capability(struct intel_connector *connector);
bool intel_hdcp2_get_capability(struct intel_connector *connector);
+void intel_hdcp_get_remote_capability(struct intel_connector *connector,
+ bool *hdcp_capable,
+ bool *hdcp2_capable);
void intel_hdcp_component_init(struct drm_i915_private *i915);
void intel_hdcp_component_fini(struct drm_i915_private *i915);
void intel_hdcp_cleanup(struct intel_connector
[PATCH 04/13] drm/i915/hdcp: Pass drm_dp_aux to read_bcaps function
Pass drm_dp_aux to intel_dp_hdcp_read_bcaps function
so as to aid in reading the bcaps for the remote monitor
later on.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 6767b5338ae7..5394391acbe1 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -125,13 +125,13 @@ static int intel_dp_hdcp_read_bstatus(struct
intel_digital_port *dig_port,
}
static
-int intel_dp_hdcp_read_bcaps(struct intel_digital_port *dig_port,
+int intel_dp_hdcp_read_bcaps(struct drm_dp_aux *aux,
+struct drm_i915_private *i915,
u8 *bcaps)
{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
ssize_t ret;
- ret = drm_dp_dpcd_read(_port->dp.aux, DP_AUX_HDCP_BCAPS,
+ ret = drm_dp_dpcd_read(aux, DP_AUX_HDCP_BCAPS,
bcaps, 1);
if (ret != 1) {
drm_dbg_kms(>drm,
@@ -146,10 +146,11 @@ static
int intel_dp_hdcp_repeater_present(struct intel_digital_port *dig_port,
bool *repeater_present)
{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
ssize_t ret;
u8 bcaps;
- ret = intel_dp_hdcp_read_bcaps(dig_port, );
+ ret = intel_dp_hdcp_read_bcaps(_port->dp.aux, i915, );
if (ret)
return ret;
@@ -271,10 +272,11 @@ static
int intel_dp_hdcp_capable(struct intel_digital_port *dig_port,
bool *hdcp_capable)
{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
ssize_t ret;
u8 bcaps;
- ret = intel_dp_hdcp_read_bcaps(dig_port, );
+ ret = intel_dp_hdcp_read_bcaps(_port->dp.aux, i915, );
if (ret)
return ret;
--
2.43.2
[PATCH 00/13] HDCP MST Type1 fixes
We were seeing a blank screen whenever Type1 content was played. This was due to extra timing which was taken as we had moved to remote read and writes previously for MST scenario, which in turn was done as we were not able to do direct read and writes to the immediate downstream device. The correct flow should be that we talk only to the immediate downstream device and the rest needs to be taken care by that device. With this patch series we move back to direct reads and writes, fix the fastset setting because of which direct reads and writes to HDCP related DPCD register stopped working, derive hdcp structure correctly and increase robustability if rxcaps HDCP capability reporting. Signed-off-by: Suraj Kandpal Suraj Kandpal (13): drm/i915/hdcp: Move to direct reads for HDCP drm/i915/hdcp: Move source hdcp2 checks into its own function drm/i915/hdcp: Refactor intel_dp_hdcp2_capable drm/i915/hdcp: Pass drm_dp_aux to read_bcaps function drm/i915/hdcp: Rename hdcp capable functions drm/i915/hdcp: Add new remote capability check shim function drm/i915/hdcp: HDCP Capability for the downstream device drm/i915/hdcp: Remove additional timing for reading mst hdcp message drm/i915/hdcp: Extract hdcp structure from correct connector drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link drm/i915/hdcp: Allocate stream id after HDCP AKE stage drm/i915/hdcp: Read Rxcaps for robustibility .../drm/i915/display/intel_display_debugfs.c | 21 +- .../drm/i915/display/intel_display_types.h| 12 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 137 +++ drivers/gpu/drm/i915/display/intel_hdcp.c | 226 +- drivers/gpu/drm/i915/display/intel_hdcp.h | 7 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +- 6 files changed, 228 insertions(+), 181 deletions(-) -- 2.43.2
[PATCH 03/13] drm/i915/hdcp: Refactor intel_dp_hdcp2_capable
Break intel_dp_hdcp2_capable so that the common the code can be
reused for the remote capability check.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 92642e8d82db..6767b5338ae7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -640,11 +640,9 @@ int intel_dp_hdcp2_check_link(struct intel_digital_port
*dig_port,
}
static
-int intel_dp_hdcp2_capable(struct intel_connector *connector,
- bool *capable)
+int _intel_dp_hdcp2_capable(struct drm_dp_aux *aux,
+ bool *capable)
{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
- struct drm_dp_aux *aux = _port->dp.aux;
u8 rx_caps[3];
int ret;
@@ -662,6 +660,16 @@ int intel_dp_hdcp2_capable(struct intel_connector
*connector,
return 0;
}
+static
+int intel_dp_hdcp2_capable(struct intel_connector *connector,
+ bool *capable)
+{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = _port->dp.aux;
+
+ return _intel_dp_hdcp2_capable(aux, capable);
+}
+
static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
--
2.43.2
[PATCH 01/13] drm/i915/hdcp: Move to direct reads for HDCP
Even for MST scenarios we need to do direct reads only on the
immediate downstream device the rest of the authentication is taken
care by that device. Remote reads will only be used to check
capability of the monitors in MST topology.
--v2
-Add fixes tag [Ankit]
-Derive aux where needed rather than through a function [Ankit]
Fixes: ae4f902bb344 ("drm/i915/hdcp: Send the correct aux for DPMST HDCP
scenario")
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 31 ++--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 9dff4bdfeec8..92642e8d82db 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -333,23 +333,13 @@ static const struct hdcp2_dp_msg_data hdcp2_dp_msg_data[]
= {
0, 0 },
};
-static struct drm_dp_aux *
-intel_dp_hdcp_get_aux(struct intel_connector *connector)
-{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
-
- if (intel_encoder_is_mst(connector->encoder))
- return >port->aux;
- else
- return _port->dp.aux;
-}
-
static int
intel_dp_hdcp2_read_rx_status(struct intel_connector *connector,
u8 *rx_status)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
- struct drm_dp_aux *aux = intel_dp_hdcp_get_aux(connector);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = _port->dp.aux;
ssize_t ret;
ret = drm_dp_dpcd_read(aux,
@@ -458,8 +448,9 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = _port->dp.aux;
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
- struct drm_dp_aux *aux;
hdcp2_msg_data = get_hdcp2_dp_msg_data(*byte);
if (!hdcp2_msg_data)
@@ -467,8 +458,6 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
offset = hdcp2_msg_data->offset;
- aux = intel_dp_hdcp_get_aux(connector);
-
/* No msg_id in DP HDCP2.2 msgs */
bytes_to_write = size - 1;
byte++;
@@ -494,7 +483,8 @@ static
ssize_t get_receiver_id_list_rx_info(struct intel_connector *connector,
u32 *dev_cnt, u8 *byte)
{
- struct drm_dp_aux *aux = intel_dp_hdcp_get_aux(connector);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = _port->dp.aux;
ssize_t ret;
u8 *rx_info = byte;
@@ -520,7 +510,7 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_hdcp *hdcp = >hdcp;
- struct drm_dp_aux *aux;
+ struct drm_dp_aux *aux = _port->dp.aux;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
@@ -534,8 +524,6 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
return -EINVAL;
offset = hdcp2_msg_data->offset;
- aux = intel_dp_hdcp_get_aux(connector);
-
ret = intel_dp_hdcp2_wait_for_msg(connector, hdcp2_msg_data);
if (ret < 0)
return ret;
@@ -655,12 +643,11 @@ static
int intel_dp_hdcp2_capable(struct intel_connector *connector,
bool *capable)
{
- struct drm_dp_aux *aux;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = _port->dp.aux;
u8 rx_caps[3];
int ret;
- aux = intel_dp_hdcp_get_aux(connector);
-
*capable = false;
ret = drm_dp_dpcd_read(aux,
DP_HDCP_2_2_REG_RX_CAPS_OFFSET,
--
2.43.2
RE: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with syncing commits
> -Original Message-
> From: dri-devel On Behalf Of Imre
> Deak
> Sent: Wednesday, February 21, 2024 2:49 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Ville Syrjälä
> Subject: [PATCH v2 11/21] drm/i915/dp: Add way to get active pipes with
> syncing
> commits
>
> Add a way to get the active pipes through a given DP port by syncing against a
> related pending non-blocking commit. Atm
> intel_dp_get_active_pipes() will only try to sync a given pipe and if that
> would
> block ignore the pipe. A follow-up change enabling the DP tunnel BW allocation
> mode will need to ensure that all active pipes are returned.
>
> This change will use intel_crtc_state::uapi.commit instead of the
> corresponding
> commit in the connector state. This shouldn't make a difference, since the two
> commit objects match for an active pipe.
>
> A follow-up patchset will remove syncing during TC port reset, which should
> reset
> a port/pipe even if syncing against a commit would block.
> Syncing OTOH is not needed there, since the commit used for the reset implies
> a
> sync already. For now add a TODO comment for this.
>
> v2:
> - Add a separate function to try-sync the pipes. (Ville)
Looks Good to me.
Reviewed-by: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 27 +++
> drivers/gpu/drm/i915/display/intel_crtc.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++---
> drivers/gpu/drm/i915/display/intel_tc.c | 7 ++
> 4 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 25593f6aae7de..17ed2e62cc66a 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -654,3 +654,30 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
> out:
> intel_psr_unlock(new_crtc_state);
> }
> +
> +/**
> + * intel_crtc_try_sync_pipes - Try syncing pending commits on a set of
> +pipes
> + * @i915: i915 device object
> + * @pipe_mask: Mask of pipes to sync
> + *
> + * Try to sync a pending non-blocking commit for the provided pipes in
> + * @pipe_mask. The commit won't be synced if this would block.
> + *
> + * Return a mask of the pipes that got synced or didn't need syncing.
> + */
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> +pipe_mask) {
> + struct intel_crtc *crtc;
> + u32 synced = 0;
> +
> + for_each_intel_crtc_in_pipe_mask(>drm, crtc, pipe_mask) {
> + const struct intel_crtc_state *crtc_state =
> + to_intel_crtc_state(crtc->base.state);
> +
> + if (!crtc_state->uapi.commit ||
> + try_wait_for_completion(_state->uapi.commit-
> >hw_done))
> + synced |= BIT(crtc->pipe);
> + }
> +
> + return synced;
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> b/drivers/gpu/drm/i915/display/intel_crtc.h
> index 22d7993d1f0ba..71a5b93166da7 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> @@ -47,5 +47,6 @@ struct intel_crtc *intel_crtc_for_pipe(struct
> drm_i915_private *i915, void intel_wait_for_vblank_if_active(struct
> drm_i915_private *i915,
>enum pipe pipe);
> void intel_crtc_wait_for_next_vblank(struct intel_crtc *crtc);
> +u32 intel_crtc_try_sync_pipes(struct drm_i915_private *i915, u32
> +pipe_mask);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d9e75922ff8f5..d0452d3e534a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5048,10 +5048,6 @@ int intel_dp_get_active_pipes(struct intel_dp
> *intel_dp,
> if (!crtc_state->hw.active)
> continue;
>
> - if (conn_state->commit &&
> - !try_wait_for_completion(_state->commit->hw_done))
> - continue;
> -
> *pipe_mask |= BIT(crtc->pipe);
> }
> drm_connector_list_iter_end(_iter);
> @@ -5091,6 +5087,8 @@ int intel_dp_retrain_link(struct intel_encoder
> *encoder,
> if (ret)
> return ret;
>
> + pipe_mask &= intel_crtc_try_sync_pipes(dev_priv, pipe_mask);
> +
> if (pipe_mask == 0)
> return 0;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 6b374d481cd9e..14d17903a81f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -7,6 +7,7 @@
> #include "i915_reg.h"
> #include "intel_atomic.h"
> #include "intel_cx0_phy_regs.h"
> +#include "intel_crtc.h"
> #include "intel_ddi.h"
> #include "intel_de.h"
> #include "intel_display.h"
> @@ -1663,6 +1664,12 @@ static
