* [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
@ 2022-03-21 10:49 Stanislav Lisovskiy
2022-03-21 11:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2) Patchwork
` (5 more replies)
0 siblings, 6 replies; 28+ messages in thread
From: Stanislav Lisovskiy @ 2022-03-21 10:49 UTC (permalink / raw)
To: intel-gfx
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 <stanislav.lisovskiy@intel.com>
---
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 8888fda8b701..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(&dev_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(&dev_priv->drm,
"required cdclk (%d kHz) exceeds max (%d kHz)\n",
--
2.24.1.485.gad05a3d8e5
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2)
2022-03-21 10:49 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
@ 2022-03-21 11:10 ` Patchwork
2022-03-21 11:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
` (4 subsequent siblings)
5 siblings, 0 replies; 28+ messages in thread
From: Patchwork @ 2022-03-21 11:10 UTC (permalink / raw)
To: Stanislav Lisovskiy; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2)
URL : https://patchwork.freedesktop.org/series/101533/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5f2d79bd4ca6 drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
-:32: CHECK:LINE_SPACING: Please don't use multiple blank lines
#32: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:2328:
+
total: 0 errors, 0 warnings, 1 checks, 32 lines checked
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2)
2022-03-21 10:49 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
2022-03-21 11:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2) Patchwork
@ 2022-03-21 11:40 ` Patchwork
2022-03-21 14:39 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
` (3 subsequent siblings)
5 siblings, 0 replies; 28+ messages in thread
From: Patchwork @ 2022-03-21 11:40 UTC (permalink / raw)
To: Stanislav Lisovskiy; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 11006 bytes --]
== Series Details ==
Series: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2)
URL : https://patchwork.freedesktop.org/series/101533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11389 -> Patchwork_22625
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/index.html
Participating hosts (34 -> 40)
------------------------------
Additional (8): bat-dg1-6 bat-dg2-9 bat-adlp-6 fi-hsw-4770 fi-pnv-d510 bat-rpls-1 bat-jsl-2 bat-jsl-1
Missing (2): fi-bsw-cyan shard-tglu
Known issues
------------
Here are the changes found in Patchwork_22625 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770: NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-hsw-4770/igt@amdgpu/amd_basic@cs-gfx.html
* igt@fbdev@info:
- bat-dg1-6: NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@fbdev@info.html
* igt@gem_exec_gttfill@basic:
- bat-dg1-6: NOTRUN -> [SKIP][3] ([i915#4086])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@gem_exec_gttfill@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-hsw-4770: NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-hsw-4770/igt@gem_huc_copy@huc-copy.html
* igt@gem_mmap@basic:
- bat-dg1-6: NOTRUN -> [SKIP][5] ([i915#4083])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@gem_mmap@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@gem_tiled_blits@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#4079]) +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3012])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-hsw-4770/igt@i915_pm_backlight@basic-brightness.html
- bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#1155])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@i915_pm_backlight@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: NOTRUN -> [DMESG-FAIL][10] ([i915#4494] / [i915#4957])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@i915_selftest@live@hangcheck.html
- fi-snb-2600: [PASS][11] -> [INCOMPLETE][12] ([i915#3921])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
* igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#4212]) +7 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_addfb_basic@addfb25-x-tiled-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#4215])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_addfb_basic@basic-y-tiled-legacy.html
* igt@kms_busy@basic:
- bat-dg1-6: NOTRUN -> [SKIP][15] ([i915#4303])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_busy@basic.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +8 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-hsw-4770/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-edid-read:
- bat-dg1-6: NOTRUN -> [SKIP][17] ([fdo#111827]) +8 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_chamelium@hdmi-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-dg1-6: NOTRUN -> [SKIP][18] ([i915#4103] / [i915#4213]) +1 similar issue
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][19] ([i915#4078]) +23 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-6: NOTRUN -> [SKIP][20] ([fdo#109285])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_force_connector_basic@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#5341])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-pnv-d510/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c.html
- bat-dg1-6: NOTRUN -> [SKIP][22] ([i915#4078] / [i915#5341])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-hsw-4770: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#533])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-hsw-4770/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_mmap_gtt:
- fi-hsw-4770: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#1072]) +3 similar issues
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-hsw-4770/igt@kms_psr@primary_mmap_gtt.html
* igt@kms_psr@sprite_plane_onoff:
- bat-dg1-6: NOTRUN -> [SKIP][25] ([i915#1072] / [i915#4078]) +3 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-dg1-6: NOTRUN -> [SKIP][26] ([i915#3555])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@kms_setmode@basic-clone-single-crtc.html
* igt@prime_vgem@basic-gtt:
- bat-dg1-6: NOTRUN -> [SKIP][27] ([i915#3708] / [i915#4077]) +1 similar issue
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@prime_vgem@basic-gtt.html
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510: NOTRUN -> [SKIP][28] ([fdo#109271]) +57 similar issues
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/fi-pnv-d510/igt@prime_vgem@basic-userptr.html
- bat-dg1-6: NOTRUN -> [SKIP][29] ([i915#3708] / [i915#4873])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@prime_vgem@basic-userptr.html
* igt@prime_vgem@basic-write:
- bat-dg1-6: NOTRUN -> [SKIP][30] ([i915#3708]) +3 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/bat-dg1-6/igt@prime_vgem@basic-write.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#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3003]: https://gitlab.freedesktop.org/drm/intel/issues/3003
[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]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4086]: https://gitlab.freedesktop.org/drm/intel/issues/4086
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
[i915#4303]: https://gitlab.freedesktop.org/drm/intel/issues/4303
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5192]: https://gitlab.freedesktop.org/drm/intel/issues/5192
[i915#5193]: https://gitlab.freedesktop.org/drm/intel/issues/5193
[i915#5291]: https://gitlab.freedesktop.org/drm/intel/issues/5291
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
[i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
Build changes
-------------
* Linux: CI_DRM_11389 -> Patchwork_22625
CI-20190529: 20190529
CI_DRM_11389: 35a8bf3837850c0ecf945c58f5611bcc53c4a43f @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6386: 0fcd59ad25b2960c0b654f90dfe4dd9e7c7b874d @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22625: 5f2d79bd4ca621a65ee5b309e033930d999159b7 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5f2d79bd4ca6 drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/index.html
[-- Attachment #2: Type: text/html, Size: 12364 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2)
2022-03-21 10:49 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
2022-03-21 11:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2) Patchwork
2022-03-21 11:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2022-03-21 14:39 ` Patchwork
2022-03-21 16:58 ` [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Souza, Jose
` (2 subsequent siblings)
5 siblings, 0 replies; 28+ messages in thread
From: Patchwork @ 2022-03-21 14:39 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30284 bytes --]
== Series Details ==
Series: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2)
URL : https://patchwork.freedesktop.org/series/101533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11389_full -> Patchwork_22625_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_22625_full:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_color@pipe-c-legacy-gamma-reset:
- {shard-rkl}: ([SKIP][1], [SKIP][2]) ([i915#4070] / [i915#4098]) -> ([SKIP][3], [SKIP][4]) ([i915#4070])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_color@pipe-c-legacy-gamma-reset.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-1/igt@kms_color@pipe-c-legacy-gamma-reset.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-1/igt@kms_color@pipe-c-legacy-gamma-reset.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_color@pipe-c-legacy-gamma-reset.html
* igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen:
- {shard-rkl}: [PASS][5] -> ([SKIP][6], [SKIP][7]) ([fdo#112022] / [i915#4070])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-2/igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen.html
* igt@kms_cursor_crc@pipe-a-cursor-32x10-rapid-movement:
- {shard-rkl}: [SKIP][8] ([fdo#112022] / [i915#4070]) -> ([SKIP][9], [SKIP][10]) ([fdo#112022])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-1/igt@kms_cursor_crc@pipe-a-cursor-32x10-rapid-movement.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_cursor_crc@pipe-a-cursor-32x10-rapid-movement.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-5/igt@kms_cursor_crc@pipe-a-cursor-32x10-rapid-movement.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-rapid-movement:
- {shard-rkl}: [SKIP][11] ([fdo#112022]) -> [SKIP][12] +3 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_cursor_crc@pipe-a-cursor-64x64-rapid-movement.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_cursor_crc@pipe-a-cursor-64x64-rapid-movement.html
* igt@kms_cursor_crc@pipe-a-cursor-max-size-rapid-movement:
- {shard-rkl}: NOTRUN -> ([SKIP][13], [SKIP][14]) ([fdo#112022] / [i915#4070])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_cursor_crc@pipe-a-cursor-max-size-rapid-movement.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-1/igt@kms_cursor_crc@pipe-a-cursor-max-size-rapid-movement.html
* igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding:
- {shard-rkl}: ([SKIP][15], [SKIP][16]) ([fdo#112022]) -> ([SKIP][17], [SKIP][18]) ([fdo#112022] / [i915#4070]) +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-5/igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-1/igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding.html
* igt@kms_cursor_edge_walk@pipe-c-256x256-right-edge:
- {shard-rkl}: ([SKIP][19], [SKIP][20]) ([i915#4070] / [i915#4098]) -> [SKIP][21]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_cursor_edge_walk@pipe-c-256x256-right-edge.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-2/igt@kms_cursor_edge_walk@pipe-c-256x256-right-edge.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_cursor_edge_walk@pipe-c-256x256-right-edge.html
* igt@kms_cursor_edge_walk@pipe-c-64x64-left-edge:
- {shard-rkl}: NOTRUN -> ([SKIP][22], [SKIP][23]) ([i915#1849] / [i915#4098])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-5/igt@kms_cursor_edge_walk@pipe-c-64x64-left-edge.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_cursor_edge_walk@pipe-c-64x64-left-edge.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
- {shard-rkl}: NOTRUN -> [SKIP][24] +6 similar issues
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt:
- {shard-rkl}: [SKIP][25] ([i915#4098]) -> ([PASS][26], [SKIP][27]) +1 similar issue
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack-mmap-gtt:
- {shard-rkl}: ([SKIP][28], [SKIP][29]) ([i915#1849] / [i915#4098]) -> ([SKIP][30], [SKIP][31]) ([i915#1849]) +1 similar issue
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack-mmap-gtt.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-1/igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack-mmap-gtt.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack-mmap-gtt.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-1/igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-render:
- {shard-rkl}: [SKIP][32] ([i915#1849]) -> [SKIP][33] +3 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-2/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-render.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-gtt:
- {shard-rkl}: ([SKIP][34], [SKIP][35]) ([fdo#111825] / [i915#1825] / [i915#4098]) -> ([SKIP][36], [SKIP][37]) ([i915#1849])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-gtt.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-gtt.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-5/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-gtt.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt:
- {shard-rkl}: [SKIP][38] ([fdo#111825] / [i915#1825]) -> ([SKIP][39], [SKIP][40]) ([i915#1849])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-2/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-pwrite:
- {shard-rkl}: [SKIP][41] ([i915#4098]) -> [SKIP][42] +10 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-pwrite.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-pri-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite:
- {shard-rkl}: ([SKIP][43], [PASS][44]) ([i915#4098]) -> ([SKIP][45], [SKIP][46]) ([i915#1849])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-6/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-2/igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-pwrite.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-cur-indfb-draw-blt:
- {shard-rkl}: NOTRUN -> ([SKIP][47], [SKIP][48]) ([i915#1849]) +1 similar issue
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@psr-2p-primscrn-cur-indfb-draw-blt.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-5/igt@kms_frontbuffer_tracking@psr-2p-primscrn-cur-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-mmap-gtt:
- {shard-rkl}: [SKIP][49] ([i915#4098]) -> ([SKIP][50], [SKIP][51]) ([i915#1849]) +2 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-mmap-gtt.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-5/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-mmap-gtt.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-cpu:
- {shard-rkl}: [PASS][52] -> ([SKIP][53], [SKIP][54]) ([i915#1849])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-6/igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-cpu.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-2/igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-cpu.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- {shard-rkl}: [SKIP][55] ([i915#4098]) -> ([SKIP][56], [SKIP][57]) ([i915#1849] / [i915#4098])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-5/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- {shard-rkl}: ([SKIP][58], [SKIP][59]) ([i915#1849] / [i915#4070] / [i915#4098]) -> [SKIP][60]
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-2/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html
* igt@kms_properties@plane-properties-legacy:
- {shard-rkl}: ([SKIP][61], [SKIP][62]) ([i915#1849] / [i915#4098]) -> [SKIP][63] +1 similar issue
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-2/igt@kms_properties@plane-properties-legacy.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-rkl-4/igt@kms_properties@plane-properties-legacy.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-rkl-3/igt@kms_properties@plane-properties-legacy.html
Known issues
------------
Here are the changes found in Patchwork_22625_full that come from known issues:
### CI changes ###
#### Issues hit ####
* boot:
- shard-apl: ([PASS][64], [PASS][65], [PASS][66], [PASS][67], [PASS][68], [PASS][69], [PASS][70], [PASS][71], [PASS][72], [PASS][73], [PASS][74], [PASS][75], [PASS][76], [PASS][77], [PASS][78], [PASS][79], [PASS][80], [PASS][81], [PASS][82], [PASS][83], [PASS][84], [PASS][85], [PASS][86], [PASS][87], [PASS][88]) -> ([PASS][89], [PASS][90], [FAIL][91], [PASS][92], [PASS][93], [PASS][94], [PASS][95], [PASS][96], [PASS][97], [PASS][98], [PASS][99], [PASS][100], [PASS][101], [PASS][102], [PASS][103], [PASS][104], [PASS][105], [PASS][106], [PASS][107], [PASS][108], [PASS][109], [PASS][110], [PASS][111], [PASS][112], [PASS][113]) ([i915#4386])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl3/boot.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl3/boot.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl3/boot.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl3/boot.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl4/boot.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl4/boot.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl2/boot.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl4/boot.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl2/boot.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl2/boot.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl1/boot.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl1/boot.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl6/boot.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl6/boot.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl7/boot.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl7/boot.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl7/boot.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl8/boot.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl8/boot.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl1/boot.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl8/boot.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl1/boot.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl1/boot.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl1/boot.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl3/boot.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl2/boot.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl1/boot.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl1/boot.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl1/boot.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl1/boot.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl8/boot.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl8/boot.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl8/boot.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl7/boot.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl7/boot.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl7/boot.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl6/boot.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl6/boot.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl6/boot.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl6/boot.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl6/boot.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl4/boot.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl4/boot.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl4/boot.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl4/boot.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl3/boot.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl3/boot.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl3/boot.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl2/boot.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl2/boot.html
### IGT changes ###
#### Issues hit ####
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][114] -> [SKIP][115] ([i915#658])
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-iclb2/igt@feature_discovery@psr2.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb5/igt@feature_discovery@psr2.html
* igt@gem_exec_balancer@parallel-contexts:
- shard-kbl: NOTRUN -> [DMESG-WARN][116] ([i915#5076]) +1 similar issue
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-kbl1/igt@gem_exec_balancer@parallel-contexts.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-skl: NOTRUN -> [SKIP][117] ([fdo#109271]) +202 similar issues
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl8/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl: [PASS][118] -> [FAIL][119] ([i915#2842])
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-kbl4/igt@gem_exec_fair@basic-none-rrul@rcs0.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-kbl4/igt@gem_exec_fair@basic-none-rrul@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [PASS][120] -> [FAIL][121] ([i915#2842])
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl6/igt@gem_exec_fair@basic-none@vecs0.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl3/igt@gem_exec_fair@basic-none@vecs0.html
* igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][122] ([fdo#109283])
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-tglb6/igt@gem_exec_params@no-blt.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][123] -> [SKIP][124] ([i915#2190])
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-tglb5/igt@gem_huc_copy@huc-copy.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-tglb7/igt@gem_huc_copy@huc-copy.html
- shard-kbl: NOTRUN -> [SKIP][125] ([fdo#109271] / [i915#2190])
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-kbl3/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl: NOTRUN -> [SKIP][126] ([fdo#109271] / [i915#4613]) +2 similar issues
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl4/igt@gem_lmem_swapping@heavy-verify-random.html
* igt@gem_lmem_swapping@parallel-multi:
- shard-apl: NOTRUN -> [SKIP][127] ([fdo#109271] / [i915#4613]) +1 similar issue
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl7/igt@gem_lmem_swapping@parallel-multi.html
* igt@gem_lmem_swapping@random:
- shard-kbl: NOTRUN -> [SKIP][128] ([fdo#109271] / [i915#4613])
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-kbl1/igt@gem_lmem_swapping@random.html
* igt@gem_pwrite@basic-exhaustion:
- shard-skl: NOTRUN -> [WARN][129] ([i915#2658])
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl8/igt@gem_pwrite@basic-exhaustion.html
* igt@gem_softpin@allocator-evict-all-engines:
- shard-glk: [PASS][130] -> [FAIL][131] ([i915#4171])
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-glk7/igt@gem_softpin@allocator-evict-all-engines.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-glk9/igt@gem_softpin@allocator-evict-all-engines.html
* igt@gem_softpin@evict-snoop-interruptible:
- shard-iclb: NOTRUN -> [SKIP][132] ([fdo#109312])
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@gem_softpin@evict-snoop-interruptible.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-skl: NOTRUN -> [SKIP][133] ([fdo#109271] / [i915#3323])
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl8/igt@gem_userptr_blits@dmabuf-sync.html
* igt@gem_userptr_blits@input-checking:
- shard-skl: NOTRUN -> [DMESG-WARN][134] ([i915#4991])
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl9/igt@gem_userptr_blits@input-checking.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][135] -> [DMESG-WARN][136] ([i915#1436] / [i915#716])
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-apl8/igt@gen9_exec_parse@allowed-all.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl1/igt@gen9_exec_parse@allowed-all.html
- shard-glk: [PASS][137] -> [DMESG-WARN][138] ([i915#1436] / [i915#716])
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-glk8/igt@gen9_exec_parse@allowed-all.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-glk2/igt@gen9_exec_parse@allowed-all.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- shard-iclb: NOTRUN -> [SKIP][139] ([fdo#110892])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@i915_pm_rpm@modeset-non-lpsp-stress.html
* igt@i915_selftest@mock@requests:
- shard-skl: [PASS][140] -> [INCOMPLETE][141] ([i915#5183] / [i915#5187])
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-skl10/igt@i915_selftest@mock@requests.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl1/igt@i915_selftest@mock@requests.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip:
- shard-tglb: NOTRUN -> [SKIP][142] ([i915#5286])
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-tglb1/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
* igt@kms_big_fb@linear-8bpp-rotate-90:
- shard-iclb: NOTRUN -> [SKIP][143] ([fdo#110725] / [fdo#111614])
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@kms_big_fb@linear-8bpp-rotate-90.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-kbl: NOTRUN -> [SKIP][144] ([fdo#109271] / [i915#3777]) +1 similar issue
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-kbl1/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][145] ([i915#3743])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl10/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-skl: NOTRUN -> [SKIP][146] ([fdo#109271] / [i915#3777]) +5 similar issues
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl10/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][147] ([fdo#109271] / [i915#3777]) +1 similar issue
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl6/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][148] ([fdo#110723])
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@kms_big_fb@yf-tiled-64bpp-rotate-270.html
* igt@kms_big_joiner@2x-modeset:
- shard-tglb: NOTRUN -> [SKIP][149] ([i915#2705])
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-tglb1/igt@kms_big_joiner@2x-modeset.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs:
- shard-kbl: NOTRUN -> [SKIP][150] ([fdo#109271] / [i915#3886])
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-kbl1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][151] ([fdo#109271] / [i915#3886]) +7 similar issues
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl10/igt@kms_ccs@pipe-b-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][152] ([fdo#109271] / [i915#3886]) +7 similar issues
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl3/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-ccs-on-another-bo-yf_tiled_ccs:
- shard-iclb: NOTRUN -> [SKIP][153] ([fdo#109278]) +5 similar issues
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@kms_ccs@pipe-d-ccs-on-another-bo-yf_tiled_ccs.html
* igt@kms_chamelium@common-hpd-after-suspend:
- shard-iclb: NOTRUN -> [SKIP][154] ([fdo#109284] / [fdo#111827]) +1 similar issue
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_chamelium@vga-frame-dump:
- shard-skl: NOTRUN -> [SKIP][155] ([fdo#109271] / [fdo#111827]) +11 similar issues
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-skl8/igt@kms_chamelium@vga-frame-dump.html
* igt@kms_chamelium@vga-hpd:
- shard-apl: NOTRUN -> [SKIP][156] ([fdo#109271] / [fdo#111827]) +7 similar issues
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl3/igt@kms_chamelium@vga-hpd.html
* igt@kms_color_chamelium@pipe-a-ctm-blue-to-red:
- shard-kbl: NOTRUN -> [SKIP][157] ([fdo#109271] / [fdo#111827]) +4 similar issues
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-kbl1/igt@kms_color_chamelium@pipe-a-ctm-blue-to-red.html
* igt@kms_color_chamelium@pipe-b-ctm-max:
- shard-tglb: NOTRUN -> [SKIP][158] ([fdo#109284] / [fdo#111827])
[158]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-tglb6/igt@kms_color_chamelium@pipe-b-ctm-max.html
* igt@kms_color_chamelium@pipe-d-ctm-negative:
- shard-iclb: NOTRUN -> [SKIP][159] ([fdo#109278] / [fdo#109284] / [fdo#111827]) +1 similar issue
[159]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@kms_color_chamelium@pipe-d-ctm-negative.html
* igt@kms_content_protection@content_type_change:
- shard-tglb: NOTRUN -> [SKIP][160] ([i915#1063])
[160]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-tglb1/igt@kms_content_protection@content_type_change.html
* igt@kms_content_protection@srm:
- shard-apl: NOTRUN -> [TIMEOUT][161] ([i915#1319])
[161]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-apl3/igt@kms_content_protection@srm.html
* igt@kms_cursor_crc@pipe-a-cursor-512x170-sliding:
- shard-tglb: NOTRUN -> [SKIP][162] ([fdo#109279] / [i915#3359])
[162]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-tglb6/igt@kms_cursor_crc@pipe-a-cursor-512x170-sliding.html
* igt@kms_cursor_crc@pipe-a-cursor-512x512-offscreen:
- shard-iclb: NOTRUN -> [SKIP][163] ([fdo#109278] / [fdo#109279]) +1 similar issue
[163]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@kms_cursor_crc@pipe-a-cursor-512x512-offscreen.html
* igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-iclb: [PASS][164] -> [FAIL][165] ([i915#5072])
[164]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11389/shard-iclb2/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions.html
[165]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/shard-iclb7/igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl: [PASS][166] -> [FAIL][167] ([i915#79])
[166]: https://in
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22625/index.html
[-- Attachment #2: Type: text/html, Size: 32979 bytes --]
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-21 10:49 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
` (2 preceding siblings ...)
2022-03-21 14:39 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
@ 2022-03-21 16:58 ` Souza, Jose
2022-03-22 7:48 ` Lisovskiy, Stanislav
2022-03-21 17:01 ` Souza, Jose
2022-03-22 13:55 ` [Intel-gfx] " Mark Pearson
5 siblings, 1 reply; 28+ messages in thread
From: Souza, Jose @ 2022-03-21 16:58 UTC (permalink / raw)
To: Lisovskiy, Stanislav, intel-gfx
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 <stanislav.lisovskiy@intel.com>
> ---
> 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 8888fda8b701..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(&dev_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.
> + min_cdclk = DIV_ROUND_UP(min_cdclk * 115, 100);
> + break;
> + }
> + }
> + }
> +
> if (min_cdclk > dev_priv->max_cdclk_freq) {
> drm_dbg_kms(&dev_priv->drm,
> "required cdclk (%d kHz) exceeds max (%d kHz)\n",
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-21 10:49 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
` (3 preceding siblings ...)
2022-03-21 16:58 ` [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Souza, Jose
@ 2022-03-21 17:01 ` Souza, Jose
2022-03-22 7:49 ` Lisovskiy, Stanislav
2022-03-22 13:55 ` [Intel-gfx] " Mark Pearson
5 siblings, 1 reply; 28+ messages in thread
From: Souza, Jose @ 2022-03-21 17:01 UTC (permalink / raw)
To: Lisovskiy, Stanislav, intel-gfx
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 <stanislav.lisovskiy@intel.com>
> ---
> 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 8888fda8b701..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.
> + struct intel_encoder *encoder;
> +
> + for_each_intel_encoder_with_psr(&dev_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(&dev_priv->drm,
> "required cdclk (%d kHz) exceeds max (%d kHz)\n",
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-21 16:58 ` [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Souza, Jose
@ 2022-03-22 7:48 ` Lisovskiy, Stanislav
2022-03-22 13:16 ` Souza, Jose
0 siblings, 1 reply; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-22 7:48 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
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 <stanislav.lisovskiy@intel.com>
> > ---
> > 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 8888fda8b701..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(&dev_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.
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(&dev_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-21 17:01 ` Souza, Jose
@ 2022-03-22 7:49 ` Lisovskiy, Stanislav
2022-03-22 13:36 ` Souza, Jose
0 siblings, 1 reply; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-22 7:49 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
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 <stanislav.lisovskiy@intel.com>
> > ---
> > 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 8888fda8b701..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.
Stan
>
> > + struct intel_encoder *encoder;
> > +
> > + for_each_intel_encoder_with_psr(&dev_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(&dev_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 7:48 ` Lisovskiy, Stanislav
@ 2022-03-22 13:16 ` Souza, Jose
2022-03-22 13:30 ` Lisovskiy, Stanislav
0 siblings, 1 reply; 28+ messages in thread
From: Souza, Jose @ 2022-03-22 13:16 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
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 <stanislav.lisovskiy@intel.com>
> > > ---
> > > 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 8888fda8b701..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(&dev_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(&dev_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 13:16 ` Souza, Jose
@ 2022-03-22 13:30 ` Lisovskiy, Stanislav
2022-03-22 13:34 ` Souza, Jose
0 siblings, 1 reply; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-22 13:30 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
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 <stanislav.lisovskiy@intel.com>
> > > > ---
> > > > 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 8888fda8b701..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(&dev_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(&dev_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > >
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 13:30 ` Lisovskiy, Stanislav
@ 2022-03-22 13:34 ` Souza, Jose
0 siblings, 0 replies; 28+ messages in thread
From: Souza, Jose @ 2022-03-22 13:34 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
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 <stanislav.lisovskiy@intel.com>
> > > > > ---
> > > > > 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 8888fda8b701..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(&dev_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);
> > > > > + break;
> > > > > + }
> > > > > + }
> > > > > + }
> > > > > +
> > > > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > > > drm_dbg_kms(&dev_priv->drm,
> > > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > > >
> >
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 7:49 ` Lisovskiy, Stanislav
@ 2022-03-22 13:36 ` Souza, Jose
2022-03-29 13:10 ` Lisovskiy, Stanislav
0 siblings, 1 reply; 28+ messages in thread
From: Souza, Jose @ 2022-03-22 13:36 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
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 <stanislav.lisovskiy@intel.com>
> > > ---
> > > 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 8888fda8b701..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(&dev_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(&dev_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-21 10:49 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
` (4 preceding siblings ...)
2022-03-21 17:01 ` Souza, Jose
@ 2022-03-22 13:55 ` Mark Pearson
2022-03-22 14:18 ` Lisovskiy, Stanislav
5 siblings, 1 reply; 28+ messages in thread
From: Mark Pearson @ 2022-03-22 13:55 UTC (permalink / raw)
To: Stanislav Lisovskiy, intel-gfx
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 <stanislav.lisovskiy@intel.com>
> ---
> 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 8888fda8b701..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(&dev_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(&dev_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
Thanks
Mark
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 13:55 ` [Intel-gfx] " Mark Pearson
@ 2022-03-22 14:18 ` Lisovskiy, Stanislav
2022-03-22 14:23 ` [Intel-gfx] [External] " Mark Pearson
0 siblings, 1 reply; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-22 14:18 UTC (permalink / raw)
To: Mark Pearson; +Cc: intel-gfx
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 <stanislav.lisovskiy@intel.com>
> > ---
> > 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 8888fda8b701..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(&dev_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(&dev_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
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [External] Re: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 14:18 ` Lisovskiy, Stanislav
@ 2022-03-22 14:23 ` Mark Pearson
2022-03-23 15:47 ` Souza, Jose
0 siblings, 1 reply; 28+ messages in thread
From: Mark Pearson @ 2022-03-22 14:23 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
Thanks Stanislav,
On 3/22/22 10:18, Lisovskiy, Stanislav wrote:
> 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 <stanislav.lisovskiy@intel.com>
>>> ---
>>> 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 8888fda8b701..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(&dev_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(&dev_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.
>
Ah - OK, no FIFO underruns that I've noticed in the logs but I was
hoping the two were connected. I'll keep an eye out for those in the
meantime.
I guess I'll just wave a flag and say I'm seeing PSR2 related tearing
issues. If I disable PSR2 selective fetch it goes away
(i915.enable_psr2_sel_fetch=0) - but as that's a different issue to this
patch thread I don't want to drag the conversation too far sideways.
Thanks!
Mark
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [External] Re: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 14:23 ` [Intel-gfx] [External] " Mark Pearson
@ 2022-03-23 15:47 ` Souza, Jose
0 siblings, 0 replies; 28+ messages in thread
From: Souza, Jose @ 2022-03-23 15:47 UTC (permalink / raw)
To: Lisovskiy, Stanislav, markpearson; +Cc: intel-gfx
Hi Mark
See comment below.
On Tue, 2022-03-22 at 10:23 -0400, Mark Pearson wrote:
> Thanks Stanislav,
>
> On 3/22/22 10:18, Lisovskiy, Stanislav wrote:
> > 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 <stanislav.lisovskiy@intel.com>
> > > > ---
> > > > 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 8888fda8b701..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(&dev_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(&dev_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.
> >
> Ah - OK, no FIFO underruns that I've noticed in the logs but I was
> hoping the two were connected. I'll keep an eye out for those in the
> meantime.
>
> I guess I'll just wave a flag and say I'm seeing PSR2 related tearing
> issues. If I disable PSR2 selective fetch it goes away
> (i915.enable_psr2_sel_fetch=0) - but as that's a different issue to this
> patch thread I don't want to drag the conversation too far sideways.
Do you have a bug for your issue? But before you file it please search in our bug tracker if there is another similar issue.
With your description so far it looks like you are affected by this https://gitlab.freedesktop.org/drm/intel/-/issues/5077 .
It was already fixed in drm-tip but it will take a while to land on Linus master and the on distros kernel.
>
> Thanks!
> Mark
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-22 13:36 ` Souza, Jose
@ 2022-03-29 13:10 ` Lisovskiy, Stanislav
2022-03-29 13:24 ` Souza, Jose
0 siblings, 1 reply; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-29 13:10 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
On Tue, Mar 22, 2022 at 03:36:10PM +0200, Souza, Jose wrote:
> 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 <stanislav.lisovskiy@intel.com>
> > > > ---
> > > > 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 8888fda8b701..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.
Yes, did that. i915_display_info now reports only eDP connected. Modified intel_dp_detect to return disconnected state
for all non-eDP connectors, also modified hotplug and digport work routines to bail out for non PORT_A ports
just in case.
So even with eDP connected only FIFO underruns still happen, just ran kms_plane_multiple and it appeared immediately.
Stan
>
>
> >
> > Stan
> >
> > >
> > > > + struct intel_encoder *encoder;
> > > > +
> > > > + for_each_intel_encoder_with_psr(&dev_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(&dev_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > >
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-29 13:10 ` Lisovskiy, Stanislav
@ 2022-03-29 13:24 ` Souza, Jose
2022-03-29 13:53 ` Lisovskiy, Stanislav
0 siblings, 1 reply; 28+ messages in thread
From: Souza, Jose @ 2022-03-29 13:24 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
On Tue, 2022-03-29 at 16:10 +0300, Lisovskiy, Stanislav wrote:
> On Tue, Mar 22, 2022 at 03:36:10PM +0200, Souza, Jose wrote:
> > 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 <stanislav.lisovskiy@intel.com>
> > > > > ---
> > > > > 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 8888fda8b701..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.
>
> Yes, did that. i915_display_info now reports only eDP connected. Modified intel_dp_detect to return disconnected state
> for all non-eDP connectors, also modified hotplug and digport work routines to bail out for non PORT_A ports
> just in case.
> So even with eDP connected only FIFO underruns still happen, just ran kms_plane_multiple and it appeared immediately.
If that only happens with kms_plane_multiple with a particular number of planes or more please limit the workaround to this number of planes then.
Some folks from ChromeOS team already shown concern about the power impacts of this workaround.
Also this information might be helpful for HW folks to help identify the issue.
>
> Stan
>
> >
> >
> > >
> > > Stan
> > >
> > > >
> > > > > + struct intel_encoder *encoder;
> > > > > +
> > > > > + for_each_intel_encoder_with_psr(&dev_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(&dev_priv->drm,
> > > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > > >
> >
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-29 13:24 ` Souza, Jose
@ 2022-03-29 13:53 ` Lisovskiy, Stanislav
0 siblings, 0 replies; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-29 13:53 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
On Tue, Mar 29, 2022 at 04:24:30PM +0300, Souza, Jose wrote:
> On Tue, 2022-03-29 at 16:10 +0300, Lisovskiy, Stanislav wrote:
> > On Tue, Mar 22, 2022 at 03:36:10PM +0200, Souza, Jose wrote:
> > > 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 <stanislav.lisovskiy@intel.com>
> > > > > > ---
> > > > > > 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 8888fda8b701..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.
> >
> > Yes, did that. i915_display_info now reports only eDP connected. Modified intel_dp_detect to return disconnected state
> > for all non-eDP connectors, also modified hotplug and digport work routines to bail out for non PORT_A ports
> > just in case.
> > So even with eDP connected only FIFO underruns still happen, just ran kms_plane_multiple and it appeared immediately.
>
> If that only happens with kms_plane_multiple with a particular number of planes or more please limit the workaround to this number of planes then.
> Some folks from ChromeOS team already shown concern about the power impacts of this workaround.
>
> Also this information might be helpful for HW folks to help identify the issue.
It is not bound to amount of planes at all, I tried reducing N_PLANES to 1 even in that
test - with same result.
Regarding power consumption concerns, thats true, of course if we figure out some other
solution, without CDCLK increase, that one should be used then.
I'm now discussing the issue with HW team.
Otherwise we just need to decide, whats more important. I think frequent FIFO underruns
would be anyway more visible to the customer, than some energy consumption increase.
Stan
>
> >
> > Stan
> >
> > >
> > >
> > > >
> > > > Stan
> > > >
> > > > >
> > > > > > + struct intel_encoder *encoder;
> > > > > > +
> > > > > > + for_each_intel_encoder_with_psr(&dev_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(&dev_priv->drm,
> > > > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 14:38 ` Souza, Jose
@ 2022-03-18 14:45 ` Lisovskiy, Stanislav
0 siblings, 0 replies; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-18 14:45 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
On Fri, Mar 18, 2022 at 04:38:27PM +0200, Souza, Jose wrote:
> On Fri, 2022-03-18 at 16:19 +0200, Lisovskiy, Stanislav wrote:
> > On Fri, Mar 18, 2022 at 02:21:10PM +0200, Souza, Jose wrote:
> > > On Fri, 2022-03-18 at 10:52 +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.
> > >
> > > It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
> >
> > Nope, I hope we figure out some more elegant solution at some point.
>
> So please add this information to commit message and code comment.
Yes.
>
> >
> > >
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index 8888fda8b701..095b79950788 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> > > > dev_priv->max_cdclk_freq));
> > > > }
> > > >
> > >
> > > Please add some comment in the code about this workaround.
> > >
> > >
> > > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > > + struct intel_encoder *encoder;
> > > > +
> > > > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > +
> > > > + if (intel_dp->psr.psr2_enabled) {
> > >
> > > You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
> > >
> > > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> > >
> > > This is not increasing by 15%.
> > >
> > > min_cdclk = 500
> > > 500 * 100 = 50000
> > > 50000 / 85 = 588.235294118
> > >
> > > While 15% of 500 is 75.
> > >
> > > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> > >
> > > > + break;
> >
So 588 here is the number of which 500 constitutes 85 %, i.e those "88,.." are 15 % of 588,
but not of 500.
Not huge difference though, but needs to be fixed.
> > No, we won't bump up it twice, because we initialize min_cdclk here from pixel rate initially
> > and only then apply all those dirty hacks and optimizations. There is similar code above as
> > well.
> > For each crtc we call this function but as starting point always its pixel rate is used,
> > then the max() of those would be the actual new cdclk.
>
> It will if you are iterating with for_each_intel_encoder_with_psr() and there is more than one encoder with PSR2 enabled.
> Switching to crtc_state->has_psr2 and then increasing the min_cdclk of the pipe with PSR2 enabled, should fix it.
But we call "break" there, after we meet first encoder with psr2_enabled, we exit the for cycle.
Stan
>
> >
> > As for 15%, good point took this from expression above in that func, but indeed this is
> > no a 15%.
> >
> > Stan
> >
> > > > + }
> > > > + }
> > > > + }
> > > > +
> > > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > > drm_dbg_kms(&dev_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > >
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 14:22 ` Lisovskiy, Stanislav
@ 2022-03-18 14:40 ` Souza, Jose
0 siblings, 0 replies; 28+ messages in thread
From: Souza, Jose @ 2022-03-18 14:40 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
On Fri, 2022-03-18 at 16:22 +0200, Lisovskiy, Stanislav wrote:
> On Fri, Mar 18, 2022 at 02:27:53PM +0200, Souza, Jose wrote:
> > On Fri, 2022-03-18 at 05:22 -0700, José Roberto de Souza wrote:
> > > On Fri, 2022-03-18 at 10:52 +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.
> > >
> > > It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
> > >
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> > > > 1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index 8888fda8b701..095b79950788 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> > > > dev_priv->max_cdclk_freq));
> > > > }
> > > >
> > >
> > > Please add some comment in the code about this workaround.
> > >
> > >
> > > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > > + struct intel_encoder *encoder;
> > > > +
> > > > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > > +
> > > > + if (intel_dp->psr.psr2_enabled) {
> > >
> > > You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
> >
> > Ah and if a remember correctly those underruns only happens in a scenario with 4 pipes enabled? or it also happens with 2 and 3 pipes?
> > Anyways would be better to narrow down the cases where the workaround is applied.
> > So for at least in a case with a single pipe enabled we can have the lowest cdclk as possible.
>
> I was thinking the same initially, but this underrun is observed in lesser pipe cases, when PSR2
> is enabled.
Please check if at least the one pipe case really need this WA.
>
> Stan
>
> >
> > >
> > > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> > >
> > > This is not increasing by 15%.
> > >
> > > min_cdclk = 500
> > > 500 * 100 = 50000
> > > 50000 / 85 = 588.235294118
> > >
> > > While 15% of 500 is 75.
> > >
> > > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> > >
> > > > + break;
> > > > + }
> > > > + }
> > > > + }
> > > > +
> > > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > > drm_dbg_kms(&dev_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > >
> >
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 14:19 ` Lisovskiy, Stanislav
@ 2022-03-18 14:38 ` Souza, Jose
2022-03-18 14:45 ` Lisovskiy, Stanislav
0 siblings, 1 reply; 28+ messages in thread
From: Souza, Jose @ 2022-03-18 14:38 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
On Fri, 2022-03-18 at 16:19 +0200, Lisovskiy, Stanislav wrote:
> On Fri, Mar 18, 2022 at 02:21:10PM +0200, Souza, Jose wrote:
> > On Fri, 2022-03-18 at 10:52 +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.
> >
> > It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
>
> Nope, I hope we figure out some more elegant solution at some point.
So please add this information to commit message and code comment.
>
> >
> > >
> > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 8888fda8b701..095b79950788 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> > > dev_priv->max_cdclk_freq));
> > > }
> > >
> >
> > Please add some comment in the code about this workaround.
> >
> >
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + if (intel_dp->psr.psr2_enabled) {
> >
> > You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
> >
> > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> >
> > This is not increasing by 15%.
> >
> > min_cdclk = 500
> > 500 * 100 = 50000
> > 50000 / 85 = 588.235294118
> >
> > While 15% of 500 is 75.
> >
> > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> >
> > > + break;
>
> No, we won't bump up it twice, because we initialize min_cdclk here from pixel rate initially
> and only then apply all those dirty hacks and optimizations. There is similar code above as
> well.
> For each crtc we call this function but as starting point always its pixel rate is used,
> then the max() of those would be the actual new cdclk.
It will if you are iterating with for_each_intel_encoder_with_psr() and there is more than one encoder with PSR2 enabled.
Switching to crtc_state->has_psr2 and then increasing the min_cdclk of the pipe with PSR2 enabled, should fix it.
>
> As for 15%, good point took this from expression above in that func, but indeed this is
> no a 15%.
>
> Stan
>
> > > + }
> > > + }
> > > + }
> > > +
> > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > drm_dbg_kms(&dev_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 12:27 ` Souza, Jose
@ 2022-03-18 14:22 ` Lisovskiy, Stanislav
2022-03-18 14:40 ` Souza, Jose
0 siblings, 1 reply; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-18 14:22 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
On Fri, Mar 18, 2022 at 02:27:53PM +0200, Souza, Jose wrote:
> On Fri, 2022-03-18 at 05:22 -0700, José Roberto de Souza wrote:
> > On Fri, 2022-03-18 at 10:52 +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.
> >
> > It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
> >
> > >
> > > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 8888fda8b701..095b79950788 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> > > dev_priv->max_cdclk_freq));
> > > }
> > >
> >
> > Please add some comment in the code about this workaround.
> >
> >
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + if (intel_dp->psr.psr2_enabled) {
> >
> > You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
>
> Ah and if a remember correctly those underruns only happens in a scenario with 4 pipes enabled? or it also happens with 2 and 3 pipes?
> Anyways would be better to narrow down the cases where the workaround is applied.
> So for at least in a case with a single pipe enabled we can have the lowest cdclk as possible.
I was thinking the same initially, but this underrun is observed in lesser pipe cases, when PSR2
is enabled.
Stan
>
> >
> > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> >
> > This is not increasing by 15%.
> >
> > min_cdclk = 500
> > 500 * 100 = 50000
> > 50000 / 85 = 588.235294118
> >
> > While 15% of 500 is 75.
> >
> > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> >
> > > + break;
> > > + }
> > > + }
> > > + }
> > > +
> > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > drm_dbg_kms(&dev_priv->drm,
> > > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 12:21 ` Souza, Jose
2022-03-18 12:27 ` Souza, Jose
@ 2022-03-18 14:19 ` Lisovskiy, Stanislav
2022-03-18 14:38 ` Souza, Jose
1 sibling, 1 reply; 28+ messages in thread
From: Lisovskiy, Stanislav @ 2022-03-18 14:19 UTC (permalink / raw)
To: Souza, Jose; +Cc: intel-gfx
On Fri, Mar 18, 2022 at 02:21:10PM +0200, Souza, Jose wrote:
> On Fri, 2022-03-18 at 10:52 +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.
>
> It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
Nope, I hope we figure out some more elegant solution at some point.
>
> >
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 8888fda8b701..095b79950788 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> > dev_priv->max_cdclk_freq));
> > }
> >
>
> Please add some comment in the code about this workaround.
>
>
> > + if (IS_ALDERLAKE_P(dev_priv)) {
> > + struct intel_encoder *encoder;
> > +
> > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > + if (intel_dp->psr.psr2_enabled) {
>
> You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
>
> > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
>
> This is not increasing by 15%.
>
> min_cdclk = 500
> 500 * 100 = 50000
> 50000 / 85 = 588.235294118
>
> While 15% of 500 is 75.
>
> Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
>
> > + break;
No, we won't bump up it twice, because we initialize min_cdclk here from pixel rate initially
and only then apply all those dirty hacks and optimizations. There is similar code above as
well.
For each crtc we call this function but as starting point always its pixel rate is used,
then the max() of those would be the actual new cdclk.
As for 15%, good point took this from expression above in that func, but indeed this is
no a 15%.
Stan
> > + }
> > + }
> > + }
> > +
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > drm_dbg_kms(&dev_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 12:21 ` Souza, Jose
@ 2022-03-18 12:27 ` Souza, Jose
2022-03-18 14:22 ` Lisovskiy, Stanislav
2022-03-18 14:19 ` Lisovskiy, Stanislav
1 sibling, 1 reply; 28+ messages in thread
From: Souza, Jose @ 2022-03-18 12:27 UTC (permalink / raw)
To: Lisovskiy, Stanislav, intel-gfx
On Fri, 2022-03-18 at 05:22 -0700, José Roberto de Souza wrote:
> On Fri, 2022-03-18 at 10:52 +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.
>
> It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
>
> >
> > Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 8888fda8b701..095b79950788 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> > dev_priv->max_cdclk_freq));
> > }
> >
>
> Please add some comment in the code about this workaround.
>
>
> > + if (IS_ALDERLAKE_P(dev_priv)) {
> > + struct intel_encoder *encoder;
> > +
> > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > + if (intel_dp->psr.psr2_enabled) {
>
> You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
Ah and if a remember correctly those underruns only happens in a scenario with 4 pipes enabled? or it also happens with 2 and 3 pipes?
Anyways would be better to narrow down the cases where the workaround is applied.
So for at least in a case with a single pipe enabled we can have the lowest cdclk as possible.
>
> > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
>
> This is not increasing by 15%.
>
> min_cdclk = 500
> 500 * 100 = 50000
> 50000 / 85 = 588.235294118
>
> While 15% of 500 is 75.
>
> Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
>
> > + break;
> > + }
> > + }
> > + }
> > +
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > drm_dbg_kms(&dev_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 8:52 [Intel-gfx] [PATCH] " Stanislav Lisovskiy
@ 2022-03-18 12:21 ` Souza, Jose
2022-03-18 12:27 ` Souza, Jose
2022-03-18 14:19 ` Lisovskiy, Stanislav
0 siblings, 2 replies; 28+ messages in thread
From: Souza, Jose @ 2022-03-18 12:21 UTC (permalink / raw)
To: Lisovskiy, Stanislav, intel-gfx
On Fri, 2022-03-18 at 10:52 +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.
It this workaround meant to be permanent? If yes we should file a HSD and get hardware folks feedback.
>
> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 8888fda8b701..095b79950788 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> dev_priv->max_cdclk_freq));
> }
>
Please add some comment in the code about this workaround.
> + if (IS_ALDERLAKE_P(dev_priv)) {
> + struct intel_encoder *encoder;
> +
> + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (intel_dp->psr.psr2_enabled) {
You should check the has_psr2 in the crtc_state, PSR2 could be disabled when this state is committed.
> + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
This is not increasing by 15%.
min_cdclk = 500
500 * 100 = 50000
50000 / 85 = 588.235294118
While 15% of 500 is 75.
Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> + break;
> + }
> + }
> + }
> +
> if (min_cdclk > dev_priv->max_cdclk_freq) {
> drm_dbg_kms(&dev_priv->drm,
> "required cdclk (%d kHz) exceeds max (%d kHz)\n",
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
@ 2022-03-18 8:52 Stanislav Lisovskiy
2022-03-18 12:21 ` Souza, Jose
0 siblings, 1 reply; 28+ messages in thread
From: Stanislav Lisovskiy @ 2022-03-18 8:52 UTC (permalink / raw)
To: intel-gfx
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.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 8888fda8b701..095b79950788 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
dev_priv->max_cdclk_freq));
}
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ struct intel_encoder *encoder;
+
+ for_each_intel_encoder_with_psr(&dev_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 * 100, 85);
+ break;
+ }
+ }
+ }
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
drm_dbg_kms(&dev_priv->drm,
"required cdclk (%d kHz) exceeds max (%d kHz)\n",
--
2.24.1.485.gad05a3d8e5
^ permalink raw reply related [flat|nested] 28+ messages in thread
* [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-01-24 9:06 [Intel-gfx] [PATCH 4/4] drm/i915: Don't allocate extra ddb during async flip for DG2 Stanislav Lisovskiy
@ 2022-03-18 8:48 ` Stanislav Lisovskiy
0 siblings, 0 replies; 28+ messages in thread
From: Stanislav Lisovskiy @ 2022-03-18 8:48 UTC (permalink / raw)
To: intel-gfx
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.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 8888fda8b701..095b79950788 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
dev_priv->max_cdclk_freq));
}
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ struct intel_encoder *encoder;
+
+ for_each_intel_encoder_with_psr(&dev_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 * 100, 85);
+ break;
+ }
+ }
+ }
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
drm_dbg_kms(&dev_priv->drm,
"required cdclk (%d kHz) exceeds max (%d kHz)\n",
--
2.24.1.485.gad05a3d8e5
^ permalink raw reply related [flat|nested] 28+ messages in thread
end of thread, other threads:[~2022-03-29 13:53 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-21 10:49 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
2022-03-21 11:10 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used (rev2) Patchwork
2022-03-21 11:40 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-21 14:39 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-03-21 16:58 ` [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Souza, Jose
2022-03-22 7:48 ` Lisovskiy, Stanislav
2022-03-22 13:16 ` Souza, Jose
2022-03-22 13:30 ` Lisovskiy, Stanislav
2022-03-22 13:34 ` Souza, Jose
2022-03-21 17:01 ` Souza, Jose
2022-03-22 7:49 ` Lisovskiy, Stanislav
2022-03-22 13:36 ` Souza, Jose
2022-03-29 13:10 ` Lisovskiy, Stanislav
2022-03-29 13:24 ` Souza, Jose
2022-03-29 13:53 ` Lisovskiy, Stanislav
2022-03-22 13:55 ` [Intel-gfx] " Mark Pearson
2022-03-22 14:18 ` Lisovskiy, Stanislav
2022-03-22 14:23 ` [Intel-gfx] [External] " Mark Pearson
2022-03-23 15:47 ` Souza, Jose
-- strict thread matches above, loose matches on Subject: below --
2022-03-18 8:52 [Intel-gfx] [PATCH] " Stanislav Lisovskiy
2022-03-18 12:21 ` Souza, Jose
2022-03-18 12:27 ` Souza, Jose
2022-03-18 14:22 ` Lisovskiy, Stanislav
2022-03-18 14:40 ` Souza, Jose
2022-03-18 14:19 ` Lisovskiy, Stanislav
2022-03-18 14:38 ` Souza, Jose
2022-03-18 14:45 ` Lisovskiy, Stanislav
2022-01-24 9:06 [Intel-gfx] [PATCH 4/4] drm/i915: Don't allocate extra ddb during async flip for DG2 Stanislav Lisovskiy
2022-03-18 8:48 ` [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.