[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/edid: filter DisplayID v2.0 CTA block in audio detection (rev2)
== Series Details == Series: drm/edid: filter DisplayID v2.0 CTA block in audio detection (rev2) URL : https://patchwork.freedesktop.org/series/101565/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] [v2] drm/edid: check basic audio support on CEA extension block
From: Cooper Chiou
Tag code stored in bit7:5 for CTA block byte[3] is not the same as
CEA extension block definition. Only check CEA block has
basic audio support.
Cc: Jani Nikula
Cc: Shawn C Lee
Cc: intel-gfx
Signed-off-by: Cooper Chiou
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/drm_edid.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 561f53831e29..f07af6786cec 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4859,7 +4859,8 @@ bool drm_detect_monitor_audio(struct edid *edid)
if (!edid_ext)
goto end;
- has_audio = ((edid_ext[3] & EDID_BASIC_AUDIO) != 0);
+ has_audio = (edid_ext[0] == CEA_EXT &&
+ (edid_ext[3] & EDID_BASIC_AUDIO) != 0);
if (has_audio) {
DRM_DEBUG_KMS("Monitor has basic audio support\n");
--
2.17.1
[Intel-gfx] ✓ Fi.CI.IGT: success for Splitting up platform-specific calls (rev4)
== Series Details ==
Series: Splitting up platform-specific calls (rev4)
URL : https://patchwork.freedesktop.org/series/99126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11397_full -> Patchwork_22645_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (12 -> 12)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22645_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_cursor_legacy@pipe-c-forked-move:
- {shard-rkl}:[SKIP][1] ([i915#4070]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-rkl-1/igt@kms_cursor_leg...@pipe-c-forked-move.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-rkl-5/igt@kms_cursor_leg...@pipe-c-forked-move.html
* igt@kms_plane_multiple@atomic-pipe-a-tiling-4:
- {shard-rkl}:NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-rkl-4/igt@kms_plane_multi...@atomic-pipe-a-tiling-4.html
Known issues
Here are the changes found in Patchwork_22645_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl: NOTRUN -> [SKIP][4] ([fdo#109271]) +175 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-skl6/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-kbl7/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-glk4/igt@gem_exec_fair@basic-p...@vcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-glk5/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-iclb7/igt@gem_exec_fair@basic-p...@vecs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-iclb7/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_lmem_swapping@parallel-random:
- shard-skl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-skl6/igt@gem_lmem_swapp...@parallel-random.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-tglb: NOTRUN -> [SKIP][12] ([i915#3323])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-tglb8/igt@gem_userptr_bl...@dmabuf-sync.html
* igt@gem_userptr_blits@unsync-unmap-after-close:
- shard-tglb: NOTRUN -> [SKIP][13] ([i915#3297])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-tglb8/igt@gem_userptr_bl...@unsync-unmap-after-close.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#454])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-iclb1/igt@i915_pm...@dc6-psr.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-iclb2/igt@i915_pm...@dc6-psr.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#5286])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-tglb7/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180.html
* igt@kms_big_fb@linear-64bpp-rotate-90:
- shard-tglb: NOTRUN -> [SKIP][17] ([fdo#111614])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-tglb7/igt@kms_big...@linear-64bpp-rotate-90.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][18] ([i915#3743]) +1 similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-skl9/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@y-tiled-16bpp-rotate-0:
- shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#118]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/shard-glk4/igt@kms_big...@y-tiled-16bpp-rotate-0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/shard-glk5/igt@kms_big...@y-tiled-16bpp-rotate-0.html
*
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Split out intel_vtd_active and run_as_guest to own header
== Series Details == Series: drm/i915: Split out intel_vtd_active and run_as_guest to own header URL : https://patchwork.freedesktop.org/series/101646/ State : success == Summary == CI Bug Log - changes from CI_DRM_11396_full -> Patchwork_22644_full Summary --- **SUCCESS** No regressions found. Participating hosts (12 -> 12) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_22644_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-hang@blt: - shard-skl: NOTRUN -> [SKIP][1] ([fdo#109271]) +254 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-skl4/igt@gem_ctx_persistence@legacy-engines-h...@blt.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][2] -> [FAIL][3] ([i915#232]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-tglb6/igt@gem_...@unwedge-stress.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-tglb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-ordering: - shard-kbl: NOTRUN -> [DMESG-FAIL][4] ([i915#5076]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-kbl4/igt@gem_exec_balan...@parallel-ordering.html * igt@gem_exec_balancer@parallel-out-fence: - shard-kbl: NOTRUN -> [DMESG-WARN][5] ([i915#5076]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-kbl7/igt@gem_exec_balan...@parallel-out-fence.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([i915#4547]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-skl4/igt@gem_exec_capture@p...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-skl8/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-glk8/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-iclb3/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-tglb1/igt@gem_huc_c...@huc-copy.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-tglb7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-verify-multi: - shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-kbl3/igt@gem_lmem_swapp...@heavy-verify-multi.html * igt@gem_lmem_swapping@parallel-random: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-skl4/igt@gem_lmem_swapp...@parallel-random.html * igt@gem_lmem_swapping@parallel-random-engines: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#4613]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-iclb3/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_pxp@verify-pxp-execution-after-suspend-resume: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271]) +54 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-apl8/igt@gem_...@verify-pxp-execution-after-suspend-resume.html * igt@gem_render_copy@yf-tiled-to-vebox-x-tiled: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#768]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-iclb3/igt@gem_render_c...@yf-tiled-to-vebox-x-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#3323]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/shard-apl3/igt@gem_userptr_bl...@dmabuf-sync.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/display: Program
PIPE_MBUS_DBOX_CTL with adl-p values
URL : https://patchwork.freedesktop.org/series/101661/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11397 -> Patchwork_22649
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/index.html
Participating hosts (48 -> 43)
--
Additional (1): fi-pnv-d510
Missing(6): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 shard-rkl
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22649:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem:
- {bat-rpls-2}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/bat-rpls-2/igt@i915_selftest@l...@gem.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- {bat-adlm-1}: NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/bat-adlm-1/igt@kms_flip@basic-flip-vs-wf_vblank.html
Known issues
Here are the changes found in Patchwork_22649 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#109315]) +17
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][4] ([fdo#109271]) +57 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#5341])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- fi-glk-dsi: [DMESG-WARN][6] ([i915#2943]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@coherency:
- {bat-rpls-2}: [INCOMPLETE][8] -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-rpls-2/igt@i915_selftest@l...@coherency.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/bat-rpls-2/igt@i915_selftest@l...@coherency.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][10] ([i915#3303]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- {fi-hsw-g3258}: [INCOMPLETE][12] ([i915#4785]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22649/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#2943]: https://gitlab.freedesktop.org/drm/intel/issues/2943
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
[i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
[i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342
Build changes
-
* Linux: CI_DRM_11397 -> Patchwork_22649
CI-20190529: 20190529
CI_DRM_11397: 056d47eaf6ea753fa2e21da31f9cbd8b721bbb7b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6387: 04d012b18355b53798af5a55a8915afb1a421bba @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22649: 884f59326ca211eb5f426f730a2a44c16a073f7f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
884f59326ca2 drm/i915/display: Remove MBUS joining invalid TODOs
767486438c27 drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL
bee7df439066
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [v2,1/4] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values
== Series Details == Series: series starting with [v2,1/4] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values URL : https://patchwork.freedesktop.org/series/101661/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/4] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values
== Series Details == Series: series starting with [v2,1/4] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values URL : https://patchwork.freedesktop.org/series/101661/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: overhaul CEA data block iteration
== Series Details ==
Series: drm/edid: overhaul CEA data block iteration
URL : https://patchwork.freedesktop.org/series/101659/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11397 -> Patchwork_22648
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22648/index.html
Participating hosts (48 -> 40)
--
Missing(8): shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan fi-ctg-p8600
shard-rkl bat-jsl-2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22648 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22648/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-hsw-4770:[PASS][2] -> [SKIP][3] ([fdo#109271]) +2 similar
issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22648/fi-hsw-4770/igt@i915_pm_...@basic-pci-d3-state.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- fi-glk-dsi: [DMESG-WARN][4] ([i915#2943]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22648/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][6] ([i915#4494] / [i915#4957]) ->
[PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22648/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-4770:[INCOMPLETE][8] ([i915#3303]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22648/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][10] ([i915#3576]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-adlp-6/igt@kms_busy@ba...@flip.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22648/bat-adlp-6/igt@kms_busy@ba...@flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2943]: https://gitlab.freedesktop.org/drm/intel/issues/2943
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#5338]: https://gitlab.freedesktop.org/drm/intel/issues/5338
Build changes
-
* Linux: CI_DRM_11397 -> Patchwork_22648
CI-20190529: 20190529
CI_DRM_11397: 056d47eaf6ea753fa2e21da31f9cbd8b721bbb7b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6387: 04d012b18355b53798af5a55a8915afb1a421bba @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22648: a6b8101aaa65a5a20a66a7603f13e9173d9bcef5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a6b8101aaa65 drm/edid: sunset drm_find_cea_extension()
13cc175a8ee2 drm/edid: skip CEA extension scan in drm_edid_to_eld() just for
CEA rev
6fa348a171ae drm/edid: detect color formats and CEA revision only on CEA
extension
3fc75617d81c drm/edid: detect basic audio only on CEA extension
e3edc2173219 drm/edid: restore some type safety to cea_db_*() functions
0ba046c15f17 drm/edid: sunset the old unused cea data block iterators
bdf077ccb603 drm/edid: convert drm_edid_to_eld() to use cea db iter
ade266ca2a2d drm/edid: convert drm_parse_cea_ext() to use cea db iter
ffdd375908fd drm/edid: convert drm_detect_monitor_audio() to use cea db iter
22a1b23994a7 drm/edid: convert drm_detect_hdmi_monitor() to use cea db iter
1d63449f0022 drm/edid: convert drm_edid_to_sad() to use cea db iter
d7bef300e712 drm/edid: convert drm_edid_to_speaker_allocation() to use cea db
iter
db6dc8dd41fb drm/edid: convert add_cea_modes() to use cea db iter
8f74ddc1652a drm/edid: clean up cea_db_is_*() functions
4c530a148bfe drm/edid: add iterator for CEA data
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/edid: overhaul CEA data block iteration
== Series Details == Series: drm/edid: overhaul CEA data block iteration URL : https://patchwork.freedesktop.org/series/101659/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/rps: Centralize computation of freq caps (rev3)
== Series Details ==
Series: drm/i915/rps: Centralize computation of freq caps (rev3)
URL : https://patchwork.freedesktop.org/series/101606/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11397 -> Patchwork_22647
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22647 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22647, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/index.html
Participating hosts (48 -> 41)
--
Additional (1): fi-pnv-d510
Missing(8): shard-tglu fi-hsw-4200u shard-rkl fi-bsw-cyan fi-ctg-p8600
bat-rpls-2 bat-jsl-2 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22647:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@basic-flip-vs-wf_vblank@a-dp1:
- {bat-adlm-1}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-adlm-1/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/bat-adlm-1/igt@kms_flip@basic-flip-vs-wf_vbl...@a-dp1.html
Known issues
Here are the changes found in Patchwork_22647 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +57 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][6] -> [INCOMPLETE][7] ([i915#4418])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#5341])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@runner@aborted:
- bat-dg1-6: NOTRUN -> [FAIL][9] ([i915#4312] / [i915#5257])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/bat-dg1-6/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][10] ([i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/fi-rkl-guc/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- fi-glk-dsi: [DMESG-WARN][11] ([i915#2943]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][13] ([i915#3576]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-adlp-6/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22647/bat-adlp-6/igt@kms_busy@ba...@flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2943]: https://gitlab.freedesktop.org/drm/intel/issues/2943
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4418]: https://gitlab.freedesktop.org/drm/intel/issues/4418
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
[i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
[i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342
Build changes
-
* Linux: CI_DRM_11397 ->
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: overhaul CEA data block iteration
== Series Details == Series: drm/edid: overhaul CEA data block iteration URL : https://patchwork.freedesktop.org/series/101659/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:315:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: overhaul CEA data block iteration
== Series Details == Series: drm/edid: overhaul CEA data block iteration URL : https://patchwork.freedesktop.org/series/101659/ State : warning == Summary == $ dim checkpatch origin/drm-tip a1fd8fea9724 drm/edid: add drm_edid_extension_block_count() and drm_edid_size() a04b9a47ee0e drm: use drm_edid_extension_block_count() and drm_edid_size() -:75: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!edid" #75: FILE: drivers/gpu/drm/drm_edid.c:3356: + if (edid == NULL || drm_edid_extension_block_count(edid) == 0) total: 0 errors, 0 warnings, 1 checks, 63 lines checked a946b4b8093f drm/edid: clean up CEA data block tag definitions 0d0acb1b0708 drm/edid: add iterator for EDID base and extension blocks -:56: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #56: FILE: drivers/gpu/drm/drm_edid.c:3389: +#define drm_edid_iter_for_each(__block, __iter)\ + while (((__block) = __drm_edid_iter_next(__iter))) total: 1 errors, 0 warnings, 0 checks, 52 lines checked 4c530a148bfe drm/edid: add iterator for CEA data blocks -:219: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #219: FILE: drivers/gpu/drm/drm_edid.c:4435: +#define cea_db_iter_for_each(__db, __iter) \ + while (((__db) = __cea_db_iter_next(__iter))) total: 1 errors, 0 warnings, 0 checks, 216 lines checked 8f74ddc1652a drm/edid: clean up cea_db_is_*() functions db6dc8dd41fb drm/edid: convert add_cea_modes() to use cea db iter d7bef300e712 drm/edid: convert drm_edid_to_speaker_allocation() to use cea db iter 1d63449f0022 drm/edid: convert drm_edid_to_sad() to use cea db iter 22a1b23994a7 drm/edid: convert drm_detect_hdmi_monitor() to use cea db iter ffdd375908fd drm/edid: convert drm_detect_monitor_audio() to use cea db iter ade266ca2a2d drm/edid: convert drm_parse_cea_ext() to use cea db iter bdf077ccb603 drm/edid: convert drm_edid_to_eld() to use cea db iter 0ba046c15f17 drm/edid: sunset the old unused cea data block iterators e3edc2173219 drm/edid: restore some type safety to cea_db_*() functions 3fc75617d81c drm/edid: detect basic audio only on CEA extension -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: References: https://patchwork.freedesktop.org/patch/msgid/20220321044330.27723-1-cooper.ch...@intel.com total: 0 errors, 1 warnings, 0 checks, 27 lines checked 6fa348a171ae drm/edid: detect color formats and CEA revision only on CEA extension 13cc175a8ee2 drm/edid: skip CEA extension scan in drm_edid_to_eld() just for CEA rev a6b8101aaa65 drm/edid: sunset drm_find_cea_extension()
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/display: Remove MBUS joining invalid TODOs
On Tue, 2022-03-22 at 14:58 -0700, Caz Yokoyama wrote:
>
>
> On Tue, Mar 22, 2022 at 2:45 PM José Roberto de Souza
> wrote:
> > skl_compute_ddb() will for a modeset in all pipes when MBUS joining
> > changes between states, so all pipes will be disabled, have all
> > MBUS related registers updated and then each pipe enabled.
> >
>
> I am not clear what you want to say here. Could you rephrase above 3 lines?
Ops it should be:
skl_compute_ddb() will do a modeset in all pipes when MBUS joining changes
between atomic commits, so all pipes will be disabled, have all MBUS
related registers updated and then each pipe enabled.
>
> > So no vblank syncronization is necessary and here droping those TODOs.
> >
>
>
> dropping
> -caz
>
> >
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cf290bb704221..9ccf0f062862c 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6066,7 +6066,6 @@ skl_compute_ddb(struct intel_atomic_state *state)
> > return ret;
> >
> > if (old_dbuf_state->joined_mbus !=
> > new_dbuf_state->joined_mbus) {
> > - /* TODO: Implement vblank synchronized MBUS joining
> > changes */
> > ret = intel_modeset_all_pipes(state);
> > if (ret)
> > return ret;
> > @@ -8195,10 +8194,6 @@ static void update_mbus_pre_enable(struct
> > intel_atomic_state *state)
> > if (!HAS_MBUS_JOINING(dev_priv))
> > return;
> >
> > - /*
> > - * TODO: Implement vblank synchronized MBUS joining changes.
> > - * Must be properly coordinated with dbuf reprogramming.
> > - */
> > if (dbuf_state->joined_mbus) {
> > mbus_ctl = MBUS_HASHING_MODE_1x4 | MBUS_JOIN |
> > MBUS_JOIN_PIPE_SELECT_NONE;
> > --
> > 2.35.1
> >
>
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2)
== Series Details ==
Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2)
URL : https://patchwork.freedesktop.org/series/100851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11396_full -> Patchwork_22643_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (12 -> 12)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22643_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_softpin@overlap:
- {shard-rkl}:[PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-rkl-5/igt@gem_soft...@overlap.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-rkl-5/igt@gem_soft...@overlap.html
* igt@kms_cursor_crc@pipe-b-cursor-128x42-random:
- {shard-rkl}:[SKIP][3] ([fdo#112022] / [i915#4070]) ->
[INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-rkl-2/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-rkl-5/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html
Known issues
Here are the changes found in Patchwork_22643_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-contexts-1us:
- shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#3070])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-iclb2/igt@gem_...@in-flight-contexts-1us.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-iclb4/igt@gem_...@in-flight-contexts-1us.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-skl: [PASS][7] -> [TIMEOUT][8] ([i915#3063])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-skl8/igt@gem_...@in-flight-contexts-immediate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-skl5/igt@gem_...@in-flight-contexts-immediate.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#4525])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-iclb4/igt@gem_exec_balan...@parallel-balancer.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-iclb6/igt@gem_exec_balan...@parallel-balancer.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-kbl: NOTRUN -> [DMESG-FAIL][11] ([i915#5076])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-kbl6/igt@gem_exec_balan...@parallel-ordering.html
* igt@gem_exec_capture@pi@vcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][12] ([i915#4547])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-skl1/igt@gem_exec_capture@p...@vcs0.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-kbl1/igt@gem_exec_fair@basic-n...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-kbl7/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][15] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk: [PASS][16] -> [FAIL][17] ([i915#2842])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_whisper@basic-fds-priority-all:
- shard-apl: [PASS][18] -> [INCOMPLETE][19] ([i915#5268])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-apl4/igt@gem_exec_whis...@basic-fds-priority-all.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-apl2/igt@gem_exec_whis...@basic-fds-priority-all.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +2
similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-kbl6/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613]) +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/shard-skl6/igt@gem_lmem_swapp...@parallel-random-engines.html
*
[Intel-gfx] [PATCH v2 4/4] drm/i915/display: Remove MBUS joining invalid TODOs
skl_compute_ddb() will for a modeset in all pipes when MBUS joining
changes between states, so all pipes will be disabled, have all
MBUS related registers updated and then each pipe enabled.
So no vblank syncronization is necessary and here droping those TODOs.
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index cf290bb704221..9ccf0f062862c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6066,7 +6066,6 @@ skl_compute_ddb(struct intel_atomic_state *state)
return ret;
if (old_dbuf_state->joined_mbus != new_dbuf_state->joined_mbus)
{
- /* TODO: Implement vblank synchronized MBUS joining
changes */
ret = intel_modeset_all_pipes(state);
if (ret)
return ret;
@@ -8195,10 +8194,6 @@ static void update_mbus_pre_enable(struct
intel_atomic_state *state)
if (!HAS_MBUS_JOINING(dev_priv))
return;
- /*
-* TODO: Implement vblank synchronized MBUS joining changes.
-* Must be properly coordinated with dbuf reprogramming.
-*/
if (dbuf_state->joined_mbus) {
mbus_ctl = MBUS_HASHING_MODE_1x4 | MBUS_JOIN |
MBUS_JOIN_PIPE_SELECT_NONE;
--
2.35.1
[Intel-gfx] [PATCH v2 3/4] drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL
PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being
enabled but that could potentially cause issues as it could have
mismatching values while pipes are being enabled.
So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be
executed before the function that enables all pipes, leaving all pipes
with a matching A_CREDIT value.
While at it, also moving it to intel_pm.c as we are trying to reduce
the gigantic size of it and intel_pm.c have other MBUS programing
sequences.
v2:
- do not program PIPE_MBUS_DBOX_CTL if pipe will not be active or
when it do not needs modeset
- remove the checks to wait a vblank
BSpec: 49213
BSpec: 50343
Cc: Ville Syrjälä
Cc: Stanislav Lisovskiy
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 37 +--
drivers/gpu/drm/i915/intel_pm.c | 47
drivers/gpu/drm/i915/intel_pm.h | 1 +
3 files changed, 49 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 424cd7e9afe60..ef5076b5e7027 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1824,35 +1824,6 @@ static void glk_pipe_scaler_clock_gating_wa(struct
drm_i915_private *dev_priv,
intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe), val);
}
-static void icl_pipe_mbus_enable(struct intel_crtc *crtc, bool joined_mbus)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe;
- u32 val;
-
- val = intel_de_read(dev_priv, PIPE_MBUS_DBOX_CTL(pipe));
- val &= ~MBUS_DBOX_A_CREDIT_MASK;
- /* Wa_22010947358:adl-p */
- if (IS_ALDERLAKE_P(dev_priv))
- val |= joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
MBUS_DBOX_A_CREDIT(4);
- else
- val |= MBUS_DBOX_A_CREDIT(2);
-
- val &= ~(MBUS_DBOX_BW_CREDIT_MASK | MBUS_DBOX_B_CREDIT_MASK);
- if (IS_ALDERLAKE_P(dev_priv)) {
- val |= MBUS_DBOX_BW_CREDIT(2);
- val |= MBUS_DBOX_B_CREDIT(8);
- } else if (DISPLAY_VER(dev_priv) >= 12) {
- val |= MBUS_DBOX_BW_CREDIT(2);
- val |= MBUS_DBOX_B_CREDIT(12);
- } else {
- val |= MBUS_DBOX_BW_CREDIT(1);
- val |= MBUS_DBOX_B_CREDIT(8);
- }
-
- intel_de_write(dev_priv, PIPE_MBUS_DBOX_CTL(pipe), val);
-}
-
static void hsw_set_linetime_wm(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -1988,13 +1959,6 @@ static void hsw_crtc_enable(struct intel_atomic_state
*state,
intel_initial_watermarks(state, crtc);
- if (DISPLAY_VER(dev_priv) >= 11) {
- const struct intel_dbuf_state *dbuf_state =
- intel_atomic_get_new_dbuf_state(state);
-
- icl_pipe_mbus_enable(crtc, dbuf_state->joined_mbus);
- }
-
if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
intel_crtc_vblank_on(new_crtc_state);
@@ -8599,6 +8563,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_encoders_update_prepare(state);
intel_dbuf_pre_plane_update(state);
+ intel_mbus_dbox_update(state);
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->do_async_flip)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e60c02d760ffa..cf290bb704221 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8258,3 +8258,50 @@ void intel_dbuf_post_plane_update(struct
intel_atomic_state *state)
gen9_dbuf_slices_update(dev_priv,
new_dbuf_state->enabled_slices);
}
+
+void intel_mbus_dbox_update(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ struct intel_crtc_state *new_crtc_state;
+ struct intel_dbuf_state *new_dbuf_state;
+ struct intel_crtc *crtc;
+ int i;
+
+ if (DISPLAY_VER(i915) < 11 || !state->modeset)
+ return;
+
+ if (HAS_MBUS_JOINING(i915))
+ new_dbuf_state = intel_atomic_get_dbuf_state(state);
+
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ u32 val;
+
+ if (!new_crtc_state->hw.active ||
+ !intel_crtc_needs_modeset(new_crtc_state))
+ continue;
+
+ val = intel_de_read(i915, PIPE_MBUS_DBOX_CTL(crtc->pipe));
+ val &= ~MBUS_DBOX_A_CREDIT_MASK;
+ /* Wa_22010947358:adl-p */
+ if (IS_ALDERLAKE_P(i915))
+ val |= new_dbuf_state->joined_mbus ?
MBUS_DBOX_A_CREDIT(6) :
+
MBUS_DBOX_A_CREDIT(4);
[Intel-gfx] [PATCH v2 2/4] drm/i915/display: Add HAS_MBUS_JOINING
This will make easy to extend MBUS joining support to future platforms
that also supports this feature.
Reviewed-by: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 217c09422711b..d7f4a95006c0d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1387,6 +1387,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_PERCTX_PREEMPT_CTRL(i915) \
((GRAPHICS_VER(i915) >= 9) && GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
+#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915))
+
static inline bool run_as_guest(void)
{
return !hypervisor_is_type(X86_HYPER_NATIVE);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2c3cd4d775daf..e60c02d760ffa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6038,7 +6038,7 @@ skl_compute_ddb(struct intel_atomic_state *state)
return ret;
}
- if (IS_ALDERLAKE_P(dev_priv))
+ if (HAS_MBUS_JOINING(dev_priv))
new_dbuf_state->joined_mbus =
adlp_check_mbus_joined(new_dbuf_state->active_pipes);
@@ -6530,7 +6530,7 @@ void skl_wm_get_hw_state(struct drm_i915_private
*dev_priv)
to_intel_dbuf_state(dev_priv->dbuf.obj.state);
struct intel_crtc *crtc;
- if (IS_ALDERLAKE_P(dev_priv))
+ if (HAS_MBUS_JOINING(dev_priv))
dbuf_state->joined_mbus = intel_de_read(dev_priv, MBUS_CTL) &
MBUS_JOIN;
for_each_intel_crtc(_priv->drm, crtc) {
@@ -8192,7 +8192,7 @@ static void update_mbus_pre_enable(struct
intel_atomic_state *state)
const struct intel_dbuf_state *dbuf_state =
intel_atomic_get_new_dbuf_state(state);
- if (!IS_ALDERLAKE_P(dev_priv))
+ if (!HAS_MBUS_JOINING(dev_priv))
return;
/*
--
2.35.1
[Intel-gfx] [PATCH v2 1/4] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values
From: Caz Yokoyama
B credits set by IFWI do not match with specification default, so here
programming the right value.
Also while at it, taking the oportunity to do a read-modify-write to
not overwrite all other bits in this register that specification don't
ask us to change.
BSpec: 49213
BSpec: 50343
Cc: Matt Roper
Cc: Stanislav Lisovskiy
Cc: Jani Nikula
Signed-off-by: Caz Yokoyama
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dc6e21e4ef0b9..424cd7e9afe60 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1830,13 +1830,19 @@ static void icl_pipe_mbus_enable(struct intel_crtc
*crtc, bool joined_mbus)
enum pipe pipe = crtc->pipe;
u32 val;
+ val = intel_de_read(dev_priv, PIPE_MBUS_DBOX_CTL(pipe));
+ val &= ~MBUS_DBOX_A_CREDIT_MASK;
/* Wa_22010947358:adl-p */
if (IS_ALDERLAKE_P(dev_priv))
- val = joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
MBUS_DBOX_A_CREDIT(4);
+ val |= joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
MBUS_DBOX_A_CREDIT(4);
else
- val = MBUS_DBOX_A_CREDIT(2);
+ val |= MBUS_DBOX_A_CREDIT(2);
- if (DISPLAY_VER(dev_priv) >= 12) {
+ val &= ~(MBUS_DBOX_BW_CREDIT_MASK | MBUS_DBOX_B_CREDIT_MASK);
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ val |= MBUS_DBOX_BW_CREDIT(2);
+ val |= MBUS_DBOX_B_CREDIT(8);
+ } else if (DISPLAY_VER(dev_priv) >= 12) {
val |= MBUS_DBOX_BW_CREDIT(2);
val |= MBUS_DBOX_B_CREDIT(12);
} else {
--
2.35.1
[Intel-gfx] [RFC 16/19] drm/edid: detect basic audio only on CEA extension
The CTA data block in DisplayID does not have the bits from byte 3 that
a CEA extension has. Only look for them in CEA extensions, but also look
for them in all CEA extensions.
References:
https://patchwork.freedesktop.org/patch/msgid/20220321044330.27723-1-cooper.ch...@intel.com
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b3aedeefed82..b6675f8638bb 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4959,16 +4959,21 @@ EXPORT_SYMBOL(drm_detect_hdmi_monitor);
*/
bool drm_detect_monitor_audio(struct edid *edid)
{
+ struct drm_edid_iter edid_iter;
const struct cea_db *db;
struct cea_db_iter iter;
- const u8 *edid_ext;
+ const u8 *cea;
bool has_audio = false;
- edid_ext = drm_find_cea_extension(edid);
- if (!edid_ext)
- goto end;
-
- has_audio = ((edid_ext[3] & EDID_BASIC_AUDIO) != 0);
+ drm_edid_iter_begin(edid, _iter);
+ drm_edid_iter_for_each(cea, _iter) {
+ if (cea[0] == CEA_EXT) {
+ has_audio = cea[3] & EDID_BASIC_AUDIO;
+ if (has_audio)
+ break;
+ }
+ }
+ drm_edid_iter_end(_iter);
if (has_audio) {
DRM_DEBUG_KMS("Monitor has basic audio support\n");
--
2.30.2
[Intel-gfx] [RFC 19/19] drm/edid: sunset drm_find_cea_extension()
Convert drm_find_cea_extension() to a predicate function to check if the
EDID has a CEA extension or a DisplayID CTA data block. This is mainly
to avoid adding new users that only find the first CEA extension.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfaa21f00941..84314b65b75b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3422,30 +3422,29 @@ const u8 *drm_find_edid_extension(const struct edid
*edid,
return edid_ext;
}
-static const u8 *drm_find_cea_extension(const struct edid *edid)
+/* Return true if the EDID has a CEA extension or a DisplayID CTA data block */
+static bool drm_edid_has_cea_extension(const struct edid *edid)
{
const struct displayid_block *block;
struct displayid_iter iter;
- const u8 *cea;
int ext_index = 0;
+ bool found = false;
/* Look for a top level CEA extension block */
- /* FIXME: make callers iterate through multiple CEA ext blocks? */
- cea = drm_find_edid_extension(edid, CEA_EXT, _index);
- if (cea)
- return cea;
+ if (drm_find_edid_extension(edid, CEA_EXT, _index))
+ return true;
/* CEA blocks can also be found embedded in a DisplayID block */
displayid_iter_edid_begin(edid, );
displayid_iter_for_each(block, ) {
if (block->tag == DATA_BLOCK_CTA) {
- cea = (const u8 *)block;
+ found = true;
break;
}
}
displayid_iter_end();
- return cea;
+ return found;
}
static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8 vic)
@@ -3715,7 +3714,7 @@ add_alternate_cea_modes(struct drm_connector *connector,
struct edid *edid)
int modes = 0;
/* Don't add CEA modes if the CEA extension block is missing */
- if (!drm_find_cea_extension(edid))
+ if (!drm_edid_has_cea_extension(edid))
return 0;
/*
--
2.30.2
[Intel-gfx] [RFC 18/19] drm/edid: skip CEA extension scan in drm_edid_to_eld() just for CEA rev
The DisplayID CTA data block version does not necessarily match the CEA
revision. Simplify by postponing drm_edid_to_eld() slightly, and reusing
the CEA revision extracted by drm_parse_cea_ext().
By not bailing out early in drm_edid_to_eld() we may end up filling
meaningless data to the ELD. However, the main decision for audio is not
the ELD, but rather drm_detect_monitor_audio() called by drivers.
(Arguably a future cleanup could do that in drm_add_edid_modes() and
cache the result in the connector.)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f40427dc5236..dfaa21f00941 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4710,10 +4710,10 @@ static void clear_eld(struct drm_connector *connector)
*/
static void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
{
+ struct drm_display_info *info = >display_info;
const struct cea_db *db;
struct cea_db_iter iter;
uint8_t *eld = connector->eld;
- const u8 *cea;
int total_sad_count = 0;
int mnl;
@@ -4722,16 +4722,10 @@ static void drm_edid_to_eld(struct drm_connector
*connector, struct edid *edid)
if (!edid)
return;
- cea = drm_find_cea_extension(edid);
- if (!cea) {
- DRM_DEBUG_KMS("ELD: no CEA Extension found\n");
- return;
- }
-
mnl = get_monitor_name(edid, [DRM_ELD_MONITOR_NAME_STRING]);
DRM_DEBUG_KMS("ELD monitor %s\n", [DRM_ELD_MONITOR_NAME_STRING]);
- eld[DRM_ELD_CEA_EDID_VER_MNL] = cea[1] << DRM_ELD_CEA_EDID_VER_SHIFT;
+ eld[DRM_ELD_CEA_EDID_VER_MNL] = info->cea_rev <<
DRM_ELD_CEA_EDID_VER_SHIFT;
eld[DRM_ELD_CEA_EDID_VER_MNL] |= mnl;
eld[DRM_ELD_VER] = DRM_ELD_VER_CEA861D;
@@ -5681,8 +5675,6 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
return 0;
}
- drm_edid_to_eld(connector, edid);
-
/*
* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
* To avoid multiple parsing of same block, lets parse that map
@@ -5690,6 +5682,9 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
*/
quirks = drm_add_display_info(connector, edid);
+ /* Depends on info->cea_rev set by drm_add_display_info() above */
+ drm_edid_to_eld(connector, edid);
+
/*
* EDID spec says modes should be preferred in this order:
* - preferred detailed mode
--
2.30.2
[Intel-gfx] [RFC 17/19] drm/edid: detect color formats and CEA revision only on CEA extension
The CTA data block in DisplayID does not have the bits from byte 3 that
a CEA extension has. Only look for them in CEA extensions, but also look
for them in all CEA extensions.
The DisplayID CTA data block version does not seem to match the CEA
revision either. Ignore it for the purpose of CEA revision.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b6675f8638bb..f40427dc5236 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5293,22 +5293,31 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
const struct edid *edid)
{
struct drm_display_info *info = >display_info;
+ struct drm_edid_iter edid_iter;
const struct cea_db *db;
struct cea_db_iter iter;
- const u8 *edid_ext;
+ const u8 *cea;
- edid_ext = drm_find_cea_extension(edid);
- if (!edid_ext)
- return;
+ drm_edid_iter_begin(edid, _iter);
+ drm_edid_iter_for_each(cea, _iter) {
+ if (cea[0] != CEA_EXT)
+ continue;
- info->cea_rev = edid_ext[1];
+ if (!info->cea_rev)
+ info->cea_rev = cea[1];
- /* The existence of a CEA block should imply RGB support */
- info->color_formats = DRM_COLOR_FORMAT_RGB444;
- if (edid_ext[3] & EDID_CEA_YCRCB444)
- info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
- if (edid_ext[3] & EDID_CEA_YCRCB422)
- info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
+ if (info->cea_rev != cea[1])
+ DRM_DEBUG_KMS("CEA extension version mismatch %u !=
%u\n",
+ info->cea_rev, cea[1]);
+
+ /* The existence of a CEA block should imply RGB support */
+ info->color_formats = DRM_COLOR_FORMAT_RGB444;
+ if (cea[3] & EDID_CEA_YCRCB444)
+ info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
+ if (cea[3] & EDID_CEA_YCRCB422)
+ info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
+ }
+ drm_edid_iter_end(_iter);
cea_db_iter_edid_begin(edid, );
cea_db_iter_for_each(db, ) {
--
2.30.2
[Intel-gfx] [RFC 15/19] drm/edid: restore some type safety to cea_db_*() functions
During the transition, we accepted a void pointer for a poor C
programmer's version of polymorphism. Switch the functions to use struct
cea_db * to regain some more type safety.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0400c4024de7..b3aedeefed82 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4244,11 +4244,8 @@ struct cea_db {
u8 data[];
} __packed;
-static int cea_db_tag(const void *_db)
+static int cea_db_tag(const struct cea_db *db)
{
- /* FIXME: Transition to passing struct cea_db * everywhere. */
- const struct cea_db *db = _db;
-
return db->tag_length >> 5;
}
@@ -4411,41 +4408,41 @@ static void cea_db_iter_end(struct cea_db_iter *iter)
memset(iter, 0, sizeof(*iter));
}
-static bool cea_db_is_hdmi_vsdb(const void *db)
+static bool cea_db_is_hdmi_vsdb(const struct cea_db *db)
{
return (cea_db_is_vendor(db, HDMI_IEEE_OUI) &&
cea_db_payload_len(db) >= 5);
}
-static bool cea_db_is_hdmi_forum_vsdb(const void *db)
+static bool cea_db_is_hdmi_forum_vsdb(const struct cea_db *db)
{
return (cea_db_is_vendor(db, HDMI_FORUM_IEEE_OUI) &&
cea_db_payload_len(db) >= 7);
}
-static bool cea_db_is_microsoft_vsdb(const void *db)
+static bool cea_db_is_microsoft_vsdb(const struct cea_db *db)
{
return (cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
cea_db_payload_len(db) == 21);
}
-static bool cea_db_is_vcdb(const void *db)
+static bool cea_db_is_vcdb(const struct cea_db *db)
{
return (cea_db_is_extended_tag(db, CEA_EXT_DB_VIDEO_CAP) &&
cea_db_payload_len(db) == 2);
}
-static bool cea_db_is_y420cmdb(const void *db)
+static bool cea_db_is_y420cmdb(const struct cea_db *db)
{
return cea_db_is_extended_tag(db, CEA_EXT_DB_420_VIDEO_CAP_MAP);
}
-static bool cea_db_is_y420vdb(const void *db)
+static bool cea_db_is_y420vdb(const struct cea_db *db)
{
return cea_db_is_extended_tag(db, CEA_EXT_DB_420_VIDEO_DATA);
}
-static bool cea_db_is_hdmi_hdr_metadata_block(const void *db)
+static bool cea_db_is_hdmi_hdr_metadata_block(const struct cea_db *db)
{
return (cea_db_is_extended_tag(db, CEA_EXT_DB_HDR_STATIC_METADATA) &&
cea_db_payload_len(db) >= 3);
--
2.30.2
[Intel-gfx] [RFC 14/19] drm/edid: sunset the old unused cea data block iterators
All CEA data block iteration has now been converted to the new cea db
iterators.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 45 --
1 file changed, 45 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ccbaa91b171d..0400c4024de7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4209,48 +4209,6 @@ cea_revision(const u8 *cea)
return cea[1];
}
-static int
-cea_db_offsets(const u8 *cea, int *start, int *end)
-{
- /* DisplayID CTA extension blocks and top-level CEA EDID
-* block header definitions differ in the following bytes:
-* 1) Byte 2 of the header specifies length differently,
-* 2) Byte 3 is only present in the CEA top level block.
-*
-* The different definitions for byte 2 follow.
-*
-* DisplayID CTA extension block defines byte 2 as:
-* Number of payload bytes
-*
-* CEA EDID block defines byte 2 as:
-* Byte number (decimal) within this block where the 18-byte
-* DTDs begin. If no non-DTD data is present in this extension
-* block, the value should be set to 04h (the byte after next).
-* If set to 00h, there are no DTDs present in this block and
-* no non-DTD data.
-*/
- if (cea[0] == DATA_BLOCK_CTA) {
- /*
-* for_each_displayid_db() has already verified
-* that these stay within expected bounds.
-*/
- *start = 3;
- *end = *start + cea[2];
- } else if (cea[0] == CEA_EXT) {
- /* Data block offset in CEA extension block */
- *start = 4;
- *end = cea[2];
- if (*end == 0)
- *end = 127;
- if (*end < 4 || *end > 127)
- return -ERANGE;
- } else {
- return -EOPNOTSUPP;
- }
-
- return 0;
-}
-
/*
* CEA Data Block iterator.
*
@@ -4493,9 +4451,6 @@ static bool cea_db_is_hdmi_hdr_metadata_block(const void
*db)
cea_db_payload_len(db) >= 3);
}
-#define for_each_cea_db(cea, i, start, end) \
- for ((i) = (start); (i) < (end) && (i) +
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)])
+ 1)
-
static void drm_parse_y420cmdb_bitmap(struct drm_connector *connector,
const u8 *db)
{
--
2.30.2
[Intel-gfx] [RFC 13/19] drm/edid: convert drm_edid_to_eld() to use cea db iter
Iterate through all CEA data blocks across all CEA extensions and
DisplayID data blocks. This may gather more data than before, and if
there's duplicated data, some is overwritten by whichever comes last.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 64 +-
1 file changed, 29 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d4bf9ef09c3c..ccbaa91b171d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4758,12 +4758,12 @@ static void clear_eld(struct drm_connector *connector)
*/
static void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
{
+ const struct cea_db *db;
+ struct cea_db_iter iter;
uint8_t *eld = connector->eld;
const u8 *cea;
- const u8 *db;
int total_sad_count = 0;
int mnl;
- int dbl;
clear_eld(connector);
@@ -4789,43 +4789,37 @@ static void drm_edid_to_eld(struct drm_connector
*connector, struct edid *edid)
eld[DRM_ELD_PRODUCT_CODE0] = edid->prod_code[0];
eld[DRM_ELD_PRODUCT_CODE1] = edid->prod_code[1];
- if (cea_revision(cea) >= 3) {
- int i, start, end;
+ cea_db_iter_edid_begin(edid, );
+ cea_db_iter_for_each(db, ) {
+ const u8 *data = cea_db_data(db);
+ int len = cea_db_payload_len(db);
int sad_count;
- if (cea_db_offsets(cea, , )) {
- start = 0;
- end = 0;
- }
-
- for_each_cea_db(cea, i, start, end) {
- db = [i];
- dbl = cea_db_payload_len(db);
-
- switch (cea_db_tag(db)) {
- case CEA_DB_AUDIO:
- /* Audio Data Block, contains SADs */
- sad_count = min(dbl / 3, 15 - total_sad_count);
- if (sad_count >= 1)
- memcpy([DRM_ELD_CEA_SAD(mnl,
total_sad_count)],
- [1], sad_count * 3);
- total_sad_count += sad_count;
- break;
- case CEA_DB_SPEAKER:
- /* Speaker Allocation Data Block */
- if (dbl >= 1)
- eld[DRM_ELD_SPEAKER] = db[1];
- break;
- case CEA_DB_VENDOR:
- /* HDMI Vendor-Specific Data Block */
- if (cea_db_is_hdmi_vsdb(db))
- drm_parse_hdmi_vsdb_audio(connector,
db);
- break;
- default:
- break;
- }
+ switch (cea_db_tag(db)) {
+ case CEA_DB_AUDIO:
+ /* Audio Data Block, contains SADs */
+ sad_count = min(len / 3, 15 - total_sad_count);
+ if (sad_count >= 1)
+ memcpy([DRM_ELD_CEA_SAD(mnl,
total_sad_count)],
+ data, sad_count * 3);
+ total_sad_count += sad_count;
+ break;
+ case CEA_DB_SPEAKER:
+ /* Speaker Allocation Data Block */
+ if (len >= 1)
+ eld[DRM_ELD_SPEAKER] = data[0];
+ break;
+ case CEA_DB_VENDOR:
+ /* HDMI Vendor-Specific Data Block */
+ if (cea_db_is_hdmi_vsdb(db))
+ drm_parse_hdmi_vsdb_audio(connector, (const u8
*)db);
+ break;
+ default:
+ break;
}
}
+ cea_db_iter_end();
+
eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= total_sad_count <<
DRM_ELD_SAD_COUNT_SHIFT;
if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
--
2.30.2
[Intel-gfx] [RFC 12/19] drm/edid: convert drm_parse_cea_ext() to use cea db iter
Iterate through all CEA data blocks across all CEA extensions and
DisplayID data blocks.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 77763d94dd93..d4bf9ef09c3c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5342,8 +5342,9 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
const struct edid *edid)
{
struct drm_display_info *info = >display_info;
+ const struct cea_db *db;
+ struct cea_db_iter iter;
const u8 *edid_ext;
- int i, start, end;
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
@@ -5358,25 +5359,25 @@ static void drm_parse_cea_ext(struct drm_connector
*connector,
if (edid_ext[3] & EDID_CEA_YCRCB422)
info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
- if (cea_db_offsets(edid_ext, , ))
- return;
-
- for_each_cea_db(edid_ext, i, start, end) {
- const u8 *db = _ext[i];
+ cea_db_iter_edid_begin(edid, );
+ cea_db_iter_for_each(db, ) {
+ /* FIXME: convert parsers to use struct cea_db */
+ const u8 *data = (const u8 *)db;
if (cea_db_is_hdmi_vsdb(db))
- drm_parse_hdmi_vsdb_video(connector, db);
+ drm_parse_hdmi_vsdb_video(connector, data);
if (cea_db_is_hdmi_forum_vsdb(db))
- drm_parse_hdmi_forum_vsdb(connector, db);
+ drm_parse_hdmi_forum_vsdb(connector, data);
if (cea_db_is_microsoft_vsdb(db))
- drm_parse_microsoft_vsdb(connector, db);
+ drm_parse_microsoft_vsdb(connector, data);
if (cea_db_is_y420cmdb(db))
- drm_parse_y420cmdb_bitmap(connector, db);
+ drm_parse_y420cmdb_bitmap(connector, data);
if (cea_db_is_vcdb(db))
- drm_parse_vcdb(connector, db);
+ drm_parse_vcdb(connector, data);
if (cea_db_is_hdmi_hdr_metadata_block(db))
- drm_parse_hdr_metadata_block(connector, db);
+ drm_parse_hdr_metadata_block(connector, data);
}
+ cea_db_iter_end();
}
static
--
2.30.2
[Intel-gfx] [RFC 10/19] drm/edid: convert drm_detect_hdmi_monitor() to use cea db iter
Iterate through all CEA data blocks, not just the first CEA extension.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e341790521d6..399e69dc1aed 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4978,27 +4978,24 @@ EXPORT_SYMBOL(drm_av_sync_delay);
*/
bool drm_detect_hdmi_monitor(struct edid *edid)
{
- const u8 *edid_ext;
- int i;
- int start_offset, end_offset;
-
- edid_ext = drm_find_cea_extension(edid);
- if (!edid_ext)
- return false;
-
- if (cea_db_offsets(edid_ext, _offset, _offset))
- return false;
+ const struct cea_db *db;
+ struct cea_db_iter iter;
+ bool hdmi = false;
/*
* Because HDMI identifier is in Vendor Specific Block,
* search it from all data blocks of CEA extension.
*/
- for_each_cea_db(edid_ext, i, start_offset, end_offset) {
- if (cea_db_is_hdmi_vsdb(_ext[i]))
- return true;
+ cea_db_iter_edid_begin(edid, );
+ cea_db_iter_for_each(db, ) {
+ if (cea_db_is_hdmi_vsdb(db)) {
+ hdmi = true;
+ break;
+ }
}
+ cea_db_iter_end();
- return false;
+ return hdmi;
}
EXPORT_SYMBOL(drm_detect_hdmi_monitor);
--
2.30.2
[Intel-gfx] [RFC 11/19] drm/edid: convert drm_detect_monitor_audio() to use cea db iter
Iterate through all CEA data blocks.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 399e69dc1aed..77763d94dd93 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5013,10 +5013,10 @@ EXPORT_SYMBOL(drm_detect_hdmi_monitor);
*/
bool drm_detect_monitor_audio(struct edid *edid)
{
+ const struct cea_db *db;
+ struct cea_db_iter iter;
const u8 *edid_ext;
- int i, j;
bool has_audio = false;
- int start_offset, end_offset;
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
@@ -5029,18 +5029,21 @@ bool drm_detect_monitor_audio(struct edid *edid)
goto end;
}
- if (cea_db_offsets(edid_ext, _offset, _offset))
- goto end;
+ cea_db_iter_edid_begin(edid, );
+ cea_db_iter_for_each(db, ) {
+ if (cea_db_tag(db) == CEA_DB_AUDIO) {
+ const u8 *data = cea_db_data(db);
+ int i;
- for_each_cea_db(edid_ext, i, start_offset, end_offset) {
- if (cea_db_tag(_ext[i]) == CEA_DB_AUDIO) {
- has_audio = true;
- for (j = 1; j < cea_db_payload_len(_ext[i]) + 1; j
+= 3)
+ for (i = 0; i < cea_db_payload_len(db); i += 3)
DRM_DEBUG_KMS("CEA audio format %d\n",
- (edid_ext[i + j] >> 3) & 0xf);
- goto end;
+ (data[i] >> 3) & 0xf);
+ has_audio = true;
+ break;
}
}
+ cea_db_iter_end();
+
end:
return has_audio;
}
--
2.30.2
[Intel-gfx] [RFC 09/19] drm/edid: convert drm_edid_to_sad() to use cea db iter
Use the cea db iterator for short audio descriptors. We'll still stop at
the first audio data block, but not at the first CEA extension if that
doesn't have the info.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 34 +-
1 file changed, 9 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 992b3578a73f..e341790521d6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4854,40 +4854,21 @@ static void drm_edid_to_eld(struct drm_connector
*connector, struct edid *edid)
*/
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads)
{
+ const struct cea_db *db;
+ struct cea_db_iter iter;
int count = 0;
- int i, start, end, dbl;
- const u8 *cea;
-
- cea = drm_find_cea_extension(edid);
- if (!cea) {
- DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
- return 0;
- }
-
- if (cea_revision(cea) < 3) {
- DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
- return 0;
- }
-
- if (cea_db_offsets(cea, , )) {
- DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
- return -EPROTO;
- }
-
- for_each_cea_db(cea, i, start, end) {
- const u8 *db = [i];
+ cea_db_iter_edid_begin(edid, );
+ cea_db_iter_for_each(db, ) {
if (cea_db_tag(db) == CEA_DB_AUDIO) {
int j;
- dbl = cea_db_payload_len(db);
-
- count = dbl / 3; /* SAD is 3B */
+ count = cea_db_payload_len(db) / 3; /* SAD is 3B */
*sads = kcalloc(count, sizeof(**sads), GFP_KERNEL);
if (!*sads)
return -ENOMEM;
for (j = 0; j < count; j++) {
- const u8 *sad = [1 + j * 3];
+ const u8 *sad = >data[j * 3];
(*sads)[j].format = (sad[0] & 0x78) >> 3;
(*sads)[j].channels = sad[0] & 0x7;
@@ -4897,6 +4878,9 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads)
break;
}
}
+ cea_db_iter_end();
+
+ DRM_DEBUG_KMS("Found %d Short Audio Descriptors\n", count);
return count;
}
--
2.30.2
[Intel-gfx] [RFC 07/19] drm/edid: convert add_cea_modes() to use cea db iter
Iterate through all CEA EDID extension blocks and DisplayID CTA data
blocks to add CEA modes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 67 ++
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a0a5a7271658..d92ce5d540c3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4539,46 +4539,41 @@ static void drm_parse_y420cmdb_bitmap(struct
drm_connector *connector,
static int
add_cea_modes(struct drm_connector *connector, struct edid *edid)
{
- const u8 *cea = drm_find_cea_extension(edid);
- const u8 *db, *hdmi = NULL, *video = NULL;
- u8 dbl, hdmi_len, video_len = 0;
+ const struct cea_db *db;
+ struct cea_db_iter iter;
int modes = 0;
- if (cea && cea_revision(cea) >= 3) {
- int i, start, end;
-
- if (cea_db_offsets(cea, , ))
- return 0;
-
- for_each_cea_db(cea, i, start, end) {
- db = [i];
- dbl = cea_db_payload_len(db);
-
- if (cea_db_tag(db) == CEA_DB_VIDEO) {
- video = db + 1;
- video_len = dbl;
- modes += do_cea_modes(connector, video, dbl);
- } else if (cea_db_is_hdmi_vsdb(db)) {
- hdmi = db;
- hdmi_len = dbl;
- } else if (cea_db_is_y420vdb(db)) {
- const u8 *vdb420 = [2];
-
- /* Add 4:2:0(only) modes present in EDID */
- modes += do_y420vdb_modes(connector,
- vdb420,
- dbl - 1);
- }
+ cea_db_iter_edid_begin(edid, );
+ cea_db_iter_for_each(db, ) {
+ const u8 *hdmi = NULL, *video = NULL;
+ u8 hdmi_len = 0, video_len = 0;
+
+ if (cea_db_tag(db) == CEA_DB_VIDEO) {
+ video = cea_db_data(db);
+ video_len = cea_db_payload_len(db);
+ modes += do_cea_modes(connector, video, video_len);
+ } else if (cea_db_is_hdmi_vsdb(db)) {
+ /* FIXME: Switch to use cea_db_data() */
+ hdmi = (const u8 *)db;
+ hdmi_len = cea_db_payload_len(db);
+ } else if (cea_db_is_y420vdb(db)) {
+ const u8 *vdb420 = cea_db_data(db) + 1;
+
+ /* Add 4:2:0(only) modes present in EDID */
+ modes += do_y420vdb_modes(connector, vdb420,
+ cea_db_payload_len(db) - 1);
}
- }
- /*
-* We parse the HDMI VSDB after having added the cea modes as we will
-* be patching their flags when the sink supports stereo 3D.
-*/
- if (hdmi)
- modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len, video,
- video_len);
+ /*
+* We parse the HDMI VSDB after having added the cea modes as we
+* will be patching their flags when the sink supports stereo
+* 3D.
+*/
+ if (hdmi)
+ modes += do_hdmi_vsdb_modes(connector, hdmi, hdmi_len,
+ video, video_len);
+ }
+ cea_db_iter_end();
return modes;
}
--
2.30.2
[Intel-gfx] [RFC 08/19] drm/edid: convert drm_edid_to_speaker_allocation() to use cea db iter
Use the cea db iterator for speaker allocation. We'll still stop at the
first speaker data block, but not at the first CEA extension if that
doesn't have the info.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 47 --
1 file changed, 15 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d92ce5d540c3..992b3578a73f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4916,42 +4916,25 @@ EXPORT_SYMBOL(drm_edid_to_sad);
*/
int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb)
{
+ const struct cea_db *db;
+ struct cea_db_iter iter;
int count = 0;
- int i, start, end, dbl;
- const u8 *cea;
- cea = drm_find_cea_extension(edid);
- if (!cea) {
- DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
- return 0;
- }
-
- if (cea_revision(cea) < 3) {
- DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
- return 0;
- }
-
- if (cea_db_offsets(cea, , )) {
- DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
- return -EPROTO;
- }
-
- for_each_cea_db(cea, i, start, end) {
- const u8 *db = [i];
-
- if (cea_db_tag(db) == CEA_DB_SPEAKER) {
- dbl = cea_db_payload_len(db);
-
- /* Speaker Allocation Data Block */
- if (dbl == 3) {
- *sadb = kmemdup([1], dbl, GFP_KERNEL);
- if (!*sadb)
- return -ENOMEM;
- count = dbl;
- break;
- }
+ cea_db_iter_edid_begin(edid, );
+ cea_db_iter_for_each(db, ) {
+ if (cea_db_tag(db) == CEA_DB_SPEAKER &&
+ cea_db_payload_len(db) == 3) {
+ *sadb = kmemdup(db->data, cea_db_payload_len(db),
+ GFP_KERNEL);
+ if (!*sadb)
+ return -ENOMEM;
+ count = cea_db_payload_len(db);
+ break;
}
}
+ cea_db_iter_end();
+
+ DRM_DEBUG_KMS("Found %d Speaker Allocation Data Blocks\n", count);
return count;
}
--
2.30.2
[Intel-gfx] [RFC 05/19] drm/edid: add iterator for CEA data blocks
Add an iterator for CEA Data Blocks across CEA extensions and CTA
DisplayID Data Blocks.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 198 ++---
1 file changed, 186 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 31d132fcd0ca..c12c3cbab274 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4196,24 +4196,12 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len,
return modes;
}
-static int
-cea_db_payload_len(const u8 *db)
-{
- return db[0] & 0x1f;
-}
-
static int
cea_db_extended_tag(const u8 *db)
{
return db[1];
}
-static int
-cea_db_tag(const u8 *db)
-{
- return db[0] >> 5;
-}
-
static int
cea_revision(const u8 *cea)
{
@@ -4269,6 +4257,192 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
return 0;
}
+/*
+ * CEA Data Block iterator.
+ *
+ * Iterate through all CEA Data Blocks in both EDID CEA extensions and CTA Data
+ * Blocks in DisplayID extension blocks.
+ *
+ * struct cea_db *db:
+ * struct cea_db_iter iter;
+ *
+ * cea_db_iter_edid_begin(edid, );
+ * cea_db_iter_for_each(db, ) {
+ * // do stuff with db
+ * }
+ * cea_db_iter_end();
+ */
+struct cea_db_iter {
+ struct drm_edid_iter edid_iter;
+ struct displayid_iter displayid_iter;
+
+ /* Current Data Block Collection. */
+ const u8 *collection;
+
+ /* Current Data Block index in current collection. */
+ int index;
+
+ /* End index in current collection. */
+ int end;
+};
+
+/* CEA-861-F section 7.5 CEA Extension Version 3 and Table 43 */
+struct cea_db {
+ u8 tag_length;
+ u8 data[];
+} __packed;
+
+static int cea_db_tag(const void *_db)
+{
+ /* FIXME: Transition to passing struct cea_db * everywhere. */
+ const struct cea_db *db = _db;
+
+ return db->tag_length >> 5;
+}
+
+static int cea_db_payload_len(const void *_db)
+{
+ /* FIXME: Transition to passing struct cea_db * everywhere. */
+ const struct cea_db *db = _db;
+
+ return db->tag_length & 0x1f;
+}
+
+static const void *cea_db_data(const struct cea_db *db)
+{
+ return db->data;
+}
+
+static void cea_db_iter_edid_begin(const struct edid *edid, struct cea_db_iter
*iter)
+{
+ memset(iter, 0, sizeof(*iter));
+
+ drm_edid_iter_begin(edid, >edid_iter);
+ displayid_iter_edid_begin(edid, >displayid_iter);
+}
+
+static const struct cea_db *
+__cea_db_iter_current_block(const struct cea_db_iter *iter)
+{
+ const struct cea_db *db;
+
+ if (!iter->collection)
+ return NULL;
+
+ db = (const struct cea_db *)>collection[iter->index];
+
+ if (iter->index + sizeof(*db) <= iter->end &&
+ iter->index + sizeof(*db) + cea_db_payload_len(db) <= iter->end)
+ return db;
+
+ return NULL;
+}
+
+/*
+ * References:
+ * - VESA E-EDID v1.4
+ * - CEA-861-F section 7.5 CEA Extension Version 3
+ */
+static const void *__cea_db_iter_edid_next(struct cea_db_iter *iter)
+{
+ const u8 *ext;
+
+ drm_edid_iter_for_each(ext, >edid_iter) {
+ /* Only support CEA extension revision 3+ */
+ if (ext[0] != CEA_EXT || cea_revision(ext) < 3)
+ continue;
+
+ iter->index = 4;
+ iter->end = ext[2];
+ if (iter->end == 0)
+ iter->end = 127;
+ if (iter->end < 4 || iter->end > 127)
+ continue;
+
+ return ext;
+ }
+
+ return NULL;
+}
+
+/*
+ * References:
+ * - DisplayID v1.3 Appendix C: CEA Data Block within a DisplayID Data Block
+ * - DisplayID v2.0 section 4.10 CTA DisplayID Data Block
+ *
+ * Note that the above do not specify any connection between DisplayID Data
+ * Block revision and CEA Extension versions.
+ */
+static const void *__cea_db_iter_displayid_next(struct cea_db_iter *iter)
+{
+ const struct displayid_block *block;
+
+ displayid_iter_for_each(block, >displayid_iter) {
+ if (block->tag != DATA_BLOCK_CTA)
+ continue;
+
+ iter->index = sizeof(*block);
+ iter->end = iter->index + block->num_bytes;
+
+ return block;
+ }
+
+ return NULL;
+}
+
+static const struct cea_db *__cea_db_iter_next(struct cea_db_iter *iter)
+{
+ const struct cea_db *db;
+
+ if (iter->collection) {
+ /* Current collection should always be valid. */
+ db = __cea_db_iter_current_block(iter);
+ if (WARN_ON(!db)) {
+ iter->collection = NULL;
+ return NULL;
+ }
+
+ /* Next block in CEA Data Block Collection */
+ iter->index += sizeof(*db) + cea_db_payload_len(db);
+
+ db = __cea_db_iter_current_block(iter);
+ if
[Intel-gfx] [RFC 06/19] drm/edid: clean up cea_db_is_*() functions
Abstract helpers for matching vendor data blocks and extended tags, and
use them to simplify all the cea_db_is_*() functions.
Take void pointer as parameter to allow transitional use for both u8 *
and struct cea_db *.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 113 -
1 file changed, 37 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c12c3cbab274..a0a5a7271658 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4196,12 +4196,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector,
const u8 *db, u8 len,
return modes;
}
-static int
-cea_db_extended_tag(const u8 *db)
-{
- return db[1];
-}
-
static int
cea_revision(const u8 *cea)
{
@@ -4313,6 +4307,22 @@ static const void *cea_db_data(const struct cea_db *db)
return db->data;
}
+static bool cea_db_is_extended_tag(const struct cea_db *db, int tag)
+{
+ return (cea_db_tag(db) == CEA_DB_EXTENDED_TAG &&
+ cea_db_payload_len(db) >= 1 &&
+ db->data[0] == tag);
+}
+
+static bool cea_db_is_vendor(const struct cea_db *db, int vendor_oui)
+{
+ const u8 *data = cea_db_data(db);
+
+ return (cea_db_tag(db) == CEA_DB_VENDOR &&
+ cea_db_payload_len(db) >= 3 &&
+ oui(data[2], data[1], data[0]) == vendor_oui);
+}
+
static void cea_db_iter_edid_begin(const struct edid *edid, struct cea_db_iter
*iter)
{
memset(iter, 0, sizeof(*iter));
@@ -4443,79 +4453,44 @@ static void cea_db_iter_end(struct cea_db_iter *iter)
memset(iter, 0, sizeof(*iter));
}
-static bool cea_db_is_hdmi_vsdb(const u8 *db)
+static bool cea_db_is_hdmi_vsdb(const void *db)
{
- if (cea_db_tag(db) != CEA_DB_VENDOR)
- return false;
-
- if (cea_db_payload_len(db) < 5)
- return false;
-
- return oui(db[3], db[2], db[1]) == HDMI_IEEE_OUI;
+ return (cea_db_is_vendor(db, HDMI_IEEE_OUI) &&
+ cea_db_payload_len(db) >= 5);
}
-static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
+static bool cea_db_is_hdmi_forum_vsdb(const void *db)
{
- if (cea_db_tag(db) != CEA_DB_VENDOR)
- return false;
-
- if (cea_db_payload_len(db) < 7)
- return false;
-
- return oui(db[3], db[2], db[1]) == HDMI_FORUM_IEEE_OUI;
+ return (cea_db_is_vendor(db, HDMI_FORUM_IEEE_OUI) &&
+ cea_db_payload_len(db) >= 7);
}
-static bool cea_db_is_microsoft_vsdb(const u8 *db)
+static bool cea_db_is_microsoft_vsdb(const void *db)
{
- if (cea_db_tag(db) != CEA_DB_VENDOR)
- return false;
-
- if (cea_db_payload_len(db) != 21)
- return false;
-
- return oui(db[3], db[2], db[1]) == MICROSOFT_IEEE_OUI;
+ return (cea_db_is_vendor(db, MICROSOFT_IEEE_OUI) &&
+ cea_db_payload_len(db) == 21);
}
-static bool cea_db_is_vcdb(const u8 *db)
+static bool cea_db_is_vcdb(const void *db)
{
- if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
- return false;
-
- if (cea_db_payload_len(db) != 2)
- return false;
-
- if (cea_db_extended_tag(db) != CEA_EXT_DB_VIDEO_CAP)
- return false;
-
- return true;
+ return (cea_db_is_extended_tag(db, CEA_EXT_DB_VIDEO_CAP) &&
+ cea_db_payload_len(db) == 2);
}
-static bool cea_db_is_y420cmdb(const u8 *db)
+static bool cea_db_is_y420cmdb(const void *db)
{
- if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
- return false;
-
- if (!cea_db_payload_len(db))
- return false;
-
- if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_CAP_MAP)
- return false;
-
- return true;
+ return cea_db_is_extended_tag(db, CEA_EXT_DB_420_VIDEO_CAP_MAP);
}
-static bool cea_db_is_y420vdb(const u8 *db)
+static bool cea_db_is_y420vdb(const void *db)
{
- if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
- return false;
-
- if (!cea_db_payload_len(db))
- return false;
-
- if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_DATA)
- return false;
+ return cea_db_is_extended_tag(db, CEA_EXT_DB_420_VIDEO_DATA);
+}
- return true;
+static bool cea_db_is_hdmi_hdr_metadata_block(const void *db)
+{
+ return (cea_db_is_extended_tag(db, CEA_EXT_DB_HDR_STATIC_METADATA) &&
+ cea_db_payload_len(db) >= 3);
}
#define for_each_cea_db(cea, i, start, end) \
@@ -4651,20 +4626,6 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
mode->clock = clock;
}
-static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
-{
- if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
- return false;
-
- if (db[1] != CEA_EXT_DB_HDR_STATIC_METADATA)
- return false;
-
- if (cea_db_payload_len(db) < 3)
- return false;
-
-
[Intel-gfx] [RFC 04/19] drm/edid: add iterator for EDID base and extension blocks
Add an iterator abstraction for going through all the EDID blocks.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 46 ++
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 6c188539493e..31d132fcd0ca 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3348,6 +3348,52 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define EDID_CEA_YCRCB422 (1 << 4)
#define EDID_CEA_VCDB_QS (1 << 6)
+/*
+ * EDID base and extension block iterator.
+ *
+ * struct drm_edid_iter iter;
+ * const u8 *block;
+ *
+ * drm_edid_iter_begin(edid, );
+ * drm_edid_iter_for_each(block, ) {
+ * // do stuff with block
+ * }
+ * drm_edid_iter_end();
+ */
+struct drm_edid_iter {
+ const struct edid *edid;
+
+ /* Current block index. */
+ int index;
+};
+
+static void drm_edid_iter_begin(const struct edid *edid,
+ struct drm_edid_iter *iter)
+{
+ memset(iter, 0, sizeof(*iter));
+
+ iter->edid = edid;
+}
+
+static const void *__drm_edid_iter_next(struct drm_edid_iter *iter)
+{
+ if (!iter->edid)
+ return NULL;
+
+ if (iter->index > drm_edid_extension_block_count(iter->edid))
+ return NULL;
+
+ return (const u8 *)iter->edid + EDID_LENGTH * iter->index++;
+}
+
+#define drm_edid_iter_for_each(__block, __iter)\
+ while (((__block) = __drm_edid_iter_next(__iter)))
+
+static void drm_edid_iter_end(struct drm_edid_iter *iter)
+{
+ memset(iter, 0, sizeof(*iter));
+}
+
/*
* Search EDID for CEA extension block.
*/
--
2.30.2
[Intel-gfx] [RFC 03/19] drm/edid: clean up CEA data block tag definitions
Add prefixed names, group, sort, add references.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 59 +-
1 file changed, 32 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b96906774433..6c188539493e 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3329,15 +3329,20 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
return closure.modes;
}
-#define AUDIO_BLOCK0x01
-#define VIDEO_BLOCK 0x02
-#define VENDOR_BLOCK0x03
-#define SPEAKER_BLOCK 0x04
-#define HDR_STATIC_METADATA_BLOCK 0x6
-#define USE_EXTENDED_TAG 0x07
-#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
-#define EXT_VIDEO_DATA_BLOCK_420 0x0E
-#define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
+/* CEA-861-F Table 44 CEA Data Block Tag Codes */
+#define CEA_DB_AUDIO 1
+#define CEA_DB_VIDEO 2
+#define CEA_DB_VENDOR 3
+#define CEA_DB_SPEAKER 4
+#define CEA_DB_EXTENDED_TAG7
+
+/* CEA-861-F Table 46 CEA Data Block Tag Codes */
+#define CEA_EXT_DB_VIDEO_CAP 0
+#define CEA_EXT_DB_VENDOR 1
+#define CEA_EXT_DB_HDR_STATIC_METADATA 6 /* CEA-861.3 2005 */
+#define CEA_EXT_DB_420_VIDEO_DATA 14
+#define CEA_EXT_DB_420_VIDEO_CAP_MAP 15
+
#define EDID_BASIC_AUDIO (1 << 6)
#define EDID_CEA_YCRCB444 (1 << 5)
#define EDID_CEA_YCRCB422 (1 << 4)
@@ -4220,7 +4225,7 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
static bool cea_db_is_hdmi_vsdb(const u8 *db)
{
- if (cea_db_tag(db) != VENDOR_BLOCK)
+ if (cea_db_tag(db) != CEA_DB_VENDOR)
return false;
if (cea_db_payload_len(db) < 5)
@@ -4231,7 +4236,7 @@ static bool cea_db_is_hdmi_vsdb(const u8 *db)
static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
{
- if (cea_db_tag(db) != VENDOR_BLOCK)
+ if (cea_db_tag(db) != CEA_DB_VENDOR)
return false;
if (cea_db_payload_len(db) < 7)
@@ -4242,7 +4247,7 @@ static bool cea_db_is_hdmi_forum_vsdb(const u8 *db)
static bool cea_db_is_microsoft_vsdb(const u8 *db)
{
- if (cea_db_tag(db) != VENDOR_BLOCK)
+ if (cea_db_tag(db) != CEA_DB_VENDOR)
return false;
if (cea_db_payload_len(db) != 21)
@@ -4253,13 +4258,13 @@ static bool cea_db_is_microsoft_vsdb(const u8 *db)
static bool cea_db_is_vcdb(const u8 *db)
{
- if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
return false;
if (cea_db_payload_len(db) != 2)
return false;
- if (cea_db_extended_tag(db) != EXT_VIDEO_CAPABILITY_BLOCK)
+ if (cea_db_extended_tag(db) != CEA_EXT_DB_VIDEO_CAP)
return false;
return true;
@@ -4267,13 +4272,13 @@ static bool cea_db_is_vcdb(const u8 *db)
static bool cea_db_is_y420cmdb(const u8 *db)
{
- if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
return false;
if (!cea_db_payload_len(db))
return false;
- if (cea_db_extended_tag(db) != EXT_VIDEO_CAP_BLOCK_Y420CMDB)
+ if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_CAP_MAP)
return false;
return true;
@@ -4281,13 +4286,13 @@ static bool cea_db_is_y420cmdb(const u8 *db)
static bool cea_db_is_y420vdb(const u8 *db)
{
- if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
return false;
if (!cea_db_payload_len(db))
return false;
- if (cea_db_extended_tag(db) != EXT_VIDEO_DATA_BLOCK_420)
+ if (cea_db_extended_tag(db) != CEA_EXT_DB_420_VIDEO_DATA)
return false;
return true;
@@ -4354,7 +4359,7 @@ add_cea_modes(struct drm_connector *connector, struct
edid *edid)
db = [i];
dbl = cea_db_payload_len(db);
- if (cea_db_tag(db) == VIDEO_BLOCK) {
+ if (cea_db_tag(db) == CEA_DB_VIDEO) {
video = db + 1;
video_len = dbl;
modes += do_cea_modes(connector, video, dbl);
@@ -4428,10 +4433,10 @@ static void fixup_detailed_cea_mode_clock(struct
drm_display_mode *mode)
static bool cea_db_is_hdmi_hdr_metadata_block(const u8 *db)
{
- if (cea_db_tag(db) != USE_EXTENDED_TAG)
+ if (cea_db_tag(db) != CEA_DB_EXTENDED_TAG)
return false;
- if (db[1] != HDR_STATIC_METADATA_BLOCK)
+ if (db[1] != CEA_EXT_DB_HDR_STATIC_METADATA)
return false;
if (cea_db_payload_len(db) < 3)
@@ -4622,7 +4627,7 @@ static void drm_edid_to_eld(struct drm_connector
*connector, struct edid *edid)
dbl = cea_db_payload_len(db);
[Intel-gfx] [RFC 02/19] drm: use drm_edid_extension_block_count() and drm_edid_size()
Use the block count and size helpers in all drm core code.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_debugfs.c | 3 +--
drivers/gpu/drm/drm_edid.c | 14 +++---
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 76a8c707c34b..cfed43e61380 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2138,7 +2138,7 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
return 0;
if (edid)
- size = EDID_LENGTH * (1 + edid->extensions);
+ size = drm_edid_size(edid);
/* Set the display info, using edid if available, otherwise
* resetting the values to defaults. This duplicates the work
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 7f1b82dbaebb..a832ef6b33fe 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -362,8 +362,7 @@ static ssize_t edid_write(struct file *file, const char
__user *ubuf,
if (len == 5 && !strncmp(buf, "reset", 5)) {
connector->override_edid = false;
ret = drm_connector_update_edid_property(connector, NULL);
- } else if (len < EDID_LENGTH ||
- EDID_LENGTH * (1 + edid->extensions) > len)
+ } else if (len < EDID_LENGTH || drm_edid_size(edid) > len)
ret = -EINVAL;
else {
connector->override_edid = false;
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f4b49693e666..b96906774433 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1643,8 +1643,8 @@ bool drm_edid_are_equal(const struct edid *edid1, const
struct edid *edid2)
return false;
if (edid1) {
- edid1_len = EDID_LENGTH * (1 + edid1->extensions);
- edid2_len = EDID_LENGTH * (1 + edid2->extensions);
+ edid1_len = drm_edid_size(edid1);
+ edid2_len = drm_edid_size(edid2);
if (edid1_len != edid2_len)
return false;
@@ -1770,7 +1770,7 @@ bool drm_edid_is_valid(struct edid *edid)
if (!edid)
return false;
- for (i = 0; i <= edid->extensions; i++)
+ for (i = 0; i <= drm_edid_extension_block_count(edid); i++)
if (!drm_edid_block_valid(raw + i * EDID_LENGTH, i, true, NULL))
return false;
@@ -2224,7 +2224,7 @@ EXPORT_SYMBOL(drm_edid_size);
*/
struct edid *drm_edid_duplicate(const struct edid *edid)
{
- return kmemdup(edid, (edid->extensions + 1) * EDID_LENGTH, GFP_KERNEL);
+ return kmemdup(edid, drm_edid_size(edid), GFP_KERNEL);
}
EXPORT_SYMBOL(drm_edid_duplicate);
@@ -3353,17 +3353,17 @@ const u8 *drm_find_edid_extension(const struct edid
*edid,
int i;
/* No EDID or EDID extensions */
- if (edid == NULL || edid->extensions == 0)
+ if (edid == NULL || drm_edid_extension_block_count(edid) == 0)
return NULL;
/* Find CEA extension */
- for (i = *ext_index; i < edid->extensions; i++) {
+ for (i = *ext_index; i < drm_edid_extension_block_count(edid); i++) {
edid_ext = (const u8 *)edid + EDID_LENGTH * (i + 1);
if (edid_ext[0] == ext_id)
break;
}
- if (i >= edid->extensions)
+ if (i >= drm_edid_extension_block_count(edid))
return NULL;
*ext_index = i + 1;
--
2.30.2
[Intel-gfx] [RFC 01/19] drm/edid: add drm_edid_extension_block_count() and drm_edid_size()
Add abstractions for getting the number of EDID extension blocks and the
total EDID size in bytes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 18 ++
include/drm/drm_edid.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 561f53831e29..f4b49693e666 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2198,6 +2198,24 @@ struct edid *drm_get_edid_switcheroo(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_get_edid_switcheroo);
+/**
+ * drm_edid_extension_block_count - get the number of EDID extension blocks
+ */
+u8 drm_edid_extension_block_count(const struct edid *edid)
+{
+ return edid->extensions;
+}
+EXPORT_SYMBOL(drm_edid_extension_block_count);
+
+/**
+ * drm_edid_size - get the EDID size in bytes
+ */
+size_t drm_edid_size(const struct edid *edid)
+{
+ return (drm_edid_extension_block_count(edid) + 1) * EDID_LENGTH;
+}
+EXPORT_SYMBOL(drm_edid_size);
+
/**
* drm_edid_duplicate - duplicate an EDID and the extensions
* @edid: EDID to duplicate
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 144c495b99c4..7a19daa00c0c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -564,6 +564,8 @@ struct edid *drm_get_edid(struct drm_connector *connector,
u32 drm_edid_get_panel_id(struct i2c_adapter *adapter);
struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
struct i2c_adapter *adapter);
+u8 drm_edid_extension_block_count(const struct edid *edid);
+size_t drm_edid_size(const struct edid *edid);
struct edid *drm_edid_duplicate(const struct edid *edid);
int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
int drm_add_override_edid_modes(struct drm_connector *connector);
--
2.30.2
[Intel-gfx] [RFC 00/19] drm/edid: overhaul CEA data block iteration
Add iterators for EDID blocks and CEA data blocks, to iterate through all data blocks across all CEA extensions and CTA blocks in DisplayID data blocks. Fix all code assuming only one CEA extension. Fix code assuming CTA blocks contain everything that CEA extensions do. Sprinkle a bunch of cleanups on top. This is completely UNTESTED, didn't even smoke test it. It builds. ;) This superseeds parts of [1] and [2]. BR, Jani. [1] https://patchwork.freedesktop.org/series/101241/ [2] https://patchwork.freedesktop.org/patch/msgid/20220321044330.27723-1-cooper.ch...@intel.com Cc: Shawn C Lee Cc: Cooper Chiou Cc: william.ts...@intel.com Cc: ankit.k.nauti...@intel.com Cc: ville.syrj...@linux.intel.com Cc: Drew Davenport Jani Nikula (19): drm/edid: add drm_edid_extension_block_count() and drm_edid_size() drm: use drm_edid_extension_block_count() and drm_edid_size() drm/edid: clean up CEA data block tag definitions drm/edid: add iterator for EDID base and extension blocks drm/edid: add iterator for CEA data blocks drm/edid: clean up cea_db_is_*() functions drm/edid: convert add_cea_modes() to use cea db iter drm/edid: convert drm_edid_to_speaker_allocation() to use cea db iter drm/edid: convert drm_edid_to_sad() to use cea db iter drm/edid: convert drm_detect_hdmi_monitor() to use cea db iter drm/edid: convert drm_detect_monitor_audio() to use cea db iter drm/edid: convert drm_parse_cea_ext() to use cea db iter drm/edid: convert drm_edid_to_eld() to use cea db iter drm/edid: sunset the old unused cea data block iterators drm/edid: restore some type safety to cea_db_*() functions drm/edid: detect basic audio only on CEA extension drm/edid: detect color formats and CEA revision only on CEA extension drm/edid: skip CEA extension scan in drm_edid_to_eld() just for CEA rev drm/edid: sunset drm_find_cea_extension() drivers/gpu/drm/drm_connector.c | 2 +- drivers/gpu/drm/drm_debugfs.c | 3 +- drivers/gpu/drm/drm_edid.c | 781 ++-- include/drm/drm_edid.h | 2 + 4 files changed, 455 insertions(+), 333 deletions(-) -- 2.30.2
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/rps: Centralize computation of freq caps (rev3)
== Series Details == Series: drm/i915/rps: Centralize computation of freq caps (rev3) URL : https://patchwork.freedesktop.org/series/101606/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/rps: Centralize computation of freq caps (rev3)
== Series Details == Series: drm/i915/rps: Centralize computation of freq caps (rev3) URL : https://patchwork.freedesktop.org/series/101606/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH] drm/i915/rps: Centralize computation of freq caps
Freq caps (i.e. RP0, RP1 and RPn frequencies) are read from HW. However the
formats (bit positions, widths, registers and units) of these vary for
different generations with even more variations arriving in the future. In
order not to have to do identical computation for these caps in multiple
places, here we centralize the computation of these caps. This makes the
code cleaner and also more extensible for the future.
v2: Clarify that caps are in "hw units" in comments (Lucas De Marchi)
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 24 +
drivers/gpu/drm/i915/gt/intel_rps.c | 101 ++
drivers/gpu/drm/i915/gt/intel_rps.h | 2 +-
drivers/gpu/drm/i915/gt/intel_rps_types.h | 10 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 14 +--
5 files changed, 79 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 31dbb2b96738..f5fbb74ed076 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -342,17 +342,16 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt,
struct drm_printer *p)
} else if (GRAPHICS_VER(i915) >= 6) {
u32 rp_state_limits;
u32 gt_perf_status;
- u32 rp_state_cap;
+ struct intel_rps_freq_caps caps;
u32 rpmodectl, rpinclimit, rpdeclimit;
u32 rpstat, cagf, reqf;
u32 rpcurupei, rpcurup, rpprevup;
u32 rpcurdownei, rpcurdown, rpprevdown;
u32 rpupei, rpupt, rpdownei, rpdownt;
u32 pm_ier, pm_imr, pm_isr, pm_iir, pm_mask;
- int max_freq;
rp_state_limits = intel_uncore_read(uncore,
GEN6_RP_STATE_LIMITS);
- rp_state_cap = intel_rps_read_state_cap(rps);
+ intel_rps_get_freq_caps(rps, );
if (IS_GEN9_LP(i915))
gt_perf_status = intel_uncore_read(uncore,
BXT_GT_PERF_STATUS);
else
@@ -474,25 +473,12 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt,
struct drm_printer *p)
drm_printf(p, "RP DOWN THRESHOLD: %d (%lldns)\n",
rpdownt, intel_gt_pm_interval_to_ns(gt, rpdownt));
- max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 0 :
- rp_state_cap >> 16) & 0xff;
- max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
drm_printf(p, "Lowest (RPN) frequency: %dMHz\n",
- intel_gpu_freq(rps, max_freq));
-
- max_freq = (rp_state_cap & 0xff00) >> 8;
- max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
+ intel_gpu_freq(rps, caps.min_freq));
drm_printf(p, "Nominal (RP1) frequency: %dMHz\n",
- intel_gpu_freq(rps, max_freq));
-
- max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 16 :
- rp_state_cap >> 0) & 0xff;
- max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
+ intel_gpu_freq(rps, caps.rp1_freq));
drm_printf(p, "Max non-overclocked (RP0) frequency: %dMHz\n",
- intel_gpu_freq(rps, max_freq));
+ intel_gpu_freq(rps, caps.rp0_freq));
drm_printf(p, "Max overclocked frequency: %dMHz\n",
intel_gpu_freq(rps, rps->max_freq));
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 6c9fdf7906c5..4528da9db590 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1070,23 +1070,59 @@ int intel_rps_set(struct intel_rps *rps, u8 val)
return 0;
}
-static void gen6_rps_init(struct intel_rps *rps)
+static u32 intel_rps_read_state_cap(struct intel_rps *rps)
{
struct drm_i915_private *i915 = rps_to_i915(rps);
- u32 rp_state_cap = intel_rps_read_state_cap(rps);
+ struct intel_uncore *uncore = rps_to_uncore(rps);
- /* All of these values are in units of 50MHz */
+ if (IS_XEHPSDV(i915))
+ return intel_uncore_read(uncore, XEHPSDV_RP_STATE_CAP);
+ else if (IS_GEN9_LP(i915))
+ return intel_uncore_read(uncore, BXT_RP_STATE_CAP);
+ else
+ return intel_uncore_read(uncore, GEN6_RP_STATE_CAP);
+}
+
+/* "Caps" frequencies should be converted to MHz using intel_gpu_freq() */
+void intel_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps
*caps)
+{
+ struct drm_i915_private *i915 = rps_to_i915(rps);
+ u32 rp_state_cap;
+
+ rp_state_cap =
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/rps: Centralize computation of freq caps (rev2)
== Series Details ==
Series: drm/i915/rps: Centralize computation of freq caps (rev2)
URL : https://patchwork.freedesktop.org/series/101606/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11397 -> Patchwork_22646
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22646/index.html
Participating hosts (47 -> 42)
--
Missing(5): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22646:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@basic-flip-vs-wf_vblank@b-dp1:
- {bat-adlm-1}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-adlm-1/igt@kms_flip@basic-flip-vs-wf_vbl...@b-dp1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22646/bat-adlm-1/igt@kms_flip@basic-flip-vs-wf_vbl...@b-dp1.html
Known issues
Here are the changes found in Patchwork_22646 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- fi-glk-dsi: [DMESG-WARN][3] ([i915#2943]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22646/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][5] ([i915#4494] / [i915#4957]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22646/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][7] ([i915#3576]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-adlp-6/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22646/bat-adlp-6/igt@kms_busy@ba...@flip.html
Warnings
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][9] ([i915#3303]) -> [INCOMPLETE][10]
([i915#4785])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22646/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2943]: https://gitlab.freedesktop.org/drm/intel/issues/2943
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
[i915#5340]: https://gitlab.freedesktop.org/drm/intel/issues/5340
[i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342
Build changes
-
* Linux: CI_DRM_11397 -> Patchwork_22646
CI-20190529: 20190529
CI_DRM_11397: 056d47eaf6ea753fa2e21da31f9cbd8b721bbb7b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6387: 04d012b18355b53798af5a55a8915afb1a421bba @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22646: 3df3df4064ea1abc90f22133e583a4bda029e1f9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3df3df4064ea drm/i915/rps: Centralize computation of freq caps
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22646/index.html
[Intel-gfx] ✗ Fi.CI.IGT: failure for Handle the DG2 max bw properly
== Series Details ==
Series: Handle the DG2 max bw properly
URL : https://patchwork.freedesktop.org/series/101635/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11396_full -> Patchwork_22642_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22642_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22642_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (12 -> 12)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22642_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-suspend@a-vga1:
- shard-snb: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-snb4/igt@kms_flip@flip-vs-susp...@a-vga1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-snb4/igt@kms_flip@flip-vs-susp...@a-vga1.html
*
igt@kms_plane_scaling@scaler-with-pixel-format-unity-scaling@pipe-b-edp-1-scaler-with-pixel-format:
- shard-iclb: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-iclb3/igt@kms_plane_scaling@scaler-with-pixel-format-unity-scal...@pipe-b-edp-1-scaler-with-pixel-format.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-iclb2/igt@kms_plane_scaling@scaler-with-pixel-format-unity-scal...@pipe-b-edp-1-scaler-with-pixel-format.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rps@waitboost:
- {shard-rkl}:[PASS][5] -> [INCOMPLETE][6] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-rkl-6/igt@i915_pm_...@waitboost.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-rkl-5/igt@i915_pm_...@waitboost.html
* igt@kms_color@pipe-d-deep-color:
- {shard-rkl}:NOTRUN -> [SKIP][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-rkl-4/igt@kms_co...@pipe-d-deep-color.html
* igt@kms_cursor_crc@pipe-b-cursor-64x64-random:
- {shard-rkl}:[SKIP][8] ([fdo#112022] / [i915#4070]) ->
[INCOMPLETE][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-rkl-2/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-rkl-5/igt@kms_cursor_...@pipe-b-cursor-64x64-random.html
Known issues
Here are the changes found in Patchwork_22642_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#232])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-tglb6/igt@gem_...@unwedge-stress.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-tglb5/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][12] -> [TIMEOUT][13] ([i915#2481] /
[i915#3070])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-iclb4/igt@gem_...@unwedge-stress.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-iclb2/igt@gem_...@unwedge-stress.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-kbl: NOTRUN -> [DMESG-FAIL][14] ([i915#5076])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-kbl1/igt@gem_exec_balan...@parallel-ordering.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][15] ([i915#5076])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-kbl7/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_capture@pi@vcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][16] ([i915#4547])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-skl9/igt@gem_exec_capture@p...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][17] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk: [PASS][18] -> [FAIL][19] ([i915#2842])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/shard-glk1/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: NOTRUN -> [FAIL][20] ([i915#2842]) +3 similar issues
[20]:
Re: [Intel-gfx] [PATCH v11 0/5] Add driver for GSC controller
Can you re-send this series with an added patch to force CONFIG_INTEL_MEI_GSC to be selected for CI? we don't need to review or merge that additional patch, but I want to make sure we get CI results with the config turned on before we merge this series. I'm also going to ping the CI team to see if we can turn it on by default for CI builds. Daniele On 3/15/2022 6:11 AM, Alexander Usyskin wrote: GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. This series includes instantiation of the auxiliary devices for HECI2 and mei-gsc auxiliary device driver that binds to the auxiliary device. The prinicpal user of this interface is the Intel Graphics System Controller Firmware Update Library (IGSC FU) (https://github.com/intel/igsc) In v2 the platform device was replaced by the auxiliary device. v3 is the rebase over drm-tip to make public CI running. In v4 the not needed debug prints and empty line were removed, 'select' were replaced by 'depends on' in MEI Kconfig, the new include file now listed in the MAINTATINERS file. V5, rebase and add Greg KH Reviewed-by V6, rebase and drop redundant assignments found by the kernel test robot. V7, add Greg KH Reviewed-by to the individual patches V8, address Tvrtko comments for i915 V9, rebase and address more Tvrtko comments, use drm error printing V10, rebase V11, address Rodrigo comments about code style, set missed mask in the interrupt config, add explicit devm_irq_free to error and remove flows Tomas, please look at the devm_irq_free part. Alexander Usyskin (2): mei: gsc: setup char driver alive in spite of firmware handshake failure mei: gsc: retrieve the firmware version Tomas Winkler (3): drm/i915/gsc: add gsc as a mei auxiliary device mei: add support for graphics system controller (gsc) devices mei: gsc: add runtime pm handlers MAINTAINERS | 1 + drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile| 3 + drivers/gpu/drm/i915/gt/intel_gsc.c | 204 ++ drivers/gpu/drm/i915/gt/intel_gsc.h | 37 drivers/gpu/drm/i915/gt/intel_gt.c | 3 + drivers/gpu/drm/i915/gt/intel_gt.h | 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 + drivers/gpu/drm/i915/i915_drv.h | 8 + drivers/gpu/drm/i915/i915_pci.c | 3 +- drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_device_info.h | 2 + drivers/misc/mei/Kconfig | 14 ++ drivers/misc/mei/Makefile| 3 + drivers/misc/mei/bus-fixup.c | 25 +++ drivers/misc/mei/gsc-me.c| 259 +++ drivers/misc/mei/hw-me.c | 29 ++- drivers/misc/mei/hw-me.h | 2 + include/linux/mei_aux.h | 19 ++ 21 files changed, 633 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.h create mode 100644 drivers/misc/mei/gsc-me.c create mode 100644 include/linux/mei_aux.h
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/rps: Centralize computation of freq caps (rev2)
== Series Details == Series: drm/i915/rps: Centralize computation of freq caps (rev2) URL : https://patchwork.freedesktop.org/series/101606/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/rps: Centralize computation of freq caps (rev2)
== Series Details == Series: drm/i915/rps: Centralize computation of freq caps (rev2) URL : https://patchwork.freedesktop.org/series/101606/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/rps: Centralize computation of freq caps (rev2)
== Series Details == Series: drm/i915/rps: Centralize computation of freq caps (rev2) URL : https://patchwork.freedesktop.org/series/101606/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3df3df4064ea drm/i915/rps: Centralize computation of freq caps -:265: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each line #265: FILE: drivers/gpu/drm/i915/gt/intel_rps_types.h:43: + * should be used to convert to MHz +*/ total: 0 errors, 1 warnings, 0 checks, 254 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for Splitting up platform-specific calls (rev4)
== Series Details ==
Series: Splitting up platform-specific calls (rev4)
URL : https://patchwork.freedesktop.org/series/99126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11397 -> Patchwork_22645
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/index.html
Participating hosts (47 -> 42)
--
Additional (1): fi-pnv-d510
Missing(6): shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22645 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@semaphore:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-hsw-4770/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271]) +57 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@hangcheck:
- fi-ivb-3770:[PASS][3] -> [INCOMPLETE][4] ([i915#3303])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#5341])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@runner@aborted:
- fi-ivb-3770:NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#4312])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-ivb-3770/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- fi-glk-dsi: [DMESG-WARN][7] ([i915#2943]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][9] ([i915#3303]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- {fi-hsw-g3258}: [INCOMPLETE][11] ([i915#4785]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][13] ([i915#3576]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11397/bat-adlp-6/igt@kms_busy@ba...@flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22645/bat-adlp-6/igt@kms_busy@ba...@flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#2943]: https://gitlab.freedesktop.org/drm/intel/issues/2943
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#5338]: https://gitlab.freedesktop.org/drm/intel/issues/5338
[i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
[i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
[i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342
Build changes
-
* Linux: CI_DRM_11397 -> Patchwork_22645
CI-20190529: 20190529
CI_DRM_11397: 056d47eaf6ea753fa2e21da31f9cbd8b721bbb7b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6387: 04d012b18355b53798af5a55a8915afb1a421bba @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22645: 8c36847c714ec64055b468bb8327a5937fe5c4f9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8c36847c714e i915/drm: Split run_as_guest into x86 and non-x86
== Logs ==
For more details see:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix up DP DFP 4:2:0 handling more (rev2)
== Series Details ==
Series: drm/i915: Fix up DP DFP 4:2:0 handling more (rev2)
URL : https://patchwork.freedesktop.org/series/95881/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11396_full -> Patchwork_22641_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (12 -> 12)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22641_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- {shard-rkl}:[SKIP][1] ([i915#1845] / [i915#4098]) ->
[INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-rkl-1/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-rkl-5/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
- {shard-rkl}:[SKIP][3] ([i915#1849] / [i915#4098]) ->
[INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-rkl-5/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-rkl-5/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b.html
* igt@perf_pmu@enable-race@rcs0:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-rkl-5/igt@perf_pmu@enable-r...@rcs0.html
Known issues
Here are the changes found in Patchwork_22641_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#232])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-tglb6/igt@gem_...@unwedge-stress.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-tglb5/igt@gem_...@unwedge-stress.html
- shard-skl: [PASS][8] -> [TIMEOUT][9] ([i915#3063])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-skl10/igt@gem_...@unwedge-stress.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-skl9/igt@gem_...@unwedge-stress.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-kbl: NOTRUN -> [DMESG-FAIL][10] ([i915#5076])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-kbl6/igt@gem_exec_balan...@parallel-ordering.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][12] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/shard-glk5/igt@gem_exec_fair@basic-p...@vecs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-glk7/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-kbl6/igt@gem_lmem_swapp...@heavy-verify-random.html
- shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +2
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-skl1/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-iclb5/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_media_vme:
- shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271]) +165 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-skl1/igt@gem_media_vme.html
* igt@gem_pxp@verify-pxp-execution-after-suspend-resume:
- shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271]) +61 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/shard-apl3/igt@gem_...@verify-pxp-execution-after-suspend-resume.html
* igt@gem_render_copy@yf-tiled-to-vebox-x-tiled:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#768])
[20]:
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Splitting up platform-specific calls (rev4)
== Series Details == Series: Splitting up platform-specific calls (rev4) URL : https://patchwork.freedesktop.org/series/99126/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Splitting up platform-specific calls (rev4)
== Series Details == Series: Splitting up platform-specific calls (rev4) URL : https://patchwork.freedesktop.org/series/99126/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH] drm/i915/rps: Centralize computation of freq caps
On Mon, 21 Mar 2022 11:17:46 -0700, Lucas De Marchi wrote:
>
> On Mon, Mar 21, 2022 at 10:56:04AM -0700, Ashutosh Dixit wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > b/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > index 3941d8551f52..5990df35b393 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps_types.h
> > @@ -37,6 +37,13 @@ enum {
> > INTEL_RPS_TIMER,
> > };
> >
> > +/* Freq caps exposed by HW, in units of 16.67 MHz for recent gens */
>
> "recent gens" is probably too broad. Since we are exporting this struct
> to other parts of the driver and we are already abstracting the
> register location and bit position, maybe we should also already
> abstract the unit in the same place? i.e. just make it always be
> "units of 16.67 MHz", or even just make it a standard Hz unit.
>
> If this would rather make things more complicated for places that expect
> "hw units", then maybe just say in this comment the value is in "HW
> units" and intel_gpu_freq() should be used to convert to hz.
Fixed in v2. In v2 I've changed the comment to say values are in "hw units"
and intel_gpu_freq() should be used to convert to MHz.
I have also added a couple of hopefully clarifying comments to
intel_rps_get_freq_caps() in v2. Some of the history of this code was not
clear to me previously and I had to trace all the way back to cee991cb9323
to figure out what is happening.
Thanks.
--
Ashutosh
> > +struct intel_rps_freq_caps {
> > + u8 rp0_freq;/* Non-overclocked max frequency. */
> > + u8 rp1_freq;/* "less than" RP0 power/freqency */
> > + u8 min_freq;/* AKA RPn. Minimum frequency */
> > +};
> > +
> > struct intel_rps {
> > struct mutex lock; /* protects enabling and the worker */
> >
[Intel-gfx] [PATCH] drm/i915/rps: Centralize computation of freq caps
Freq caps (i.e. RP0, RP1 and RPn frequencies) are read from HW. However the
formats (bit positions, widths, registers and units) of these vary for
different generations with even more variations arriving in the future. In
order not to have to do identical computation for these caps in multiple
places, here we centralize the computation of these caps. This makes the
code cleaner and also more extensible for the future.
v2: Clarify that caps are in "hw units" in comments (Lucas De Marchi)
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 24 +
drivers/gpu/drm/i915/gt/intel_rps.c | 101 ++
drivers/gpu/drm/i915/gt/intel_rps.h | 2 +-
drivers/gpu/drm/i915/gt/intel_rps_types.h | 10 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 14 +--
5 files changed, 79 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 31dbb2b96738..f5fbb74ed076 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -342,17 +342,16 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt,
struct drm_printer *p)
} else if (GRAPHICS_VER(i915) >= 6) {
u32 rp_state_limits;
u32 gt_perf_status;
- u32 rp_state_cap;
+ struct intel_rps_freq_caps caps;
u32 rpmodectl, rpinclimit, rpdeclimit;
u32 rpstat, cagf, reqf;
u32 rpcurupei, rpcurup, rpprevup;
u32 rpcurdownei, rpcurdown, rpprevdown;
u32 rpupei, rpupt, rpdownei, rpdownt;
u32 pm_ier, pm_imr, pm_isr, pm_iir, pm_mask;
- int max_freq;
rp_state_limits = intel_uncore_read(uncore,
GEN6_RP_STATE_LIMITS);
- rp_state_cap = intel_rps_read_state_cap(rps);
+ intel_rps_get_freq_caps(rps, );
if (IS_GEN9_LP(i915))
gt_perf_status = intel_uncore_read(uncore,
BXT_GT_PERF_STATUS);
else
@@ -474,25 +473,12 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt,
struct drm_printer *p)
drm_printf(p, "RP DOWN THRESHOLD: %d (%lldns)\n",
rpdownt, intel_gt_pm_interval_to_ns(gt, rpdownt));
- max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 0 :
- rp_state_cap >> 16) & 0xff;
- max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
drm_printf(p, "Lowest (RPN) frequency: %dMHz\n",
- intel_gpu_freq(rps, max_freq));
-
- max_freq = (rp_state_cap & 0xff00) >> 8;
- max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
+ intel_gpu_freq(rps, caps.min_freq));
drm_printf(p, "Nominal (RP1) frequency: %dMHz\n",
- intel_gpu_freq(rps, max_freq));
-
- max_freq = (IS_GEN9_LP(i915) ? rp_state_cap >> 16 :
- rp_state_cap >> 0) & 0xff;
- max_freq *= (IS_GEN9_BC(i915) ||
-GRAPHICS_VER(i915) >= 11 ? GEN9_FREQ_SCALER : 1);
+ intel_gpu_freq(rps, caps.rp1_freq));
drm_printf(p, "Max non-overclocked (RP0) frequency: %dMHz\n",
- intel_gpu_freq(rps, max_freq));
+ intel_gpu_freq(rps, caps.rp0_freq));
drm_printf(p, "Max overclocked frequency: %dMHz\n",
intel_gpu_freq(rps, rps->max_freq));
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 6c9fdf7906c5..4528da9db590 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1070,23 +1070,59 @@ int intel_rps_set(struct intel_rps *rps, u8 val)
return 0;
}
-static void gen6_rps_init(struct intel_rps *rps)
+static u32 intel_rps_read_state_cap(struct intel_rps *rps)
{
struct drm_i915_private *i915 = rps_to_i915(rps);
- u32 rp_state_cap = intel_rps_read_state_cap(rps);
+ struct intel_uncore *uncore = rps_to_uncore(rps);
- /* All of these values are in units of 50MHz */
+ if (IS_XEHPSDV(i915))
+ return intel_uncore_read(uncore, XEHPSDV_RP_STATE_CAP);
+ else if (IS_GEN9_LP(i915))
+ return intel_uncore_read(uncore, BXT_RP_STATE_CAP);
+ else
+ return intel_uncore_read(uncore, GEN6_RP_STATE_CAP);
+}
+
+/* "Caps" frequencies should be converted to MHz using intel_gpu_freq() */
+void intel_rps_get_freq_caps(struct intel_rps *rps, struct intel_rps_freq_caps
*caps)
+{
+ struct drm_i915_private *i915 = rps_to_i915(rps);
+ u32 rp_state_cap;
+
+ rp_state_cap =
[Intel-gfx] [PATCH v4 1/1] i915/drm: Split run_as_guest into x86 and non-x86
Splitting run_as_guest into a more arch-friendly function
as non-x86 builds do not support this functionality.
Signed-off-by: Casey Bowman
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3c85dc8c1f04..76f0e47e3186 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1366,7 +1366,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
static inline bool run_as_guest(void)
{
+#if IS_ENABLED(CONFIG_X86)
return !hypervisor_is_type(X86_HYPER_NATIVE);
+#else
+ /* Not supported yet */
+ return false;
+#endif
}
#define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
--
2.25.1
[Intel-gfx] [PATCH v4 0/1] Splitting up platform-specific calls
In this RFC I would like to ask the community their thoughts on how we can best handle splitting architecture-specific calls. I would like to address the following: 1. How do we want to split architecture calls? Different object files per platform? Separate function calls within the same object file? 2. How do we address dummy functions? If we have a function call that is used for one or more platforms, but is not used in another, what should we do for this case? I've given an example of splitting an architecture call in my patch with run_as_guest() being split into different implementations for x86 and arm64 in separate object files, sharing a single header. Another suggestion from Michael (michael.ch...@intel.com) involved using a single object file, a single header, and splitting various functions calls via ifdefs in the header file. I would appreciate any input on how we can avoid scaling issues when including multiple architectures and multiple functions (as the number of function calls will inevitably increase with more architectures). v2: Revised to use kernel's platform-splitting scheme. v3: Revised to use simple if-else structure. v4: Modified into more arch-neutral split. Casey Bowman (1): i915/drm: Split run_as_guest into x86 and non-x86 drivers/gpu/drm/i915/i915_drv.h | 5 + 1 file changed, 5 insertions(+) -- 2.25.1
Re: [Intel-gfx] [PATCH v13 00/13] Add GuC Error Capture Support
On Mon, Mar 21, 2022 at 09:45:14AM -0700, Alan Previn wrote: This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global, engine class and engine instance registers with GuC. 3. Defines tables of register lists that are global or engine class or engine instance in scope. 4. Updates usage and buffer-state data for the regions of the shared GuC log-buffer to accomdate both the existing relay logging of general debug logs along with the new error state capture usage. 5. Using a pool of preallocated memory, provide ability to extract and format the GuC reported register-capture data into chunks consistent with existing i915 error- state collection flows and structures. 6. Connects the i915_gpu_coredump reporting function to the GuC error capture module to print all GuC error state capture dumps that is reported. This is the 13th rev of this series where the first 3 revs are RFC Prior receipts of rvb's: - Patch #2, #3, #4, #5, #10, #11, #12, #13 have received R-v-b's from Umesh Nerlige Ramappa - Patch #1, #6, #7, #8, #9 has received an R-v-b from Matthew Brost . NOTE: some of these came in on the trybot series. https://patchwork.freedesktop.org/series/100831/ Changes from prior revs: v13:- Fixing register list definition styling as per Jani's request. As in v12, the CI failure in display is unrelated to these changes. Applied to drm-intel-gt-next. Thanks Lucas De Marchi
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Split out intel_vtd_active and run_as_guest to own header
== Series Details ==
Series: drm/i915: Split out intel_vtd_active and run_as_guest to own header
URL : https://patchwork.freedesktop.org/series/101646/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11396 -> Patchwork_22644
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/index.html
Participating hosts (49 -> 43)
--
Missing(6): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 shard-rkl
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22644:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@coherency:
- {bat-rpls-2}: [DMESG-WARN][1] ([i915#4391]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@coherency.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/bat-rpls-2/igt@i915_selftest@l...@coherency.html
* igt@kms_flip@basic-plain-flip@a-dp1:
- {bat-adlm-1}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-adlm-1/igt@kms_flip@basic-plain-f...@a-dp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/bat-adlm-1/igt@kms_flip@basic-plain-f...@a-dp1.html
Known issues
Here are the changes found in Patchwork_22644 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][5] -> [INCOMPLETE][6] ([i915#3303])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-cfl-8109u: [PASS][7] -> [DMESG-WARN][8] ([i915#295])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][9] ([fdo#109271] / [i915#1436] /
[i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][10] ([i915#5127]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][12] ([i915#4494] / [i915#4957]) ->
[PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@objects:
- {bat-rpls-2}: [DMESG-WARN][14] ([i915#4391]) -> [PASS][15] +3
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@objects.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/bat-rpls-2/igt@i915_selftest@l...@objects.html
* igt@kms_busy@basic@modeset:
- {bat-adlp-6}: [DMESG-WARN][16] ([i915#3576]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-adlp-6/igt@kms_busy@ba...@modeset.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22644/bat-adlp-6/igt@kms_busy@ba...@modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]:
Re: [Intel-gfx] [PATCH v2] drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
On Tue, Mar 22, 2022 at 04:38:44PM +0200, Imre Deak wrote:
> At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted
> DPCD register values when reading from the 0xF- LTTPR range with an
> AUX transaction block size bigger than 1. The DP standard requires 0 to
> be returned - as for any other reserved/invalid addresses - but these
> monitors return the DPCD_REV register value repeated in each byte of the
> read buffer. This will in turn corrupt the values returned by the LTTPRs
> between the source and the monitor: LTTPRs must adjust the values they
> read from the downstream DPRX, for instance left-shift/init the
> downstream DP_PHY_REPEATER_CNT value. Since the value returned by the
> monitor's DPRX is non-zero the adjusted values will be corrupt.
>
> Reading the LTTPR registers one-by-one instead of reading all of them
> with a single AUX transfer works around the issue.
>
> According to the DP standard's 0xF register description:
> "LTTPR-related registers at DPCD Addresses Fh through F02FFh are
> valid only for DPCD r1.4 (or higher)." While it's unclear if DPCD r1.4
> refers to the DPCD_REV or to the
> LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV register (tickets filed
> at the VESA site to clarify this haven't been addressed), one
> possibility is that it's a restriction due to non-compliant monitors
> described above. Disabling the non-transparent LTTPR mode for all such
> monitors is not a viable solution: the transparent LTTPR mode has its
> own issue causing link training failures and this would affect a lot of
> monitors in use with DPCD_REV < 1.4. Instead this patch works around
> the problem by reading the LTTPR common and PHY cap registers one-by-one
> for any monitor with a DPCD_REV < 1.4.
>
> The standard requires the DPCD capabilites to be read after the LTTPR
> common capabilities are read, so re-read the DPCD capabilities after
> the LTTPR common and PHY caps were read out.
>
> v2:
> - Use for instead of a while loop. (Ville)
> - Add to code comment the monitor model with the problem.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4531
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/dp/drm_dp.c | 57 ---
> .../drm/i915/display/intel_dp_link_training.c | 30 +++---
> include/drm/dp/drm_dp_helper.h| 2 +
> 3 files changed, 58 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/dp/drm_dp.c b/drivers/gpu/drm/dp/drm_dp.c
> index 703972ae14c64..58744f83931af 100644
> --- a/drivers/gpu/drm/dp/drm_dp.c
> +++ b/drivers/gpu/drm/dp/drm_dp.c
> @@ -2390,9 +2390,35 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
> }
> EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
>
> +static int drm_dp_read_lttpr_regs(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE], int address,
> + u8 *buf, int buf_size)
> +{
> + /*
> + * At least the DELL P2715Q monitor with a DPCD_REV < 0x14 returns
> + * corrupted values when reading from the 0xF- range with a block
> + * size bigger than 1.
> + */
> + int block_size = dpcd[DP_DPCD_REV] < 0x14 ? 1 : buf_size;
> + int offset;
> + int ret;
> +
> + for (offset = 0; offset < buf_size; offset += block_size) {
> + ret = drm_dp_dpcd_read(aux,
> +address + offset,
> +[offset], block_size);
> + if (ret < 0)
> + return ret;
> +
> + WARN_ON(ret != block_size);
> + }
> +
> + return 0;
> +}
> +
> /**
> * drm_dp_read_lttpr_common_caps - read the LTTPR common capabilities
> * @aux: DisplayPort AUX channel
> + * @dpcd: DisplayPort configuration data
> * @caps: buffer to return the capability info in
> *
> * Read capabilities common to all LTTPRs.
> @@ -2400,25 +2426,19 @@ EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
> * Returns 0 on success or a negative error code on failure.
> */
> int drm_dp_read_lttpr_common_caps(struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> u8 caps[DP_LTTPR_COMMON_CAP_SIZE])
> {
> - int ret;
> -
> - ret = drm_dp_dpcd_read(aux,
> -
> DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
> -caps, DP_LTTPR_COMMON_CAP_SIZE);
> - if (ret < 0)
> - return ret;
> -
> - WARN_ON(ret != DP_LTTPR_COMMON_CAP_SIZE);
> -
> - return 0;
> + return drm_dp_read_lttpr_regs(aux, dpcd,
> +
> DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
> + caps, DP_LTTPR_COMMON_CAP_SIZE);
> }
> EXPORT_SYMBOL(drm_dp_read_lttpr_common_caps);
>
> /**
> * drm_dp_read_lttpr_phy_caps - read the
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Use drm_clflush* instead of clflush
On Tue, Mar 22, 2022 at 02:09:43PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Use drm_clflush* instead of clflush
> URL : https://patchwork.freedesktop.org/series/101611/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11395_full -> Patchwork_22635_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
Series applied to drm-intel-gt-next. Thanks for the patches.
Matt
>
>
>
> Participating hosts (13 -> 13)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_22635_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@runner@aborted:
> - {shard-rkl}:([FAIL][1], [FAIL][2], [FAIL][3]) ([i915#2029] /
> [i915#3002] / [i915#4312]) -> ([FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7])
> ([i915#3002] / [i915#4312])
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@run...@aborted.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@run...@aborted.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@run...@aborted.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-2/igt@run...@aborted.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-5/igt@run...@aborted.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-1/igt@run...@aborted.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-2/igt@run...@aborted.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_22635_full that come from known
> issues:
>
> ### CI changes ###
>
> Possible fixes
>
> * boot:
> - shard-glk: ([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], [PASS][22], [PASS][23],
> [PASS][24], [PASS][25], [PASS][26], [PASS][27], [FAIL][28], [PASS][29],
> [PASS][30], [PASS][31]) ([i915#4392]) -> ([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], [PASS][45], [PASS][46],
> [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52],
> [PASS][53], [PASS][54], [PASS][55], [PASS][56])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
>[23]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
>[24]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
>[25]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
>[26]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
>[27]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
>[28]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
>[29]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
>[30]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
>[31]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
>[32]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-glk1/boot.html
>[33]:
>
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Split out intel_vtd_active and run_as_guest to own header
== Series Details == Series: drm/i915: Split out intel_vtd_active and run_as_guest to own header URL : https://patchwork.freedesktop.org/series/101646/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Refactor CT access to use iosys_map (rev2)
== Series Details ==
Series: drm/i915/guc: Refactor CT access to use iosys_map (rev2)
URL : https://patchwork.freedesktop.org/series/101148/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11395_full -> Patchwork_22639_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 12)
--
Missing(1): shard-dg1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22639_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-rkl}:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@i915_pm_...@system-suspend-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@i915_pm_...@system-suspend-devices.html
* igt@kms_color@pipe-c-deep-color:
- {shard-rkl}:[SKIP][3] ([i915#4070]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-2/igt@kms_co...@pipe-c-deep-color.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_co...@pipe-c-deep-color.html
* igt@kms_color@pipe-c-legacy-gamma-reset:
- {shard-rkl}:[SKIP][5] ([i915#4070]) -> ([SKIP][6], [SKIP][7])
([i915#1849] / [i915#4098])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@kms_co...@pipe-c-legacy-gamma-reset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-5/igt@kms_co...@pipe-c-legacy-gamma-reset.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_co...@pipe-c-legacy-gamma-reset.html
* igt@kms_cursor_crc@pipe-a-cursor-256x256-rapid-movement:
- {shard-rkl}:[SKIP][8] ([fdo#112022] / [i915#4070]) -> ([PASS][9],
[SKIP][10])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@kms_cursor_...@pipe-a-cursor-256x256-rapid-movement.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-6/igt@kms_cursor_...@pipe-a-cursor-256x256-rapid-movement.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_cursor_...@pipe-a-cursor-256x256-rapid-movement.html
* igt@kms_cursor_crc@pipe-a-cursor-32x32-onscreen:
- {shard-rkl}:NOTRUN -> [SKIP][11] +38 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_cursor_...@pipe-a-cursor-32x32-onscreen.html
* igt@kms_cursor_crc@pipe-b-cursor-64x21-random:
- {shard-rkl}:[SKIP][12] ([fdo#112022]) -> [SKIP][13] +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-5/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html
* igt@kms_cursor_crc@pipe-b-cursor-alpha-opaque:
- {shard-rkl}:[SKIP][14] ([fdo#112022] / [i915#4070]) -> [SKIP][15]
+3 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-2/igt@kms_cursor_...@pipe-b-cursor-alpha-opaque.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_cursor_...@pipe-b-cursor-alpha-opaque.html
* igt@kms_cursor_crc@pipe-c-cursor-256x85-offscreen:
- {shard-rkl}:NOTRUN -> ([SKIP][16], [SKIP][17]) ([fdo#112022] /
[i915#4070])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-1/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-512x170-random:
- {shard-rkl}:[SKIP][18] ([i915#4070]) -> ([SKIP][19], [SKIP][20])
([fdo#112022] / [i915#4070])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-6/igt@kms_cursor_...@pipe-c-cursor-512x170-random.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-2/igt@kms_cursor_...@pipe-c-cursor-512x170-random.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_cursor_...@pipe-c-cursor-512x170-random.html
* igt@kms_cursor_crc@pipe-c-cursor-max-size-rapid-movement:
- {shard-rkl}:[SKIP][21] ([fdo#112022]) -> ([SKIP][22], [SKIP][23])
([fdo#112022] / [i915#4070]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-5/igt@kms_cursor_...@pipe-c-cursor-max-size-rapid-movement.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22639/shard-rkl-3/igt@kms_cursor_...@pipe-c-cursor-max-size-rapid-movement.html
[23]:
Re: [Intel-gfx] [PATCH 3/3] drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL
On Fri, 2022-03-18 at 23:28 +0200, Ville Syrjälä wrote:
> On Fri, Mar 18, 2022 at 12:55:22PM -0700, José Roberto de Souza wrote:
> > PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being
> > enabled leaving other pipes with a wrong A_CREDIT value in cases
> > like when going from one pipe enabled to two pipes and the first
> > pipe don't need modeset, similar when going from two or more
> > pipes to ones.
> >
> > So here moving the PIPE_MBUS_DBOX_CTL programing to be executed before
> > the function that enables and updates all necessary pipes.
> > Leaving all pipes with the correct value of A_CREDIT.
> >
> > As now PIPE_MBUS_DBOX_CTL is being programmed at the right time it
> > is also waiting the vblanks after adjust PIPE_MBUS_DBOX_CTL
> > as required by specification.
> >
> > BSpec: 49213
> > BSpec: 50343
> > Cc: Ville Syrjälä
> > Cc: Stanislav Lisovskiy
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 36 +
> > drivers/gpu/drm/i915/intel_pm.c | 55 +++-
> > drivers/gpu/drm/i915/intel_pm.h | 1 +
> > 3 files changed, 56 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 2e85ae575423a..4cd2d76058b8c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -1821,34 +1821,6 @@ static void glk_pipe_scaler_clock_gating_wa(struct
> > drm_i915_private *dev_priv,
> > intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe), val);
> > }
> >
> > -static void icl_pipe_mbus_enable(struct intel_crtc *crtc, bool joined_mbus)
> > -{
> > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > - enum pipe pipe = crtc->pipe;
> > - u32 val = intel_de_read(dev_priv, PIPE_MBUS_DBOX_CTL(pipe));
> > -
> > - val &= ~MBUS_DBOX_A_CREDIT_MASK;
> > - /* Wa_22010947358:adl-p */
> > - if (IS_ALDERLAKE_P(dev_priv))
> > - val |= joined_mbus ? MBUS_DBOX_A_CREDIT(6) :
> > MBUS_DBOX_A_CREDIT(4);
> > - else
> > - val |= MBUS_DBOX_A_CREDIT(2);
> > -
> > - val &= ~(MBUS_DBOX_BW_CREDIT_MASK | MBUS_DBOX_B_CREDIT_MASK);
> > - if (IS_ALDERLAKE_P(dev_priv)) {
> > - val |= MBUS_DBOX_BW_CREDIT(2);
> > - val |= MBUS_DBOX_B_CREDIT(8);
> > - } else if (DISPLAY_VER(dev_priv) >= 12) {
> > - val |= MBUS_DBOX_BW_CREDIT(2);
> > - val |= MBUS_DBOX_B_CREDIT(12);
> > - } else {
> > - val |= MBUS_DBOX_BW_CREDIT(1);
> > - val |= MBUS_DBOX_B_CREDIT(8);
> > - }
> > -
> > - intel_de_write(dev_priv, PIPE_MBUS_DBOX_CTL(pipe), val);
> > -}
> > -
> > static void hsw_set_linetime_wm(const struct intel_crtc_state *crtc_state)
> > {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -1984,13 +1956,6 @@ static void hsw_crtc_enable(struct
> > intel_atomic_state *state,
> >
> > intel_initial_watermarks(state, crtc);
> >
> > - if (DISPLAY_VER(dev_priv) >= 11) {
> > - const struct intel_dbuf_state *dbuf_state =
> > - intel_atomic_get_new_dbuf_state(state);
> > -
> > - icl_pipe_mbus_enable(crtc, dbuf_state->joined_mbus);
> > - }
> > -
> > if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
> > intel_crtc_vblank_on(new_crtc_state);
> >
> > @@ -8589,6 +8554,7 @@ static void intel_atomic_commit_tail(struct
> > intel_atomic_state *state)
> > intel_encoders_update_prepare(state);
> >
> > intel_dbuf_pre_plane_update(state);
> > + intel_mbus_dbox_update(state);
> >
> > for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> > if (new_crtc_state->do_async_flip)
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 96bb8ecc11668..08ba32e5eb4ad 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6172,7 +6172,6 @@ skl_compute_ddb(struct intel_atomic_state *state)
> > return ret;
> >
> > if (old_dbuf_state->joined_mbus != new_dbuf_state->joined_mbus)
> > {
> > - /* TODO: Implement vblank synchronized MBUS joining
> > changes */
> > ret = intel_modeset_all_pipes(state);
> > if (ret)
> > return ret;
> > @@ -8365,3 +8364,57 @@ void intel_dbuf_post_plane_update(struct
> > intel_atomic_state *state)
> > gen9_dbuf_slices_update(dev_priv,
> > new_dbuf_state->enabled_slices);
> > }
> > +
> > +void intel_mbus_dbox_update(struct intel_atomic_state *state)
> > +{
> > + struct drm_i915_private *i915 = to_i915(state->base.dev);
> > + struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> > + struct intel_dbuf_state *old_dbuf_state, *new_dbuf_state;
> > + struct intel_crtc *crtc;
> > +
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Split out intel_vtd_active and run_as_guest to own header
== Series Details == Series: drm/i915: Split out intel_vtd_active and run_as_guest to own header URL : https://patchwork.freedesktop.org/series/101646/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Split out intel_vtd_active and run_as_guest to own header
== Series Details == Series: drm/i915: Split out intel_vtd_active and run_as_guest to own header URL : https://patchwork.freedesktop.org/series/101646/ State : warning == Summary == $ dim checkpatch origin/drm-tip b5d25bc04040 drm/i915: Split out intel_vtd_active and run_as_guest to own header -:179: CHECK:LINE_SPACING: Please don't use multiple blank lines #179: FILE: drivers/gpu/drm/i915/gt/intel_gtt.c:21: + + -:381: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #381: new file mode 100644 total: 0 errors, 1 warnings, 1 checks, 300 lines checked
Re: [Intel-gfx] [PATCH v11 4/5] mei: gsc: add runtime pm handlers
On Tue, Mar 15, 2022 at 03:11:56PM +0200, Alexander Usyskin wrote:
> From: Tomas Winkler
>
> Implement runtime handlers for mei-gsc, to track
> idle state of the device properly.
>
> CC: Rodrigo Vivi
> Signed-off-by: Tomas Winkler
> Signed-off-by: Alexander Usyskin
> ---
> V4: drop debug prints
> V5: Rebase
> V6: Rebase
> V7: add Greg KH Reviewed-by
> V8: Rebase
> V9: Rebase
> V11: Rebase
> ---
> drivers/misc/mei/gsc-me.c | 67 ++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
> index 58e39c00f150..32ea75f5e7aa 100644
> --- a/drivers/misc/mei/gsc-me.c
> +++ b/drivers/misc/mei/gsc-me.c
> @@ -159,7 +159,72 @@ static int __maybe_unused mei_gsc_pm_resume(struct
> device *device)
> return 0;
> }
>
> -static SIMPLE_DEV_PM_OPS(mei_gsc_pm_ops, mei_gsc_pm_suspend,
> mei_gsc_pm_resume);
> +static int __maybe_unused mei_gsc_pm_runtime_idle(struct device *device)
> +{
> + struct mei_device *dev = dev_get_drvdata(device);
> +
> + if (!dev)
> + return -ENODEV;
> + if (mei_write_is_idle(dev))
> + pm_runtime_autosuspend(device);
> +
> + return -EBUSY;
I see now... this function takes to the autosuspend but returns the EBUSY so
the pci subsystem won't take it. Many other drivers taking this approach.
> +}
> +
> +static int __maybe_unused mei_gsc_pm_runtime_suspend(struct device *device)
> +{
> + struct mei_device *dev = dev_get_drvdata(device);
> + struct mei_me_hw *hw;
> + int ret;
> +
> + if (!dev)
> + return -ENODEV;
> +
> + mutex_lock(>device_lock);
> +
> + if (mei_write_is_idle(dev)) {
> + hw = to_me_hw(dev);
> + hw->pg_state = MEI_PG_ON;
> + ret = 0;
> + } else {
> + ret = -EAGAIN;
> + }
> +
> + mutex_unlock(>device_lock);
> +
> + return ret;
> +}
> +
> +static int __maybe_unused mei_gsc_pm_runtime_resume(struct device *device)
> +{
> + struct mei_device *dev = dev_get_drvdata(device);
> + struct mei_me_hw *hw;
> + irqreturn_t irq_ret;
> +
> + if (!dev)
> + return -ENODEV;
> +
> + mutex_lock(>device_lock);
> +
> + hw = to_me_hw(dev);
> + hw->pg_state = MEI_PG_OFF;
> +
> + mutex_unlock(>device_lock);
> +
> + irq_ret = mei_me_irq_thread_handler(1, dev);
> + if (irq_ret != IRQ_HANDLED)
> + dev_err(dev->dev, "thread handler fail %d\n", irq_ret);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops mei_gsc_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(mei_gsc_pm_suspend,
> + mei_gsc_pm_resume)
> + SET_RUNTIME_PM_OPS(mei_gsc_pm_runtime_suspend,
> +mei_gsc_pm_runtime_resume,
> +mei_gsc_pm_runtime_idle)
> +};
Thank you for all the explanation.
I would prefer if you could move the autosuspend enable and autosuspend delay
to this patch instead of having it on the patch 2. Concerning some strange
behaviour in some bisect...
But that's minor and up to you:
Reviewed-by: Rodrigo Vivi
>
> static const struct auxiliary_device_id mei_gsc_id_table[] = {
> {
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH v13 09/13] drm/i915/guc: Check sizing of guc_capture output
On Mon, Mar 21, 2022 at 09:45:23AM -0700, Alan Previn wrote:
Add intel_guc_capture_output_min_size_est function to
provide a reasonable minimum size for error-capture
region before allocating the shared buffer.
Signed-off-by: Alan Previn
Reviewed-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 48 +++
.../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 7 ++-
3 files changed, 55 insertions(+), 1 deletion(-)
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 63ef407a2fd0..f87fee216430 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -663,6 +663,54 @@ intel_guc_capture_getnullheader(struct intel_guc *guc,
return 0;
}
+#define GUC_CAPTURE_OVERBUFFER_MULTIPLIER 3
missing blank line here
+int
+intel_guc_capture_output_min_size_est(struct intel_guc *guc)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ int worst_min_size = 0, num_regs = 0;
+ size_t tmp = 0;
+
+ /*
+* If every single engine-instance suffered a failure in quick
succession but
+* were all unrelated, then a burst of multiple error-capture events
would dump
+* registers for every one engine instance, one at a time. In this
case, GuC
+* would even dump the global-registers repeatedly.
+*
+* For each engine instance, there would be 1 x
guc_state_capture_group_t output
+* followed by 3 x guc_state_capture_t lists. The latter is how the
register
+* dumps are split across different register types (where the '3' are
global vs class
+* vs instance). Finally, let's multiply the whole thing by 3x (just so
we are
+* not limited to just 1 round of data in a worst case full register
dump log)
+*
+* NOTE: intel_guc_log that allocates the log buffer would round this
size up to
+* a power of two.
+*/
+
+ for_each_engine(engine, gt, id) {
+ worst_min_size += sizeof(struct
guc_state_capture_group_header_t) +
+ (3 * sizeof(struct
guc_state_capture_header_t));
+
+ if (!intel_guc_capture_getlistsize(guc, 0,
GUC_CAPTURE_LIST_TYPE_GLOBAL, 0, ))
+ num_regs += tmp;
+
+ if (!intel_guc_capture_getlistsize(guc, 0,
GUC_CAPTURE_LIST_TYPE_ENGINE_CLASS,
+ engine->class, )) {
+ num_regs += tmp;
+ }
+ if (!intel_guc_capture_getlistsize(guc, 0,
GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE,
+ engine->class, )) {
+ num_regs += tmp;
+ }
+ }
+
+ worst_min_size += (num_regs * sizeof(struct guc_mmio_reg));
+
+ return (worst_min_size * GUC_CAPTURE_OVERBUFFER_MULTIPLIER);
+}
+
static void
guc_capture_free_ads_cache(struct intel_guc_state_capture *gc)
{
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
index 8de7704e12eb..540d72079462 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.h
@@ -11,6 +11,7 @@
struct guc_gt_system_info;
struct intel_guc;
+int intel_guc_capture_output_min_size_est(struct intel_guc *guc);
int intel_guc_capture_getlist(struct intel_guc *guc, u32 owner, u32 type, u32
classid,
void **outptr);
int intel_guc_capture_getlistsize(struct intel_guc *guc, u32 owner, u32 type,
u32 classid,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index fe4b2d3f305d..ed05b1a04f9c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -7,10 +7,11 @@
#include
#include "gt/intel_gt.h"
+#include "intel_guc_capture.h"
+#include "intel_guc_log.h"
#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_memcpy.h"
-#include "intel_guc_log.h"
This seems to be an artifact of rebasing or you tried to sort the
includes... when sorting make sure you use LANG=C to avoid locale
differences wrt sorting
The previous placement of intel_guc_log.h was actually the correct one.
I'm squashing this and the previous blank line I mentioned as a fixup.
thanks
Lucas De Marchi
static void guc_log_copy_debuglogs_for_relay(struct intel_guc_log *log);
@@ -466,6 +467,10 @@ int intel_guc_log_create(struct intel_guc_log *log)
* | Capture logs |
* +===+ + CAPTURE_SIZE
*/
+ if (intel_guc_capture_output_min_size_est(guc) > CAPTURE_BUFFER_SIZE)
+ DRM_WARN("GuC log buffer for state_capture maybe too small. %d <
%d\n",
+
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On Tue, Mar 22, 2022 at 04:49:53PM +0200, Jani Nikula wrote:
On Tue, 22 Mar 2022, Lucas De Marchi wrote:
On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
On Mon, 21 Mar 2022, Lucas De Marchi wrote:
On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
Wanted to ping this older thread to find out where we stand with this patch,
Are we OK with the current state of these changes?
With more recent information gathered from feedback on other patches, would
we prefer changing this to a more arch-neutral control flow?
e.g.
#if IS_ENABLED(CONFIG_X86)
...
#else
...
#endif
Would we also prefer this RFC series be merged or would it be preferred to
create a new series instead?
for this specific function, that is used in only 2 places I think it's
ok to do:
static inline bool run_as_guest(void)
{
#if IS_ENABLED(CONFIG_X86)
return !hypervisor_is_type(X86_HYPER_NATIVE);
#else
/* Not supported yet */
return false;
#endif
}
For PCH it doesn't really matter as we don't execute that function
for discrete. For intel_vtd_active() I figure anything other than
x86 would be fine with false here.
Jani, that this look good to you?
It's more important to me to get this out of i915_drv.h, which is not
supposed to be a collection of random stuff anymore. I've sent patches
to this effect but they've stalled a bit.
do you have a patch moving this particular one? got a link?
Yeah, but it was basically shot down by Tvrtko [1], and I stalled there.
I'd just like to get all this cruft out of i915_drv.h. Whenever we have
a file where the name isn't super specific, we seem to have a tendency
of turning it into a dumping ground for random crap. So I'd really like
to move this out of there *before* expanding on it.
ok, I took a look there and it seems there is still some discussion on
where to move it. The place you moved it to is not ideal as
`run_as_guest()` has nothing to do with vt-d, even if it's used by one
of those functions. It's also used by the PCH detection/fallback code.
So, I think this is very much orthogonal to moving it and we are not
really extending: this just doesn't make much sense for other archs.
So my proposal is that we continue with this as is and move it when
we have a rough agreement on where to move it to.
As much as I hate the i915_utils.[ch] and I've been trying to reduce it,
I can't think of a best place. Other than of course come up with an
arch-neutral API to add to the kernel
From some quick grep, include/linux/hypervisor.h might be a good place.
But again, I think it should be orthogonal to what this is doing.
thanks
Lucas De Marchi
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/99852/
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [RFC] drm/i915: Split out intel_vtd_active and run_as_guest to own header
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Lucas De Marchi
---
Typed up how I see it - bash away.
---
drivers/gpu/drm/i915/display/intel_bw.c | 3 +-
drivers/gpu/drm/i915/display/intel_display.c | 9 -
drivers/gpu/drm/i915/display/intel_display.h | 2 ++
drivers/gpu/drm/i915/display/intel_fbc.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 3 +-
drivers/gpu/drm/i915/gem/i915_gemfs.c| 3 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 5 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 ++
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_driver.c | 3 +-
drivers/gpu/drm/i915/i915_driver.h | 4 +++
drivers/gpu/drm/i915/i915_drv.h | 37
drivers/gpu/drm/i915/i915_gpu_error.c| 3 +-
drivers/gpu/drm/i915/intel_device_info.c | 4 ++-
drivers/gpu/drm/i915/intel_pch.c | 3 +-
drivers/gpu/drm/i915/intel_vtd.h | 27 ++
17 files changed, 76 insertions(+), 48 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_vtd.h
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index ac11ff19e47d..6c9cb4f97218 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -13,6 +13,7 @@
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
#include "intel_pm.h"
+#include "intel_vtd.h"
/* Parameters for Qclk Geyserville (QGV) */
struct intel_qgv_point {
@@ -649,7 +650,7 @@ static unsigned int intel_bw_data_rate(struct
drm_i915_private *dev_priv,
for_each_pipe(dev_priv, pipe)
data_rate += bw_state->data_rate[pipe];
- if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active(dev_priv))
+ if (DISPLAY_VER(dev_priv) >= 13 && intel_vtd_active(dev_priv->drm.dev))
data_rate = DIV_ROUND_UP(data_rate * 105, 100);
return data_rate;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dc6e21e4ef0b..e80f3ca3ee4e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -110,6 +110,7 @@
#include "intel_quirks.h"
#include "intel_sprite.h"
#include "intel_tc.h"
+#include "intel_vtd.h"
#include "intel_vga.h"
#include "i9xx_plane.h"
#include "skl_scaler.h"
@@ -1197,7 +1198,7 @@ static bool needs_async_flip_vtd_wa(const struct
intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
- return crtc_state->uapi.async_flip && intel_vtd_active(i915) &&
+ return crtc_state->uapi.async_flip && intel_vtd_active(i915->drm.dev) &&
(DISPLAY_VER(i915) == 9 || IS_BROADWELL(i915) ||
IS_HASWELL(i915));
}
@@ -10699,3 +10700,9 @@ void intel_display_driver_unregister(struct
drm_i915_private *i915)
acpi_video_unregister();
intel_opregion_unregister(i915);
}
+
+bool intel_scanout_needs_vtd_wa(struct drm_i915_private *dev_priv)
+{
+ return DISPLAY_VER(dev_priv) >= 6 &&
+ intel_vtd_active(dev_priv->drm.dev);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 8513703086b7..d69587c76e71 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -694,4 +694,6 @@ void assert_transcoder(struct drm_i915_private *dev_priv,
#define I915_STATE_WARN_ON(x) \
I915_STATE_WARN((x), "%s", "WARN_ON(" __stringify(x) ")")
+bool intel_scanout_needs_vtd_wa(struct drm_i915_private *dev_priv);
+
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 142280b6ce6d..00a3e30587a5 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -50,6 +50,7 @@
#include "intel_display_types.h"
#include "intel_fbc.h"
#include "intel_frontbuffer.h"
+#include "intel_vtd.h"
#define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS;
(__fbc_id)++) \
@@ -1643,7 +1644,7 @@ static int intel_sanitize_fbc_option(struct
drm_i915_private *i915)
static bool need_fbc_vtd_wa(struct drm_i915_private *i915)
{
/* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */
- if (intel_vtd_active(i915) &&
+ if (intel_vtd_active(i915->drm.dev) &&
(IS_SKYLAKE(i915) || IS_BROXTON(i915))) {
drm_info(>drm,
"Disabling framebuffer compression (FBC) to prevent
screen flicker with VT-d enabled\n");
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 143f61aaa867..9b986b1b0b60 100644
---
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add RPL-S PCI IDs
== Series Details == Series: drm/i915: Add RPL-S PCI IDs URL : https://patchwork.freedesktop.org/series/101621/ State : success == Summary == CI Bug Log - changes from CI_DRM_11395_full -> Patchwork_22638_full Summary --- **SUCCESS** No regressions found. Participating hosts (13 -> 13) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_22638_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][1], [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], [FAIL][21], [PASS][22], [PASS][23], [PASS][24]) ([i915#4392]) -> ([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], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk9/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk8/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk7/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk5/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk1/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk4/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk4/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22638/shard-glk4/boot.html [44]:
Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt
On Tue, 22 Mar 2022 at 12:06, Juha-Pekka Heikkila
wrote:
>
> On 22.3.2022 12.45, Matthew Auld wrote:
> > On Mon, 21 Mar 2022 at 18:36, Juha-Pekka Heikkila
> > wrote:
> >>
> >> On 21.3.2022 14.29, Matthew Auld wrote:
> >>> On Fri, 18 Mar 2022 at 09:22, Juha-Pekka Heikkila
> >>> wrote:
>
> On 17.3.2022 13.55, Matthew Auld wrote:
> > On Wed, 16 Mar 2022 at 22:23, Juha-Pekka Heikkila
> > wrote:
> >>
> >> Add fallback smem allocation for dpt if stolen memory
> >> allocation failed.
> >>
> >> Signed-off-by: Juha-Pekka Heikkila
> >> ---
> >> drivers/gpu/drm/i915/display/intel_dpt.c | 18 ++
> >> 1 file changed, 14 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >> index fb0e7e79e0cd..c8b66433d4db 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >> @@ -10,6 +10,7 @@
> >> #include "intel_display_types.h"
> >> #include "intel_dpt.h"
> >> #include "intel_fb.h"
> >> +#include "gem/i915_gem_internal.h"
> >
> > Nit: these should be kept sorted
> >
> >>
> >> struct i915_dpt {
> >>struct i915_address_space vm;
> >> @@ -128,6 +129,10 @@ struct i915_vma *intel_dpt_pin(struct
> >> i915_address_space *vm)
> >>void __iomem *iomem;
> >>struct i915_gem_ww_ctx ww;
> >>int err;
> >> + u64 pin_flags = 0;
> >> +
> >> + if (i915_gem_object_is_stolen(dpt->obj))
> >> + pin_flags |= PIN_MAPPABLE; /* for
> >> i915_vma_pin_iomap(stolen) */
> >>
> >>wakeref = intel_runtime_pm_get(>runtime_pm);
> >>atomic_inc(>gpu_error.pending_fb_pin);
> >> @@ -138,7 +143,7 @@ struct i915_vma *intel_dpt_pin(struct
> >> i915_address_space *vm)
> >>continue;
> >>
> >>vma = i915_gem_object_ggtt_pin_ww(dpt->obj, ,
> >> NULL, 0, 4096,
> >> - HAS_LMEM(i915) ? 0 :
> >> PIN_MAPPABLE);
> >> + pin_flags);
> >>if (IS_ERR(vma)) {
> >>err = PTR_ERR(vma);
> >>continue;
> >> @@ -248,10 +253,15 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>
> >>size = round_up(size * sizeof(gen8_pte_t),
> >> I915_GTT_PAGE_SIZE);
> >>
> >> - if (HAS_LMEM(i915))
> >> - dpt_obj = i915_gem_object_create_lmem(i915, size,
> >> I915_BO_ALLOC_CONTIGUOUS);
> >> - else
> >> + dpt_obj = i915_gem_object_create_lmem(i915, size,
> >> I915_BO_ALLOC_CONTIGUOUS);
> >> + if (IS_ERR(dpt_obj) &&
> >> i915_ggtt_has_aperture(to_gt(i915)->ggtt))
> >>dpt_obj = i915_gem_object_create_stolen(i915, size);
> >> + if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >> + drm_dbg_kms(>drm, "fb: [FB:%d] Allocating dpt
> >> from smem\n",
> >> + fb->base.base.id);
> >> +
> >> + dpt_obj = i915_gem_object_create_internal(i915, size);
> >
> > Looks like we are missing some prerequisite patch to be able to
> > directly map such memory in vma_pin_iomap?
>
> For these functions I'm more like a consumer, I was following
> suggestions from Chris on this. Is there something extra that should be
> considered in this regard when use it like this?
> >>>
> >>> AFAICT this will trigger the WARN_ON() in vma_pin_iomap() if we
> >>> fallback to create_internal(), since the object is now not lmem and is
> >>> also not map_and_fenceable(i.e PIN_MAPPABLE).
> >>
> >> This shouldn't affect case when dpt allocation from lmem failed, it is
> >> expected to go to "return ERR_CAST(dpt_obj);" below these comments. On
> >> situation when allocating lmem and stolen failed on next "if" I added
> >> !HAS_LMEM(i915) to handle situation with lmem. Though, when I was
> >> originally trying this patch without limiting lmem case I remember with
> >> dg2 I got black screen but I don't remember seeing WARN_ON() in logs.
> >>
> >>>
> >>> The other issue is that we need some way of CPU mapping this type of
> >>> object, like with calling i915_gem_object_pin_map() inside
> >>> vma_pin_iomap(). It looks like there is an internal patch that tries
> >>> to handle both issues, so I guess we need to also bring that patch
> >>> upstream as a prerequisite to this?
> >>
> >> I have above in intel_dpt_pin(..) that "pin_flags |= PIN_MAPPABLE" when
> >> handling stolen memory. I suspect patch you are referring to is this
> >> same patch I wrote, here just adjusted for upstreaming. This patch was
>
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On Tue, 22 Mar 2022, Tvrtko Ursulin wrote:
> On 22/03/2022 15:26, Jani Nikula wrote:
>> On Tue, 22 Mar 2022, Tvrtko Ursulin wrote:
>>> On 22/03/2022 14:49, Jani Nikula wrote:
On Tue, 22 Mar 2022, Lucas De Marchi wrote:
> On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
>> On Mon, 21 Mar 2022, Lucas De Marchi wrote:
>>> On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
Wanted to ping this older thread to find out where we stand with this
patch,
Are we OK with the current state of these changes?
With more recent information gathered from feedback on other patches,
would
we prefer changing this to a more arch-neutral control flow?
e.g.
#if IS_ENABLED(CONFIG_X86)
...
#else
...
#endif
Would we also prefer this RFC series be merged or would it be
preferred to
create a new series instead?
>>>
>>> for this specific function, that is used in only 2 places I think it's
>>> ok to do:
>>>
>>> static inline bool run_as_guest(void)
>>> {
>>> #if IS_ENABLED(CONFIG_X86)
>>> return !hypervisor_is_type(X86_HYPER_NATIVE);
>>> #else
>>> /* Not supported yet */
>>> return false;
>>> #endif
>>> }
>>>
>>> For PCH it doesn't really matter as we don't execute that function
>>> for discrete. For intel_vtd_active() I figure anything other than
>>> x86 would be fine with false here.
>>>
>>> Jani, that this look good to you?
>>
>> It's more important to me to get this out of i915_drv.h, which is not
>> supposed to be a collection of random stuff anymore. I've sent patches
>> to this effect but they've stalled a bit.
>
> do you have a patch moving this particular one? got a link?
Yeah, but it was basically shot down by Tvrtko [1], and I stalled there.
I'd just like to get all this cruft out of i915_drv.h. Whenever we have
a file where the name isn't super specific, we seem to have a tendency
of turning it into a dumping ground for random crap. So I'd really like
to move this out of there *before* expanding on it.
>>>
>>> Sounds like we had agreement on what tweaks to make and I conceded to
>>> live for now with the IMO wrongly named intel_vtd_run_as_guest.
>>>
>>> (I mean I really disagree with file name being trumps, which I think
>>> this example illustrates - this is i915 asking whether the kernel is
>>> running as guest so intel_vtd_ prefix is just wrong. Intel VT-d is the
>>> iommu thingy so it makes no sense when called from PCH detection. But I
>>> have no better ideas at the moment. We can call it i915_run_as_guest, to
>>> signify function belongs to i915, but then we lose the first parameter
>>> names the function rule.)
>>
>> I think the "first parameter names the function" rule has backfired in
>> gem/gt land, because it's pretty difficult to figure out *where* you'd
>> expect to find or place functions.
>
> Hey surely is not that bad. And I am sure if I tried to add some display
> feature that there's a chance I'd manage to misplace something. :))
>
> No scheme is perfect and there are always edge cases, ambiguities and
> always work to cleanup further because it all evolved rather than
> started from scratch. If you know what the function you wrote is about,
> surely you can place it into a file whose name suggests it is the right
> area. If you want the example of GT, there is a nice collection of files
> per functional area.. intel_gt_.. interrupts, power management,
> requests, debugfs, etc.
>
> And if you look for functions you did not write, I certainly suggest
> using ctags rather than try opening random files. I think driver is just
> too big for the latter approach.
Obviously I use code tagging and search. The point was more about the
surprise in expecting to find a function in some place, and finding it
in a totally different place. And obviously for finding the right place
for new functions.
BR,
Jani.
>
> Regards,
>
> Tvrtko
>
>
>> BR,
>> Jani.
>>
>>>
>>> But in any case I don't see that I created any blockers in this thread.
>>> AFAICS just a respin with intel_vtd_active taking struct device is
>>> needed and job done.
>>>
>>> Regards,
>>>
>>> Tvrtko
>>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On 22/03/2022 15:26, Jani Nikula wrote:
On Tue, 22 Mar 2022, Tvrtko Ursulin wrote:
On 22/03/2022 14:49, Jani Nikula wrote:
On Tue, 22 Mar 2022, Lucas De Marchi wrote:
On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
On Mon, 21 Mar 2022, Lucas De Marchi wrote:
On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
Wanted to ping this older thread to find out where we stand with this patch,
Are we OK with the current state of these changes?
With more recent information gathered from feedback on other patches, would
we prefer changing this to a more arch-neutral control flow?
e.g.
#if IS_ENABLED(CONFIG_X86)
...
#else
...
#endif
Would we also prefer this RFC series be merged or would it be preferred to
create a new series instead?
for this specific function, that is used in only 2 places I think it's
ok to do:
static inline bool run_as_guest(void)
{
#if IS_ENABLED(CONFIG_X86)
return !hypervisor_is_type(X86_HYPER_NATIVE);
#else
/* Not supported yet */
return false;
#endif
}
For PCH it doesn't really matter as we don't execute that function
for discrete. For intel_vtd_active() I figure anything other than
x86 would be fine with false here.
Jani, that this look good to you?
It's more important to me to get this out of i915_drv.h, which is not
supposed to be a collection of random stuff anymore. I've sent patches
to this effect but they've stalled a bit.
do you have a patch moving this particular one? got a link?
Yeah, but it was basically shot down by Tvrtko [1], and I stalled there.
I'd just like to get all this cruft out of i915_drv.h. Whenever we have
a file where the name isn't super specific, we seem to have a tendency
of turning it into a dumping ground for random crap. So I'd really like
to move this out of there *before* expanding on it.
Sounds like we had agreement on what tweaks to make and I conceded to
live for now with the IMO wrongly named intel_vtd_run_as_guest.
(I mean I really disagree with file name being trumps, which I think
this example illustrates - this is i915 asking whether the kernel is
running as guest so intel_vtd_ prefix is just wrong. Intel VT-d is the
iommu thingy so it makes no sense when called from PCH detection. But I
have no better ideas at the moment. We can call it i915_run_as_guest, to
signify function belongs to i915, but then we lose the first parameter
names the function rule.)
I think the "first parameter names the function" rule has backfired in
gem/gt land, because it's pretty difficult to figure out *where* you'd
expect to find or place functions.
Hey surely is not that bad. And I am sure if I tried to add some display
feature that there's a chance I'd manage to misplace something. :))
No scheme is perfect and there are always edge cases, ambiguities and
always work to cleanup further because it all evolved rather than
started from scratch. If you know what the function you wrote is about,
surely you can place it into a file whose name suggests it is the right
area. If you want the example of GT, there is a nice collection of files
per functional area.. intel_gt_.. interrupts, power management,
requests, debugfs, etc.
And if you look for functions you did not write, I certainly suggest
using ctags rather than try opening random files. I think driver is just
too big for the latter approach.
Regards,
Tvrtko
BR,
Jani.
But in any case I don't see that I created any blockers in this thread.
AFAICS just a respin with intel_vtd_active taking struct device is
needed and job done.
Regards,
Tvrtko
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On Tue, 22 Mar 2022, Tvrtko Ursulin wrote:
> On 22/03/2022 14:49, Jani Nikula wrote:
>> On Tue, 22 Mar 2022, Lucas De Marchi wrote:
>>> On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
On Mon, 21 Mar 2022, Lucas De Marchi wrote:
> On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
>> Wanted to ping this older thread to find out where we stand with this
>> patch,
>> Are we OK with the current state of these changes?
>>
>> With more recent information gathered from feedback on other patches,
>> would
>> we prefer changing this to a more arch-neutral control flow?
>>
>> e.g.
>> #if IS_ENABLED(CONFIG_X86)
>> ...
>> #else
>> ...
>> #endif
>>
>> Would we also prefer this RFC series be merged or would it be preferred
>> to
>> create a new series instead?
>
> for this specific function, that is used in only 2 places I think it's
> ok to do:
>
> static inline bool run_as_guest(void)
> {
> #if IS_ENABLED(CONFIG_X86)
> return !hypervisor_is_type(X86_HYPER_NATIVE);
> #else
> /* Not supported yet */
> return false;
> #endif
> }
>
> For PCH it doesn't really matter as we don't execute that function
> for discrete. For intel_vtd_active() I figure anything other than
> x86 would be fine with false here.
>
> Jani, that this look good to you?
It's more important to me to get this out of i915_drv.h, which is not
supposed to be a collection of random stuff anymore. I've sent patches
to this effect but they've stalled a bit.
>>>
>>> do you have a patch moving this particular one? got a link?
>>
>> Yeah, but it was basically shot down by Tvrtko [1], and I stalled there.
>>
>> I'd just like to get all this cruft out of i915_drv.h. Whenever we have
>> a file where the name isn't super specific, we seem to have a tendency
>> of turning it into a dumping ground for random crap. So I'd really like
>> to move this out of there *before* expanding on it.
>
> Sounds like we had agreement on what tweaks to make and I conceded to
> live for now with the IMO wrongly named intel_vtd_run_as_guest.
>
> (I mean I really disagree with file name being trumps, which I think
> this example illustrates - this is i915 asking whether the kernel is
> running as guest so intel_vtd_ prefix is just wrong. Intel VT-d is the
> iommu thingy so it makes no sense when called from PCH detection. But I
> have no better ideas at the moment. We can call it i915_run_as_guest, to
> signify function belongs to i915, but then we lose the first parameter
> names the function rule.)
I think the "first parameter names the function" rule has backfired in
gem/gt land, because it's pretty difficult to figure out *where* you'd
expect to find or place functions.
BR,
Jani.
>
> But in any case I don't see that I created any blockers in this thread.
> AFAICS just a respin with intel_vtd_active taking struct device is
> needed and job done.
>
> Regards,
>
> Tvrtko
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On 22/03/2022 15:18, Tvrtko Ursulin wrote:
On 22/03/2022 14:49, Jani Nikula wrote:
On Tue, 22 Mar 2022, Lucas De Marchi wrote:
On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
On Mon, 21 Mar 2022, Lucas De Marchi wrote:
On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
Wanted to ping this older thread to find out where we stand with
this patch,
Are we OK with the current state of these changes?
With more recent information gathered from feedback on other
patches, would
we prefer changing this to a more arch-neutral control flow?
e.g.
#if IS_ENABLED(CONFIG_X86)
...
#else
...
#endif
Would we also prefer this RFC series be merged or would it be
preferred to
create a new series instead?
for this specific function, that is used in only 2 places I think it's
ok to do:
static inline bool run_as_guest(void)
{
#if IS_ENABLED(CONFIG_X86)
return !hypervisor_is_type(X86_HYPER_NATIVE);
#else
/* Not supported yet */
return false;
#endif
}
For PCH it doesn't really matter as we don't execute that function
for discrete. For intel_vtd_active() I figure anything other than
x86 would be fine with false here.
Jani, that this look good to you?
It's more important to me to get this out of i915_drv.h, which is not
supposed to be a collection of random stuff anymore. I've sent patches
to this effect but they've stalled a bit.
do you have a patch moving this particular one? got a link?
Yeah, but it was basically shot down by Tvrtko [1], and I stalled there.
I'd just like to get all this cruft out of i915_drv.h. Whenever we have
a file where the name isn't super specific, we seem to have a tendency
of turning it into a dumping ground for random crap. So I'd really like
to move this out of there *before* expanding on it.
Sounds like we had agreement on what tweaks to make and I conceded to
live for now with the IMO wrongly named intel_vtd_run_as_guest.
(I mean I really disagree with file name being trumps, which I think
this example illustrates - this is i915 asking whether the kernel is
running as guest so intel_vtd_ prefix is just wrong. Intel VT-d is the
iommu thingy so it makes no sense when called from PCH detection. But I
have no better ideas at the moment. We can call it i915_run_as_guest, to
signify function belongs to i915, but then we lose the first parameter
names the function rule.)
But in any case I don't see that I created any blockers in this thread.
AFAICS just a respin with intel_vtd_active taking struct device is
needed and job done.
Sorry now I see I also suggested moving intel_scanout_needs_vtd_wa,
intel_ggtt_update_needs_vtd_wa and intel_vm_no_concurrent_access_wa all
to their respective files. Which I think is also correct. They are all
higher components which are asking intel_vtd a question and basing a
decision upon the answer. I don't think intel_vtd.h should contain
knowledge about a mix of other driver components.
Regards,
Tvrtko
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2)
== Series Details ==
Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2)
URL : https://patchwork.freedesktop.org/series/100851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11396 -> Patchwork_22643
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/index.html
Participating hosts (49 -> 43)
--
Missing(6): shard-tglu fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 shard-rkl
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22643:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@requests:
- {bat-adlm-1}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/bat-adlm-1/igt@i915_selftest@l...@requests.html
Known issues
Here are the changes found in Patchwork_22643 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0@smem:
- fi-glk-dsi: [PASS][2] -> [DMESG-WARN][3] ([i915#2943])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/fi-glk-dsi/igt@gem_exec_suspend@basic...@smem.html
Possible fixes
* igt@i915_selftest@live@evict:
- {bat-rpls-2}: [INCOMPLETE][4] -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@evict.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/bat-rpls-2/igt@i915_selftest@l...@evict.html
* igt@i915_selftest@live@objects:
- {bat-rpls-2}: [DMESG-WARN][6] ([i915#4391]) -> [PASS][7] +4 similar
issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@objects.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/bat-rpls-2/igt@i915_selftest@l...@objects.html
* igt@kms_force_connector_basic@force-connector-state:
- {bat-adlm-1}: [INCOMPLETE][8] ([i915#5361]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-adlm-1/igt@kms_force_connector_ba...@force-connector-state.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/bat-adlm-1/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u: [DMESG-WARN][10] ([i915#295] / [i915#5341]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][12] ([i915#295]) -> [PASS][13] +10
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22643/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#2943]: https://gitlab.freedesktop.org/drm/intel/issues/2943
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#5195]: https://gitlab.freedesktop.org/drm/intel/issues/5195
[i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
[i915#5361]: https://gitlab.freedesktop.org/drm/intel/issues/5361
Build changes
-
* Linux: CI_DRM_11396 -> Patchwork_22643
CI-20190529: 20190529
CI_DRM_11396: 18b88414e6c9660022bb464d4d5fadb07d38cf04 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6387: 04d012b18355b53798af5a55a8915afb1a421bba @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22643: 8d7fe49b240d8f4fb1a167594706ab916e4a78cb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8d7fe49b240d drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
== Logs ==
For more details see:
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On 22/03/2022 14:49, Jani Nikula wrote:
On Tue, 22 Mar 2022, Lucas De Marchi wrote:
On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
On Mon, 21 Mar 2022, Lucas De Marchi wrote:
On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
Wanted to ping this older thread to find out where we stand with this patch,
Are we OK with the current state of these changes?
With more recent information gathered from feedback on other patches, would
we prefer changing this to a more arch-neutral control flow?
e.g.
#if IS_ENABLED(CONFIG_X86)
...
#else
...
#endif
Would we also prefer this RFC series be merged or would it be preferred to
create a new series instead?
for this specific function, that is used in only 2 places I think it's
ok to do:
static inline bool run_as_guest(void)
{
#if IS_ENABLED(CONFIG_X86)
return !hypervisor_is_type(X86_HYPER_NATIVE);
#else
/* Not supported yet */
return false;
#endif
}
For PCH it doesn't really matter as we don't execute that function
for discrete. For intel_vtd_active() I figure anything other than
x86 would be fine with false here.
Jani, that this look good to you?
It's more important to me to get this out of i915_drv.h, which is not
supposed to be a collection of random stuff anymore. I've sent patches
to this effect but they've stalled a bit.
do you have a patch moving this particular one? got a link?
Yeah, but it was basically shot down by Tvrtko [1], and I stalled there.
I'd just like to get all this cruft out of i915_drv.h. Whenever we have
a file where the name isn't super specific, we seem to have a tendency
of turning it into a dumping ground for random crap. So I'd really like
to move this out of there *before* expanding on it.
Sounds like we had agreement on what tweaks to make and I conceded to
live for now with the IMO wrongly named intel_vtd_run_as_guest.
(I mean I really disagree with file name being trumps, which I think
this example illustrates - this is i915 asking whether the kernel is
running as guest so intel_vtd_ prefix is just wrong. Intel VT-d is the
iommu thingy so it makes no sense when called from PCH detection. But I
have no better ideas at the moment. We can call it i915_run_as_guest, to
signify function belongs to i915, but then we lose the first parameter
names the function rule.)
But in any case I don't see that I created any blockers in this thread.
AFAICS just a respin with intel_vtd_active taking struct device is
needed and job done.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 0/4] Drop wbinvd_on_all_cpus usage
On 3/22/22 13:53, Tvrtko Ursulin wrote: On 22/03/2022 11:37, Thomas Hellström wrote: On Tue, 2022-03-22 at 11:20 +, Tvrtko Ursulin wrote: On 22/03/2022 10:26, Thomas Hellström wrote: On Tue, 2022-03-22 at 10:13 +, Tvrtko Ursulin wrote: On 21/03/2022 15:15, Thomas Hellström wrote: On Mon, 2022-03-21 at 14:43 +, Tvrtko Ursulin wrote: On 21/03/2022 13:40, Thomas Hellström wrote: Hi, On Mon, 2022-03-21 at 13:12 +, Tvrtko Ursulin wrote: On 21/03/2022 12:33, Thomas Hellström wrote: On Mon, 2022-03-21 at 12:22 +, Tvrtko Ursulin wrote: On 21/03/2022 11:03, Thomas Hellström wrote: Hi, Tvrtko. On 3/21/22 11:27, Tvrtko Ursulin wrote: On 19/03/2022 19:42, Michael Cheng wrote: To align with the discussion in [1][2], this patch series drops all usage of wbvind_on_all_cpus within i915 by either replacing the call with certain drm clflush helpers, or reverting to a previous logic. AFAIU, complaint from [1] was that it is wrong to provide non x86 implementations under the wbinvd_on_all_cpus name. Instead an arch agnostic helper which achieves the same effect could be created. Does Arm have such concept? I also understand Linus' email like we shouldn't leak incoherent IO to other architectures, meaning any remaining wbinvd()s should be X86 only. The last part is completely obvious since it is a x86 instruction name. Yeah, I meant the function implementing wbinvd() semantics. But I think we can't pick a solution until we know how the concept maps to Arm and that will also include seeing how the drm_clflush_sg for Arm would look. Is there a range based solution, or just a big hammer there. If the latter, then it is no good to churn all these reverts but instead an arch agnostic wrapper, with a generic name, would be the way to go. But my impression was that ARM would not need the range- based interface either, because ARM is only for discrete and with discrete we're always coherent. Not sure what you mean here - what about flushing system memory objects on discrete? Those still need flushing on paths like suspend which this series touches. Am I missing something? System bos on discrete should always have I915_BO_CACHE_COHERENT_FOR_READ | I915_BO_CACHE_COHERENT_FOR_WRITE either by the gpu being fully cache coherent (or us mapping system write-combined). Hence no need for cache clflushes or wbinvd() for incoherent IO. Hmm so you are talking about the shmem ttm backend. It ends up depending on the result of i915_ttm_cache_level, yes? It cannot end up with I915_CACHE_NONE from that function? If the object is allocated with allowable placement in either LMEM or SYSTEM, and it ends in system, it gets allocated with I915_CACHE_NONE, but then the shmem ttm backend isn't used but TTM's wc pools, and the object should *always* be mapped wc. Even in system. I am not familiar with neither TTM backend or wc pools so maybe a missed question - if obj->cache_level can be set to none, and obj->cache_coherency to zero, then during object lifetime helpers which consult those fields (like i915_gem_cpu_write_needs_clflush, __start_cpu_write, etc) are giving out incorrect answers? That is, it is irrelevant that they would say flushes are required, since in actuality those objects can never ever and from anywhere be mapped other than WC so flushes aren't actually required? If we map other than WC somewhere in these situations, that should be a bug needing a fix. It might be that some of these helpers that you mention might still flag that a clflush is needed, and in that case that's an oversight that also needs fixing. I also found in i915_drm.h: * As caching mode when specifying `I915_MMAP_OFFSET_FIXED`, WC or WB will * be used, depending on the object placement on creation. WB will be used * when the object can only exist in system memory, WC otherwise. If what you say is true, that on discrete it is _always_ WC, then that needs updating as well. If an object is allocated as system only, then it is mapped WB, and we're relying on the gpu being cache coherent to avoid clflushes. Same is actually currently true if the object happens to be accessed by the cpu while evicted. Might need an update for that. Hmm okay, I think I actually misunderstood something here. I think the reason for difference bbtween smem+lmem object which happens to be in smem and smem only object is eluding me. That's adhering to Linus' "And I sincerely hope to the gods that no cache-incoherent i915 mess ever makes it out of the x86 world. Incoherent IO was always a historical mistake and should never ever happen again, so we should not spread that horrific pattern around." Sure, but I was not talking about IO - just the CPU side access to CPU side objects. OK, I was under the impression that clflushes() and wbinvd()s in i915 was only ever used to make data visible to non-snooping GPUs. Do you mean that there are other uses as well? Agreed the wb
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2)
== Series Details == Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2) URL : https://patchwork.freedesktop.org/series/100851/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On Tue, 22 Mar 2022, Lucas De Marchi wrote:
> On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
>>On Mon, 21 Mar 2022, Lucas De Marchi wrote:
>>> On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
Wanted to ping this older thread to find out where we stand with this patch,
Are we OK with the current state of these changes?
With more recent information gathered from feedback on other patches, would
we prefer changing this to a more arch-neutral control flow?
e.g.
#if IS_ENABLED(CONFIG_X86)
...
#else
...
#endif
Would we also prefer this RFC series be merged or would it be preferred to
create a new series instead?
>>>
>>> for this specific function, that is used in only 2 places I think it's
>>> ok to do:
>>>
>>> static inline bool run_as_guest(void)
>>> {
>>> #if IS_ENABLED(CONFIG_X86)
>>> return !hypervisor_is_type(X86_HYPER_NATIVE);
>>> #else
>>> /* Not supported yet */
>>> return false;
>>> #endif
>>> }
>>>
>>> For PCH it doesn't really matter as we don't execute that function
>>> for discrete. For intel_vtd_active() I figure anything other than
>>> x86 would be fine with false here.
>>>
>>> Jani, that this look good to you?
>>
>>It's more important to me to get this out of i915_drv.h, which is not
>>supposed to be a collection of random stuff anymore. I've sent patches
>>to this effect but they've stalled a bit.
>
> do you have a patch moving this particular one? got a link?
Yeah, but it was basically shot down by Tvrtko [1], and I stalled there.
I'd just like to get all this cruft out of i915_drv.h. Whenever we have
a file where the name isn't super specific, we seem to have a tendency
of turning it into a dumping ground for random crap. So I'd really like
to move this out of there *before* expanding on it.
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/99852/
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2)
== Series Details == Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities (rev2) URL : https://patchwork.freedesktop.org/series/100851/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8d7fe49b240d drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities -:38: WARNING:TYPO_SPELLING: 'capabilites' may be misspelled - perhaps 'capabilities'? #38: The standard requires the DPCD capabilites to be read after the LTTPR ^^^ -:58: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #58: FILE: drivers/gpu/drm/dp/drm_dp.c:2393: +static int drm_dp_read_lttpr_regs(struct drm_dp_aux *aux, const u8 dpcd[DP_RECEIVER_CAP_SIZE], int address, -:172: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #172: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:81: +static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp, const u8 dpcd[DP_RECEIVER_CAP_SIZE]) total: 0 errors, 3 warnings, 0 checks, 181 lines checked
[Intel-gfx] [PATCH v2] drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted
DPCD register values when reading from the 0xF- LTTPR range with an
AUX transaction block size bigger than 1. The DP standard requires 0 to
be returned - as for any other reserved/invalid addresses - but these
monitors return the DPCD_REV register value repeated in each byte of the
read buffer. This will in turn corrupt the values returned by the LTTPRs
between the source and the monitor: LTTPRs must adjust the values they
read from the downstream DPRX, for instance left-shift/init the
downstream DP_PHY_REPEATER_CNT value. Since the value returned by the
monitor's DPRX is non-zero the adjusted values will be corrupt.
Reading the LTTPR registers one-by-one instead of reading all of them
with a single AUX transfer works around the issue.
According to the DP standard's 0xF register description:
"LTTPR-related registers at DPCD Addresses Fh through F02FFh are
valid only for DPCD r1.4 (or higher)." While it's unclear if DPCD r1.4
refers to the DPCD_REV or to the
LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV register (tickets filed
at the VESA site to clarify this haven't been addressed), one
possibility is that it's a restriction due to non-compliant monitors
described above. Disabling the non-transparent LTTPR mode for all such
monitors is not a viable solution: the transparent LTTPR mode has its
own issue causing link training failures and this would affect a lot of
monitors in use with DPCD_REV < 1.4. Instead this patch works around
the problem by reading the LTTPR common and PHY cap registers one-by-one
for any monitor with a DPCD_REV < 1.4.
The standard requires the DPCD capabilites to be read after the LTTPR
common capabilities are read, so re-read the DPCD capabilities after
the LTTPR common and PHY caps were read out.
v2:
- Use for instead of a while loop. (Ville)
- Add to code comment the monitor model with the problem.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4531
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/dp/drm_dp.c | 57 ---
.../drm/i915/display/intel_dp_link_training.c | 30 +++---
include/drm/dp/drm_dp_helper.h| 2 +
3 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/dp/drm_dp.c b/drivers/gpu/drm/dp/drm_dp.c
index 703972ae14c64..58744f83931af 100644
--- a/drivers/gpu/drm/dp/drm_dp.c
+++ b/drivers/gpu/drm/dp/drm_dp.c
@@ -2390,9 +2390,35 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+static int drm_dp_read_lttpr_regs(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE], int address,
+ u8 *buf, int buf_size)
+{
+ /*
+* At least the DELL P2715Q monitor with a DPCD_REV < 0x14 returns
+* corrupted values when reading from the 0xF- range with a block
+* size bigger than 1.
+*/
+ int block_size = dpcd[DP_DPCD_REV] < 0x14 ? 1 : buf_size;
+ int offset;
+ int ret;
+
+ for (offset = 0; offset < buf_size; offset += block_size) {
+ ret = drm_dp_dpcd_read(aux,
+ address + offset,
+ [offset], block_size);
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != block_size);
+ }
+
+ return 0;
+}
+
/**
* drm_dp_read_lttpr_common_caps - read the LTTPR common capabilities
* @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
* @caps: buffer to return the capability info in
*
* Read capabilities common to all LTTPRs.
@@ -2400,25 +2426,19 @@ EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
* Returns 0 on success or a negative error code on failure.
*/
int drm_dp_read_lttpr_common_caps(struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
u8 caps[DP_LTTPR_COMMON_CAP_SIZE])
{
- int ret;
-
- ret = drm_dp_dpcd_read(aux,
-
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
- caps, DP_LTTPR_COMMON_CAP_SIZE);
- if (ret < 0)
- return ret;
-
- WARN_ON(ret != DP_LTTPR_COMMON_CAP_SIZE);
-
- return 0;
+ return drm_dp_read_lttpr_regs(aux, dpcd,
+
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
+ caps, DP_LTTPR_COMMON_CAP_SIZE);
}
EXPORT_SYMBOL(drm_dp_read_lttpr_common_caps);
/**
* drm_dp_read_lttpr_phy_caps - read the capabilities for a given LTTPR PHY
* @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
* @dp_phy: LTTPR PHY to read the capabilities for
* @caps: buffer to return the capability info in
*
@@ -2427,20 +2447,13 @@
Re: [Intel-gfx] [PATCH 1/4] i915/gem: drop wbinvd_on_all_cpus usage
On Mon, Mar 21, 2022 at 10:42:03AM -0700, Michael Cheng wrote: > > On 2022-03-21 10:28 a.m., Tvrtko Ursulin wrote: > > > > On 21/03/2022 16:31, Michael Cheng wrote: > > > On 2022-03-21 3:30 a.m., Tvrtko Ursulin wrote: > > > > > > > > > > > On 19/03/2022 19:42, Michael Cheng wrote: > > > > > Previous concern with using drm_clflush_sg was that we don't > > > > > know what the > > > > > sg_table is pointing to, thus the usage of wbinvd_on_all_cpus to flush > > > > > everything at once to avoid paranoia. > > > > > > > > And now we know, or we know it is not a concern? > > > > > > > > > To make i915 more architecture-neutral and be less paranoid, > > > > > lets attempt to > > > > > > > > "Lets attempt" as we don't know if this will work and/or what > > > > can/will break? > > > > > > Yes, but it seems like there's no regression with IGT . > > > > > > If there's a big hit in performance, or if this solution gets > > > accepted and the bug reports come flying in, we can explore other > > > solutions. But speaking to Dan Vetter, ideal solution would be to > > > avoid any calls directly to wbinvd, and use drm helpers in place. > > > > > > +Daniel for any extra input. > > > > > > > > use drm_clflush_sg to flush the pages for when the GPU wants to read > > > > > from main memory. > > > > > > > > > > Signed-off-by: Michael Cheng > > > > > --- > > > > > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 ++--- > > > > > 1 file changed, 2 insertions(+), 7 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > > > > > b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > > > > > index f5062d0c6333..b0a5baaebc43 100644 > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c > > > > > @@ -8,6 +8,7 @@ > > > > > #include > > > > > #include > > > > > #include > > > > > +#include > > > > > #include > > > > > @@ -250,16 +251,10 @@ static int > > > > > i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object > > > > > *obj) > > > > > * DG1 is special here since it still snoops > > > > > transactions even with > > > > > * CACHE_NONE. This is not the case with other > > > > > HAS_SNOOP platforms. We > > > > > * might need to revisit this as we add new discrete platforms. > > > > > - * > > > > > - * XXX: Consider doing a vmap flush or something, where possible. > > > > > - * Currently we just do a heavy handed > > > > > wbinvd_on_all_cpus() here since > > > > > - * the underlying sg_table might not even point to > > > > > struct pages, so we > > > > > - * can't just call drm_clflush_sg or similar, like we > > > > > do elsewhere in > > > > > - * the driver. > > > > > */ > > > > > if (i915_gem_object_can_bypass_llc(obj) || > > > > > (!HAS_LLC(i915) && !IS_DG1(i915))) > > > > > - wbinvd_on_all_cpus(); > > > > > + drm_clflush_sg(pages); > > > > > > > > And as noticed before, drm_clfush_sg still can call > > > > wbinvd_on_all_cpus so are you just punting the issue somewhere > > > > else? How will it be solved there? > > > > > > > Instead of calling an x86 asm directly, we are using what's > > > available to use to make the driver more architecture neutral. > > > Agreeing with Thomas, this solution falls within the "prefer > > > range-aware clflush apis", and since some other generation platform > > > doesn't support clflushopt, it will fall back to using wbinvd. > > > > Right, I was trying to get the information on what will drm_clflush_sg > > do on Arm. Is it range based or global there, or if the latter exists. > > > I am not too sure about the ARM side. We are currently working that out with > the ARM folks in a different thread. It won't do anything useful on arm. The _only_ way to get special memory on arm is by specifying what you want at allocation time. Anything else is busted, more or less. Which is why none of these code paths should run on anything else than x86. And even on x86 they're at best questionable, but some of these are mistakes encoded into uapi and we're stuck. We should still try to use drm_clflush_sg() imo to make the entire ordeal less horrible, and if that turns out to be problematic, we need to bite the bullet and fix the uapi architecture instead of trying to retroshoehorn performance fixes into uapi that just can't do it properly. In this case here this would mean fixing allocation flags with GEM_CREATE_EXT and fixing userspace to use that when needed (it should know already since pretty much all drivers have this issue in some form or another). Cheers, Daniel > > Regards, > > > > Tvrtko -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [RFC PATCH v3 1/1] i915/drm: Split out x86/arm64 for run_as_guest
On Tue, Mar 22, 2022 at 12:21:59PM +0200, Jani Nikula wrote:
On Mon, 21 Mar 2022, Lucas De Marchi wrote:
On Mon, Mar 21, 2022 at 04:34:49PM -0700, Casey Bowman wrote:
Wanted to ping this older thread to find out where we stand with this patch,
Are we OK with the current state of these changes?
With more recent information gathered from feedback on other patches, would
we prefer changing this to a more arch-neutral control flow?
e.g.
#if IS_ENABLED(CONFIG_X86)
...
#else
...
#endif
Would we also prefer this RFC series be merged or would it be preferred to
create a new series instead?
for this specific function, that is used in only 2 places I think it's
ok to do:
static inline bool run_as_guest(void)
{
#if IS_ENABLED(CONFIG_X86)
return !hypervisor_is_type(X86_HYPER_NATIVE);
#else
/* Not supported yet */
return false;
#endif
}
For PCH it doesn't really matter as we don't execute that function
for discrete. For intel_vtd_active() I figure anything other than
x86 would be fine with false here.
Jani, that this look good to you?
It's more important to me to get this out of i915_drv.h, which is not
supposed to be a collection of random stuff anymore. I've sent patches
to this effect but they've stalled a bit.
do you have a patch moving this particular one? got a link?
Lucas De Marchi
Re: [Intel-gfx] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
On Tue, Mar 22, 2022 at 09:55:35AM -0400, Mark Pearson wrote:
> Hi,
>
> On 3/21/22 06:49, Stanislav Lisovskiy wrote:
> > We are currently getting FIFO underruns, in particular
> > when PSR2 is enabled. There seem to be no existing workaround
> > or patches, which can fix that issue(were expecting some recent
> > selective fetch update and DBuf bw/SAGV fixes to help,
> > which unfortunately didn't).
> > Current idea is that it looks like for some reason the
> > DBuf prefill time isn't enough once we exit PSR2, despite its
> > theoretically correct.
> > So bump it up a bit by 15%(minimum experimental amount required
> > to get it working), if PSR2 is enabled.
> > For PSR1 there is no need in this hack, so we limit it only
> > to PSR2 and Alderlake.
> >
> > v2: - Added comment(Jose Souza)
> > - Fixed 15% calculation(Jose Souza)
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index fda8b701..92d57869983a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct
> > intel_crtc_state *crtc_state)
> > dev_priv->max_cdclk_freq));
> > }
> >
> > +
> > + /*
> > +* HACK. We are getting FIFO underruns, in particular
> > +* when PSR2 is enabled. There seem to be no existing workaround
> > +* or patches as of now.
> > +* Current idea is that it looks like for some reason the
> > +* DBuf prefill time isn't enough once we exit PSR2, despite its
> > +* theoretically correct.
> > +* So bump it up a bit by 15%(minimum experimental amount required
> > +* to get it working), if PSR2 is enabled.
> > +* For PSR1 there is no need in this hack, so we limit it only
> > +* to PSR2 and Alderlake.
> > +*/
> > + if (IS_ALDERLAKE_P(dev_priv)) {
> > + struct intel_encoder *encoder;
> > +
> > + for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > + if (intel_dp->psr.psr2_enabled) {
> > + min_cdclk = DIV_ROUND_UP(min_cdclk * 115, 100);
> > + break;
> > + }
> > + }
> > + }
> > +
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > drm_dbg_kms(_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>
> Not sure if this will get thru as I'm not subscribed to this list but I
> tested the patch below on my X1 Yoga 7 (Intel ADL-P with Step C0
> silicon) and it didn't fix some screen tearing issues I'm seeing there
> that are PSR2 related
>
> I also tried increasing the timeout to *300 to see if that made any
> difference and it didn't.
>
> Let me know if there's anything else I can try out - I have a couple of
> ADL-P machines I can test against and both are seeing screen tearing
Are you getting this screen tearing because of the FIFO underruns?
Those should be visible in dmesg. This patch can fix only part of underrun
issues caused by PSR2.
If your screen tearing caused by PSR2, but there are no underruns that
patch won't help for sure.
Stan
>
> Thanks
> Mark
[Intel-gfx] ✓ Fi.CI.BAT: success for Handle the DG2 max bw properly
== Series Details ==
Series: Handle the DG2 max bw properly
URL : https://patchwork.freedesktop.org/series/101635/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11396 -> Patchwork_22642
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/index.html
Participating hosts (48 -> 42)
--
Missing(6): shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22642 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2] ([i915#3303])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-kbl-soraka: [PASS][3] -> [INCOMPLETE][4] ([i915#4116])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][5] ([i915#1436] / [i915#4312] /
[i915#5257])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/fi-kbl-soraka/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][6] ([fdo#109271] / [i915#1436] /
[i915#4312])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][7] ([i915#4494] / [i915#4957]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- {fi-hsw-g3258}: [INCOMPLETE][9] ([i915#4785]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@uncore:
- {bat-rpls-2}: [DMESG-WARN][11] ([i915#4391]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@uncore.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/bat-rpls-2/igt@i915_selftest@l...@uncore.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][13] ([i915#3576]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u: [DMESG-WARN][15] ([i915#295] / [i915#5341]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][17] ([i915#295]) -> [PASS][18] +10
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22642/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4116]: https://gitlab.freedesktop.org/drm/intel/issues/4116
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#4983]:
[Intel-gfx] ✓ Fi.CI.IGT: success for Use drm_clflush* instead of clflush
== Series Details ==
Series: Use drm_clflush* instead of clflush
URL : https://patchwork.freedesktop.org/series/101611/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11395_full -> Patchwork_22635_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22635_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {shard-rkl}:([FAIL][1], [FAIL][2], [FAIL][3]) ([i915#2029] /
[i915#3002] / [i915#4312]) -> ([FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7])
([i915#3002] / [i915#4312])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@run...@aborted.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@run...@aborted.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@run...@aborted.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-2/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-5/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-1/igt@run...@aborted.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-rkl-2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_22635_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-glk: ([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], [PASS][22], [PASS][23],
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [FAIL][28], [PASS][29],
[PASS][30], [PASS][31]) ([i915#4392]) -> ([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], [PASS][45], [PASS][46],
[PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52],
[PASS][53], [PASS][54], [PASS][55], [PASS][56])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-glk1/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-glk1/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-glk2/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-glk2/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22635/shard-glk2/boot.html
[37]:
Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/guc: use the memcpy_from_wc call from the drm
On 21.03.2022 14:14, Lucas De Marchi wrote:
> On Thu, Mar 03, 2022 at 11:30:10PM +0530, Balasubramani Vivekanandan wrote:
> > memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
> > by the implementation in drm_cache.c.
> > Updated to use the functions provided by drm_cache.c.
> >
> > v2: Check if the log object allocated from local memory or system memory
> >and according setup the iosys_map (Lucas)
> >
> > Cc: Lucas De Marchi
> >
> > Signed-off-by: Balasubramani Vivekanandan
> >
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > index a24dc6441872..b9db765627ea 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
> > @@ -3,6 +3,7 @@
> > * Copyright © 2014-2019 Intel Corporation
> > */
> >
> > +#include
> > #include
> > #include
> >
> > @@ -206,6 +207,7 @@ static void guc_read_update_log_buffer(struct
> > intel_guc_log *log)
> > enum guc_log_buffer_type type;
> > void *src_data, *dst_data;
> > bool new_overflow;
> > + struct iosys_map src_map;
> >
> > mutex_lock(>relay.lock);
> >
> > @@ -282,14 +284,21 @@ static void guc_read_update_log_buffer(struct
> > intel_guc_log *log)
> > }
> >
> > /* Just copy the newly written data */
> > + if (i915_gem_object_is_lmem(log->vma->obj))
> > + iosys_map_set_vaddr_iomem(_map, (void __iomem
> > *)src_data);
> > + else
> > + iosys_map_set_vaddr(_map, src_data);
>
> It would be better to keep this outside of the loop. So inside the loop
> we can use only iosys_map_incr(_map, buffer_size). However you'd
> also have to handle the read_offset. The iosys_map_ API has both a
> src_offset and dst_offset due to situations like that. Maybe this is
> missing in the new drm_memcpy_* function you're adding?
>
> This function was not correct wrt to IO memory access with the other
> 2 places in this function doing plain memcpy(). Since we are starting to
> use iosys_map here, we probably should handle this commit as "migrate to
> iosys_map", and convert those. In your current final state
> we have 3 variables aliasing the same memory location. IMO it will be
> error prone to keep it like that
yes, it is a good suggestion to completely change the reading of the GuC
log for the relay to use the iosys_map interfaces.
Though it was planned eventually, doing it now with this series will
avoid mixing of memcpy() and drm_memcpy_*(which needs iosys_map
parameters) functions.
I will do the changes.
>
> +Michal, some questions:
>
> - I'm not very familiar with the relayfs API. Is the `dst_data += PAGE_SIZE;`
> really correct?
>
> - Could you double check this patch and ack if ok?
>
> Heads up that since the log buffer is potentially in lmem, we will need
> to convert this function to take that into account. All those accesses
> to log_buf_state need to use the proper kernel abstraction for system vs
> I/O memory.
>
> thanks
> Lucas De Marchi
>
> > +
> > if (read_offset > write_offset) {
> > - i915_memcpy_from_wc(dst_data, src_data, write_offset);
> > + drm_memcpy_from_wc_vaddr(dst_data, _map,
> > +write_offset);
> > bytes_to_copy = buffer_size - read_offset;
> > } else {
> > bytes_to_copy = write_offset - read_offset;
> > }
> > - i915_memcpy_from_wc(dst_data + read_offset,
> > - src_data + read_offset, bytes_to_copy);
> > + iosys_map_incr(_map, read_offset);
> > + drm_memcpy_from_wc_vaddr(dst_data + read_offset, _map,
> > +bytes_to_copy);
> >
> > src_data += buffer_size;
> > dst_data += buffer_size;
> > --
> > 2.25.1
> >
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Handle the DG2 max bw properly
== Series Details == Series: Handle the DG2 max bw properly URL : https://patchwork.freedesktop.org/series/101635/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
On Tue, 2022-03-22 at 09:49 +0200, Lisovskiy, Stanislav wrote:
> On Mon, Mar 21, 2022 at 07:01:27PM +0200, Souza, Jose wrote:
> > On Mon, 2022-03-21 at 12:49 +0200, Stanislav Lisovskiy wrote:
> > > We are currently getting FIFO underruns, in particular
> > > when PSR2 is enabled. There seem to be no existing workaround
> > > or patches, which can fix that issue(were expecting some recent
> > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > which unfortunately didn't).
> > > Current idea is that it looks like for some reason the
> > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > theoretically correct.
> > > So bump it up a bit by 15%(minimum experimental amount required
> > > to get it working), if PSR2 is enabled.
> > > For PSR1 there is no need in this hack, so we limit it only
> > > to PSR2 and Alderlake.
> > >
> > > v2: - Added comment(Jose Souza)
> > > - Fixed 15% calculation(Jose Souza)
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++
> > > 1 file changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index fda8b701..92d57869983a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct
> > > intel_crtc_state *crtc_state)
> > > dev_priv->max_cdclk_freq));
> > > }
> > >
> > > +
> > > + /*
> > > + * HACK. We are getting FIFO underruns, in particular
> > > + * when PSR2 is enabled. There seem to be no existing workaround
> > > + * or patches as of now.
> > > + * Current idea is that it looks like for some reason the
> > > + * DBuf prefill time isn't enough once we exit PSR2, despite its
> > > + * theoretically correct.
> > > + * So bump it up a bit by 15%(minimum experimental amount required
> > > + * to get it working), if PSR2 is enabled.
> > > + * For PSR1 there is no need in this hack, so we limit it only
> > > + * to PSR2 and Alderlake.
> > > + */
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> >
> >
> > And please check if we can only apply this when two or more pipes are
> > enabled.
> > Otherwise this will impact power numbers in the case that is matters most.
>
> That one I can check. Probably need someone at office to disconnect all the
> pipes, except eDP to see
> if its still reproducible, however I think I've seen it already happening.
You can have some hack code in the functions that check if a port is connected
and return false for all ports other than port A/eDP.
>
> Stan
>
> >
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + if (intel_dp->psr.psr2_enabled) {
> > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 115, 100);
> > > + break;
> > > + }
> > > + }
> > > + }
> > > +
> > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > drm_dbg_kms(_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
On Tue, 2022-03-22 at 15:30 +0200, Lisovskiy, Stanislav wrote:
> On Tue, Mar 22, 2022 at 03:16:41PM +0200, Souza, Jose wrote:
> > On Tue, 2022-03-22 at 09:48 +0200, Lisovskiy, Stanislav wrote:
> > > On Mon, Mar 21, 2022 at 06:58:39PM +0200, Souza, Jose wrote:
> > > > On Mon, 2022-03-21 at 12:49 +0200, Stanislav Lisovskiy wrote:
> > > > > We are currently getting FIFO underruns, in particular
> > > > > when PSR2 is enabled. There seem to be no existing workaround
> > > > > or patches, which can fix that issue(were expecting some recent
> > > > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > > > which unfortunately didn't).
> > > > > Current idea is that it looks like for some reason the
> > > > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > > theoretically correct.
> > > > > So bump it up a bit by 15%(minimum experimental amount required
> > > > > to get it working), if PSR2 is enabled.
> > > > > For PSR1 there is no need in this hack, so we limit it only
> > > > > to PSR2 and Alderlake.
> > > > >
> > > > > v2: - Added comment(Jose Souza)
> > > > > - Fixed 15% calculation(Jose Souza)
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 26
> > > > > ++
> > > > > 1 file changed, 26 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > index fda8b701..92d57869983a 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > > @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct
> > > > > intel_crtc_state *crtc_state)
> > > > > dev_priv->max_cdclk_freq));
> > > > > }
> > > > >
> > > > > +
> > > > > + /*
> > > > > + * HACK. We are getting FIFO underruns, in particular
> > > > > + * when PSR2 is enabled. There seem to be no existing workaround
> > > > > + * or patches as of now.
> > > > > + * Current idea is that it looks like for some reason the
> > > > > + * DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > > + * theoretically correct.
> > > > > + * So bump it up a bit by 15%(minimum experimental amount
> > > > > required
> > > > > + * to get it working), if PSR2 is enabled.
> > > > > + * For PSR1 there is no need in this hack, so we limit it only
> > > > > + * to PSR2 and Alderlake.
> > > > > + */
> > > > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > > > + struct intel_encoder *encoder;
> > > > > +
> > > > > + for_each_intel_encoder_with_psr(_priv->drm,
> > > > > encoder) {
> > > > > + struct intel_dp *intel_dp =
> > > > > enc_to_intel_dp(encoder);
> > > > > +
> > > > > + if (intel_dp->psr.psr2_enabled) {
> > > >
> > > > Again, you can't use this, PSR could end up disabled when this atomic
> > > > commit it applied.
> > > > Please use intel_crtc_state.has_psr2.
> > >
> > > Yes, but if PSR2 is disabled - we don't need this hack, we can live with
> > > lower
> > > CDCLK then, thus saving power. And once PSR2 is enabled we'll have to
> > > switch it
> > > on. I intentionally didn't want to enable it always, if PSR2 is supported
> > > in principle - we care only if its indeed enabled.
> >
> > The problem is that this code don't handle this cases.
> > intel_dp->psr.psr2_enabled has the current PSR2 state, while crtc_state
> > have the future(as soon as this state is applied) PSR2 state.
> > You should avoid access global state as much as possible during the atomic
> > check phase.
> >
> > In a case like, PSR2 disabled going to to a state with PSR2 enabled will
> > cause this workaround to not be applied.
>
> Ah ok, so that intel_dp->psr.psr2_enabled isn't part of committed state,
> actually yes, that explains -
> I use only dev_priv to get it, but not atomic state.
>
> So has_psr2 indicates the state to be committed? Actually I saw it being
> assigned to psr2_enabled in
> some places, but wasn't sure.
When the state is in commit phase psr2_enabled it will eventually be assigned
but at intel_crtc_compute_min_cdclk() you need to check has_psr2.
> Then need to use that one. The name is a bit confusing then.
>
> Stan
>
> >
> > > Also CDCLK is the last thing, which is being calculated, thats how
> > > architecture
> > > is designed, so we can rely on all the states here, if you mean that.
> > >
> > > Even if this would be not working(not aware why but still), would anyway
> > > prefer
> > > to find someway to enable this only, when PSR2 is indeed enabled,
> > > otherwise
> > > we would be kind of wasting power..
> > >
> > >
> > > Stan
> > >
> > > >
> > > >
> > > > > + min_cdclk = DIV_ROUND_UP(min_cdclk *
> > > > > 115, 100);
> > > > > +
Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
On Tue, Mar 22, 2022 at 03:16:41PM +0200, Souza, Jose wrote:
> On Tue, 2022-03-22 at 09:48 +0200, Lisovskiy, Stanislav wrote:
> > On Mon, Mar 21, 2022 at 06:58:39PM +0200, Souza, Jose wrote:
> > > On Mon, 2022-03-21 at 12:49 +0200, Stanislav Lisovskiy wrote:
> > > > We are currently getting FIFO underruns, in particular
> > > > when PSR2 is enabled. There seem to be no existing workaround
> > > > or patches, which can fix that issue(were expecting some recent
> > > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > > which unfortunately didn't).
> > > > Current idea is that it looks like for some reason the
> > > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > theoretically correct.
> > > > So bump it up a bit by 15%(minimum experimental amount required
> > > > to get it working), if PSR2 is enabled.
> > > > For PSR1 there is no need in this hack, so we limit it only
> > > > to PSR2 and Alderlake.
> > > >
> > > > v2: - Added comment(Jose Souza)
> > > > - Fixed 15% calculation(Jose Souza)
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++
> > > > 1 file changed, 26 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index fda8b701..92d57869983a 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct
> > > > intel_crtc_state *crtc_state)
> > > > dev_priv->max_cdclk_freq));
> > > > }
> > > >
> > > > +
> > > > + /*
> > > > +* HACK. We are getting FIFO underruns, in particular
> > > > +* when PSR2 is enabled. There seem to be no existing workaround
> > > > +* or patches as of now.
> > > > +* Current idea is that it looks like for some reason the
> > > > +* DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > +* theoretically correct.
> > > > +* So bump it up a bit by 15%(minimum experimental amount
> > > > required
> > > > +* to get it working), if PSR2 is enabled.
> > > > +* For PSR1 there is no need in this hack, so we limit it only
> > > > +* to PSR2 and Alderlake.
> > > > +*/
> > > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > > + struct intel_encoder *encoder;
> > > > +
> > > > + for_each_intel_encoder_with_psr(_priv->drm,
> > > > encoder) {
> > > > + struct intel_dp *intel_dp =
> > > > enc_to_intel_dp(encoder);
> > > > +
> > > > + if (intel_dp->psr.psr2_enabled) {
> > >
> > > Again, you can't use this, PSR could end up disabled when this atomic
> > > commit it applied.
> > > Please use intel_crtc_state.has_psr2.
> >
> > Yes, but if PSR2 is disabled - we don't need this hack, we can live with
> > lower
> > CDCLK then, thus saving power. And once PSR2 is enabled we'll have to
> > switch it
> > on. I intentionally didn't want to enable it always, if PSR2 is supported
> > in principle - we care only if its indeed enabled.
>
> The problem is that this code don't handle this cases.
> intel_dp->psr.psr2_enabled has the current PSR2 state, while crtc_state have
> the future(as soon as this state is applied) PSR2 state.
> You should avoid access global state as much as possible during the atomic
> check phase.
>
> In a case like, PSR2 disabled going to to a state with PSR2 enabled will
> cause this workaround to not be applied.
Ah ok, so that intel_dp->psr.psr2_enabled isn't part of committed state,
actually yes, that explains -
I use only dev_priv to get it, but not atomic state.
So has_psr2 indicates the state to be committed? Actually I saw it being
assigned to psr2_enabled in
some places, but wasn't sure.
Then need to use that one. The name is a bit confusing then.
Stan
>
> > Also CDCLK is the last thing, which is being calculated, thats how
> > architecture
> > is designed, so we can rely on all the states here, if you mean that.
> >
> > Even if this would be not working(not aware why but still), would anyway
> > prefer
> > to find someway to enable this only, when PSR2 is indeed enabled, otherwise
> > we would be kind of wasting power..
> >
> >
> > Stan
> >
> > >
> > >
> > > > + min_cdclk = DIV_ROUND_UP(min_cdclk *
> > > > 115, 100);
> > > > + break;
> > > > + }
> > > > + }
> > > > + }
> > > > +
> > > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > > drm_dbg_kms(_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d
> > > > kHz)\n",
> > >
>
Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
On Tue, 2022-03-22 at 09:48 +0200, Lisovskiy, Stanislav wrote:
> On Mon, Mar 21, 2022 at 06:58:39PM +0200, Souza, Jose wrote:
> > On Mon, 2022-03-21 at 12:49 +0200, Stanislav Lisovskiy wrote:
> > > We are currently getting FIFO underruns, in particular
> > > when PSR2 is enabled. There seem to be no existing workaround
> > > or patches, which can fix that issue(were expecting some recent
> > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > which unfortunately didn't).
> > > Current idea is that it looks like for some reason the
> > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > theoretically correct.
> > > So bump it up a bit by 15%(minimum experimental amount required
> > > to get it working), if PSR2 is enabled.
> > > For PSR1 there is no need in this hack, so we limit it only
> > > to PSR2 and Alderlake.
> > >
> > > v2: - Added comment(Jose Souza)
> > > - Fixed 15% calculation(Jose Souza)
> > >
> > > Signed-off-by: Stanislav Lisovskiy
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++
> > > 1 file changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index fda8b701..92d57869983a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2325,6 +2325,32 @@ int intel_crtc_compute_min_cdclk(const struct
> > > intel_crtc_state *crtc_state)
> > > dev_priv->max_cdclk_freq));
> > > }
> > >
> > > +
> > > + /*
> > > + * HACK. We are getting FIFO underruns, in particular
> > > + * when PSR2 is enabled. There seem to be no existing workaround
> > > + * or patches as of now.
> > > + * Current idea is that it looks like for some reason the
> > > + * DBuf prefill time isn't enough once we exit PSR2, despite its
> > > + * theoretically correct.
> > > + * So bump it up a bit by 15%(minimum experimental amount required
> > > + * to get it working), if PSR2 is enabled.
> > > + * For PSR1 there is no need in this hack, so we limit it only
> > > + * to PSR2 and Alderlake.
> > > + */
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_intel_encoder_with_psr(_priv->drm, encoder) {
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + if (intel_dp->psr.psr2_enabled) {
> >
> > Again, you can't use this, PSR could end up disabled when this atomic
> > commit it applied.
> > Please use intel_crtc_state.has_psr2.
>
> Yes, but if PSR2 is disabled - we don't need this hack, we can live with lower
> CDCLK then, thus saving power. And once PSR2 is enabled we'll have to switch
> it
> on. I intentionally didn't want to enable it always, if PSR2 is supported in
> principle - we care only if its indeed enabled.
The problem is that this code don't handle this cases.
intel_dp->psr.psr2_enabled has the current PSR2 state, while crtc_state have
the future(as soon as this state is applied) PSR2 state.
You should avoid access global state as much as possible during the atomic
check phase.
In a case like, PSR2 disabled going to to a state with PSR2 enabled will cause
this workaround to not be applied.
> Also CDCLK is the last thing, which is being calculated, thats how
> architecture
> is designed, so we can rely on all the states here, if you mean that.
>
> Even if this would be not working(not aware why but still), would anyway
> prefer
> to find someway to enable this only, when PSR2 is indeed enabled, otherwise
> we would be kind of wasting power..
>
>
> Stan
>
> >
> >
> > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 115, 100);
> > > + break;
> > > + }
> > > + }
> > > + }
> > > +
> > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > drm_dbg_kms(_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Random cleanups
== Series Details ==
Series: drm/i915: Random cleanups
URL : https://patchwork.freedesktop.org/series/101607/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11395_full -> Patchwork_22634_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22634_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22634_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22634_full:
### IGT changes ###
Possible regressions
* igt@kms_rotation_crc@primary-y-tiled-reflect-x-180:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-tglb1/igt@kms_rotation_...@primary-y-tiled-reflect-x-180.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-tglb8/igt@kms_rotation_...@primary-y-tiled-reflect-x-180.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_plane_multiple@atomic-pipe-c-tiling-4:
- {shard-rkl}:[SKIP][3] ([i915#4070]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-rkl-1/igt@kms_plane_multi...@atomic-pipe-c-tiling-4.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-rkl-4/igt@kms_plane_multi...@atomic-pipe-c-tiling-4.html
Known issues
Here are the changes found in Patchwork_22634_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-skl: ([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], [PASS][22], [PASS][23], [FAIL][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]) ([i915#5032])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl8/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl9/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl9/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl7/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl7/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl4/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl4/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl1/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl1/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl10/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl10/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-skl10/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl7/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl4/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl4/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl4/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl3/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl2/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl10/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl10/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl10/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22634/shard-skl9/boot.html
[34]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix up DP DFP 4:2:0 handling more (rev2)
== Series Details ==
Series: drm/i915: Fix up DP DFP 4:2:0 handling more (rev2)
URL : https://patchwork.freedesktop.org/series/95881/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11396 -> Patchwork_22641
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/index.html
Participating hosts (48 -> 42)
--
Missing(6): shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22641:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@objects:
- {bat-rpls-2}: [DMESG-WARN][1] ([i915#4391]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@objects.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/bat-rpls-2/igt@i915_selftest@l...@objects.html
Known issues
Here are the changes found in Patchwork_22641 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-cfl-8109u: [PASS][3] -> [DMESG-WARN][4] ([i915#203] / [i915#262]
/ [i915#295])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
* igt@gem_exec_suspend@basic-s0@smem:
- fi-cfl-8109u: [PASS][5] -> [DMESG-WARN][6] ([i915#203] / [i915#295])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][7] ([i915#4494] / [i915#4957]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@uncore:
- {bat-rpls-2}: [DMESG-WARN][9] ([i915#4391]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@uncore.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/bat-rpls-2/igt@i915_selftest@l...@uncore.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-cfl-8109u: [DMESG-WARN][11] ([i915#295] / [i915#5341]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][13] ([i915#295]) -> [PASS][14] +10
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22641/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
[i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
[i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342
Build changes
-
* Linux: CI_DRM_11396 -> Patchwork_22641
CI-20190529: 20190529
CI_DRM_11396: 18b88414e6c9660022bb464d4d5fadb07d38cf04 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6387: 04d012b18355b53798af5a55a8915afb1a421bba @
Re: [Intel-gfx] [PATCH 0/4] Drop wbinvd_on_all_cpus usage
On 22/03/2022 11:37, Thomas Hellström wrote: On Tue, 2022-03-22 at 11:20 +, Tvrtko Ursulin wrote: On 22/03/2022 10:26, Thomas Hellström wrote: On Tue, 2022-03-22 at 10:13 +, Tvrtko Ursulin wrote: On 21/03/2022 15:15, Thomas Hellström wrote: On Mon, 2022-03-21 at 14:43 +, Tvrtko Ursulin wrote: On 21/03/2022 13:40, Thomas Hellström wrote: Hi, On Mon, 2022-03-21 at 13:12 +, Tvrtko Ursulin wrote: On 21/03/2022 12:33, Thomas Hellström wrote: On Mon, 2022-03-21 at 12:22 +, Tvrtko Ursulin wrote: On 21/03/2022 11:03, Thomas Hellström wrote: Hi, Tvrtko. On 3/21/22 11:27, Tvrtko Ursulin wrote: On 19/03/2022 19:42, Michael Cheng wrote: To align with the discussion in [1][2], this patch series drops all usage of wbvind_on_all_cpus within i915 by either replacing the call with certain drm clflush helpers, or reverting to a previous logic. AFAIU, complaint from [1] was that it is wrong to provide non x86 implementations under the wbinvd_on_all_cpus name. Instead an arch agnostic helper which achieves the same effect could be created. Does Arm have such concept? I also understand Linus' email like we shouldn't leak incoherent IO to other architectures, meaning any remaining wbinvd()s should be X86 only. The last part is completely obvious since it is a x86 instruction name. Yeah, I meant the function implementing wbinvd() semantics. But I think we can't pick a solution until we know how the concept maps to Arm and that will also include seeing how the drm_clflush_sg for Arm would look. Is there a range based solution, or just a big hammer there. If the latter, then it is no good to churn all these reverts but instead an arch agnostic wrapper, with a generic name, would be the way to go. But my impression was that ARM would not need the range- based interface either, because ARM is only for discrete and with discrete we're always coherent. Not sure what you mean here - what about flushing system memory objects on discrete? Those still need flushing on paths like suspend which this series touches. Am I missing something? System bos on discrete should always have I915_BO_CACHE_COHERENT_FOR_READ | I915_BO_CACHE_COHERENT_FOR_WRITE either by the gpu being fully cache coherent (or us mapping system write-combined). Hence no need for cache clflushes or wbinvd() for incoherent IO. Hmm so you are talking about the shmem ttm backend. It ends up depending on the result of i915_ttm_cache_level, yes? It cannot end up with I915_CACHE_NONE from that function? If the object is allocated with allowable placement in either LMEM or SYSTEM, and it ends in system, it gets allocated with I915_CACHE_NONE, but then the shmem ttm backend isn't used but TTM's wc pools, and the object should *always* be mapped wc. Even in system. I am not familiar with neither TTM backend or wc pools so maybe a missed question - if obj->cache_level can be set to none, and obj->cache_coherency to zero, then during object lifetime helpers which consult those fields (like i915_gem_cpu_write_needs_clflush, __start_cpu_write, etc) are giving out incorrect answers? That is, it is irrelevant that they would say flushes are required, since in actuality those objects can never ever and from anywhere be mapped other than WC so flushes aren't actually required? If we map other than WC somewhere in these situations, that should be a bug needing a fix. It might be that some of these helpers that you mention might still flag that a clflush is needed, and in that case that's an oversight that also needs fixing. I also found in i915_drm.h: * As caching mode when specifying `I915_MMAP_OFFSET_FIXED`, WC or WB will * be used, depending on the object placement on creation. WB will be used * when the object can only exist in system memory, WC otherwise. If what you say is true, that on discrete it is _always_ WC, then that needs updating as well. If an object is allocated as system only, then it is mapped WB, and we're relying on the gpu being cache coherent to avoid clflushes. Same is actually currently true if the object happens to be accessed by the cpu while evicted. Might need an update for that. Hmm okay, I think I actually misunderstood something here. I think the reason for difference bbtween smem+lmem object which happens to be in smem and smem only object is eluding me. That's adhering to Linus' "And I sincerely hope to the gods that no cache-incoherent i915 mess ever makes it out of the x86 world. Incoherent IO was always a historical mistake and should never ever happen again, so we should not spread that horrific pattern around." Sure, but I was not talking about IO - just the CPU side access to CPU side objects. OK, I was under the impression that clflushes() and wbinvd()s in i915 was only ever used to make data visible to non-snooping GPUs. Do you mean that there are other uses as well? Agreed the wb cache flush on on suspend only if gpu is
[Intel-gfx] [PATCH 1/1] drm/i915: Handle the DG2 max bw properly
Separate the max bw call for DG2 as it has a constant bandwidth
regardless of the number of planes enabled.
cc: Ville Syrjälä
cc: Stanislav Lisovskiy
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_bw.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 395e48930b08..f1e1feb8db06 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -538,6 +538,13 @@ static unsigned int tgl_max_bw(struct drm_i915_private
*dev_priv,
return dev_priv->max_bw[0].deratedbw[qgv_point];
}
+static unsigned int dg2_max_bw(struct drm_i915_private *i915)
+{
+ struct intel_bw_info *bi = >max_bw[0];
+
+ return bi->deratedbw[0];
+}
+
static unsigned int adl_psf_bw(struct drm_i915_private *dev_priv,
int psf_gv_point)
{
@@ -931,7 +938,9 @@ int intel_bw_atomic_check(struct intel_atomic_state *state)
for (i = 0; i < num_qgv_points; i++) {
unsigned int max_data_rate;
- if (DISPLAY_VER(dev_priv) > 11)
+ if (IS_DG2(dev_priv))
+ max_data_rate = dg2_max_bw(dev_priv);
+ else if (DISPLAY_VER(dev_priv) > 11)
max_data_rate = tgl_max_bw(dev_priv, num_active_planes,
i);
else
max_data_rate = icl_max_bw(dev_priv, num_active_planes,
i);
--
2.25.1
[Intel-gfx] [PATCH 0/1] [PATCH 0/1] Handle the DG2 max bw properly
Provide accurate max bw data for DG2. cc: Ville Syrjälä cc: Stanislav Lisovskiy Vinod Govindapillai (1): drm/i915: Handle the DG2 max bw properly drivers/gpu/drm/i915/display/intel_bw.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) -- 2.25.1
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Fix up DP DFP 4:2:0 handling more (rev2)
== Series Details == Series: drm/i915: Fix up DP DFP 4:2:0 handling more (rev2) URL : https://patchwork.freedesktop.org/series/95881/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_disable' not found
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/ttm: Evict and restore of compressed object (rev4)
== Series Details ==
Series: drm/i915/ttm: Evict and restore of compressed object (rev4)
URL : https://patchwork.freedesktop.org/series/101106/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11396 -> Patchwork_22640
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22640 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22640, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/index.html
Participating hosts (48 -> 41)
--
Missing(7): shard-tglu fi-hsw-4200u bat-adlm-1 fi-bsw-cyan fi-ctg-p8600
fi-pnv-d510 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22640:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@migrate:
- fi-rkl-guc: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-rkl-guc/igt@i915_selftest@l...@migrate.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-rkl-guc/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@mman:
- bat-dg1-6: [PASS][3] -> [DMESG-FAIL][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-dg1-6/igt@i915_selftest@l...@mman.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/bat-dg1-6/igt@i915_selftest@l...@mman.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {fi-adl-ddr5}: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-adl-ddr5/igt@i915_selftest@l...@migrate.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-adl-ddr5/igt@i915_selftest@l...@migrate.html
- {fi-tgl-dsi}: [PASS][7] -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
- {bat-rpls-2}: [PASS][9] -> [DMESG-FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/bat-rpls-2/igt@i915_selftest@l...@migrate.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/bat-rpls-2/igt@i915_selftest@l...@migrate.html
Known issues
Here are the changes found in Patchwork_22640 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][11] -> [FAIL][12] ([i915#4054])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][13] -> [INCOMPLETE][14] ([i915#3303])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][15] -> [INCOMPLETE][16] ([i915#3921])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@memory_region:
- fi-cfl-8109u: [PASS][17] -> [DMESG-WARN][18] ([i915#203]) +28
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
* igt@i915_selftest@live@migrate:
- fi-tgl-1115g4: [PASS][19] -> [DMESG-FAIL][20] ([i915#1888])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11396/fi-tgl-1115g4/igt@i915_selftest@l...@migrate.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-tgl-1115g4/igt@i915_selftest@l...@migrate.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][21] ([fdo#109271] / [i915#1436] /
[i915#4312])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22640/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@objects:
- {bat-rpls-2}: [DMESG-WARN][22] ([i915#4391]) -> [PASS][23] +3
similar issues
[22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/rps: Centralize computation of freq caps
== Series Details ==
Series: drm/i915/rps: Centralize computation of freq caps
URL : https://patchwork.freedesktop.org/series/101606/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11395_full -> Patchwork_22633_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_22633_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_request_retire@retire-vma-not-inactive:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-rkl-2/igt@gem_request_ret...@retire-vma-not-inactive.html
Known issues
Here are the changes found in Patchwork_22633_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], [PASS][23], [PASS][24],
[PASS][25]) ([i915#4392]) -> ([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], [PASS][45], [PASS][46], [PASS][47],
[PASS][48], [PASS][49], [PASS][50])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk9/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk8/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk4/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk3/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11395/shard-glk1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk2/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk2/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk3/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk3/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk3/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk4/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk4/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk4/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk5/boot.html
[38]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22633/shard-glk5/boot.html
[39]:
