* [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 11:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
` (2 more replies)
0 siblings, 3 replies; 23+ 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] 23+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 8:52 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
@ 2022-03-18 11:18 ` Patchwork
2022-03-18 12:21 ` [Intel-gfx] [PATCH] " Souza, Jose
2022-03-18 12:30 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2022-03-18 11:18 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5163 bytes --]
== Series Details ==
Series: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
URL : https://patchwork.freedesktop.org/series/101533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11380 -> Patchwork_22612
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/index.html
Participating hosts (48 -> 45)
------------------------------
Additional (2): bat-jsl-2 fi-pnv-d510
Missing (5): shard-tglu fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22612:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@coherency:
- {bat-rpls-2}: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_selftest@live@coherency.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/bat-rpls-2/igt@i915_selftest@live@coherency.html
Known issues
------------
Here are the changes found in Patchwork_22612 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510: NOTRUN -> [SKIP][3] ([fdo#109271]) +57 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/fi-pnv-d510/igt@gem_huc_copy@huc-copy.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][4] -> [DMESG-FAIL][5] ([i915#4494] / [i915#4957])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg1-6/igt@i915_selftest@live@hangcheck.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/bat-dg1-6/igt@i915_selftest@live@hangcheck.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#5341])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/fi-pnv-d510/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c.html
#### Possible fixes ####
* igt@i915_selftest@live@objects:
- {bat-rpls-2}: [DMESG-WARN][7] ([i915#4391]) -> [PASS][8] +2 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_selftest@live@objects.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/bat-rpls-2/igt@i915_selftest@live@objects.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#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[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#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[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
[i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342
Build changes
-------------
* Linux: CI_DRM_11380 -> Patchwork_22612
CI-20190529: 20190529
CI_DRM_11380: fe83949cd4316608ea785fc376b6ed444224adad @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6385: f3df40281d93d5a63ee98fa30e90852d780673c9 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22612: fc7505c5f9a40dbbf242c8c37d63b972eddfbc46 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fc7505c5f9a4 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_22612/index.html
[-- Attachment #2: Type: text/html, Size: 4461 bytes --]
^ permalink raw reply [flat|nested] 23+ 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] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
2022-03-18 11:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
@ 2022-03-18 12:21 ` Souza, Jose
2022-03-18 12:27 ` Souza, Jose
2022-03-18 14:19 ` Lisovskiy, Stanislav
2022-03-18 12:30 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2 siblings, 2 replies; 23+ 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] 23+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 12:21 ` [Intel-gfx] [PATCH] " 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; 23+ 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] 23+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 8:52 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
2022-03-18 11:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-03-18 12:21 ` [Intel-gfx] [PATCH] " Souza, Jose
@ 2022-03-18 12:30 ` Patchwork
2 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2022-03-18 12:30 UTC (permalink / raw)
To: Lisovskiy, Stanislav; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 26446 bytes --]
== Series Details ==
Series: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
URL : https://patchwork.freedesktop.org/series/101533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11380_full -> Patchwork_22612_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Participating hosts (12 -> 10)
------------------------------
Missing (2): shard-rkl shard-tglu
Known issues
------------
Here are the changes found in Patchwork_22612_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][1] -> [TIMEOUT][2] ([i915#3063]) +2 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-tglb2/igt@gem_eio@in-flight-contexts-10ms.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-tglb6/igt@gem_eio@in-flight-contexts-10ms.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#2481] / [i915#3070])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb5/igt@gem_eio@unwedge-stress.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb4/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@gem_exec_balancer@parallel-balancer.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb7/igt@gem_exec_balancer@parallel-balancer.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-tglb2/igt@gem_exec_fair@basic-flow@rcs0.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-tglb5/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb1/igt@gem_exec_fair@basic-none@vcs1.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-glk1/igt@gem_exec_fair@basic-pace-share@rcs0.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-glk1/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar issue
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-kbl6/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-kbl1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
- shard-apl: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl8/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl6/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_params@no-vebox:
- shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271]) +107 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl4/igt@gem_exec_params@no-vebox.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [PASS][17] -> [FAIL][18] ([i915#644])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-glk9/igt@gem_ppgtt@flink-and-close-vma-leak.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-glk5/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gem_pxp@create-valid-protected-context:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#4270])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_pxp@create-valid-protected-context.html
* igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#768]) +1 similar issue
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled.html
* igt@gem_softpin@allocator-evict-all-engines:
- shard-glk: [PASS][21] -> [FAIL][22] ([i915#4171])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-glk1/igt@gem_softpin@allocator-evict-all-engines.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-glk5/igt@gem_softpin@allocator-evict-all-engines.html
* igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109290])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_userptr_blits@coherency-sync.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-iclb: NOTRUN -> [SKIP][24] ([i915#3323])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_userptr_blits@dmabuf-sync.html
- shard-skl: NOTRUN -> [SKIP][25] ([fdo#109271] / [i915#3323])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@gem_userptr_blits@dmabuf-sync.html
* igt@gen3_render_linear_blits:
- shard-tglb: NOTRUN -> [SKIP][26] ([fdo#109289])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-tglb8/igt@gen3_render_linear_blits.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-skl: NOTRUN -> [SKIP][27] ([fdo#109271] / [i915#658])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@i915_pm_dc@dc3co-vpb-simulation.html
- shard-iclb: NOTRUN -> [SKIP][28] ([i915#658])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@i915_pm_dc@dc3co-vpb-simulation.html
* igt@i915_pm_rpm@gem-execbuf-stress-pc8:
- shard-iclb: NOTRUN -> [SKIP][29] ([fdo#109293] / [fdo#109506])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@i915_pm_rpm@gem-execbuf-stress-pc8.html
* igt@i915_selftest@live@gt_pm:
- shard-skl: NOTRUN -> [DMESG-FAIL][30] ([i915#1886])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@i915_selftest@live@gt_pm.html
* igt@kms_big_fb@4-tiled-32bpp-rotate-90:
- shard-iclb: NOTRUN -> [SKIP][31] ([i915#5286]) +1 similar issue
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@kms_big_fb@4-tiled-32bpp-rotate-90.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- shard-skl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#3777])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip:
- shard-skl: NOTRUN -> [FAIL][33] ([i915#3743])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl4/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl: NOTRUN -> [SKIP][34] ([fdo#109271] / [i915#3777])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-skl: NOTRUN -> [SKIP][35] ([fdo#109271] / [i915#1888] / [i915#3886])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl9/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][36] ([fdo#109271] / [i915#3886])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_mc_ccs:
- shard-skl: NOTRUN -> [SKIP][37] ([fdo#109271] / [i915#3886]) +5 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl9/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_mc_ccs.html
* igt@kms_color_chamelium@pipe-b-ctm-0-75:
- shard-apl: NOTRUN -> [SKIP][38] ([fdo#109271] / [fdo#111827]) +1 similar issue
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@kms_color_chamelium@pipe-b-ctm-0-75.html
* igt@kms_color_chamelium@pipe-b-ctm-max:
- shard-skl: NOTRUN -> [SKIP][39] ([fdo#109271] / [fdo#111827]) +9 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@kms_color_chamelium@pipe-b-ctm-max.html
* igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement:
- shard-iclb: NOTRUN -> [SKIP][40] ([fdo#109278]) +4 similar issues
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@kms_cursor_crc@pipe-d-cursor-256x256-rapid-movement.html
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled:
- shard-skl: [PASS][41] -> [DMESG-WARN][42] ([i915#1982])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl4/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl9/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-apl: [PASS][43] -> [DMESG-WARN][44] ([i915#180]) +3 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl6/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl8/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip@flip-vs-suspend@c-dp1:
- shard-kbl: [PASS][45] -> [INCOMPLETE][46] ([i915#636])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-kbl7/igt@kms_flip@flip-vs-suspend@c-dp1.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-kbl3/igt@kms_flip@flip-vs-suspend@c-dp1.html
* igt@kms_flip@plain-flip-ts-check@a-edp1:
- shard-skl: [PASS][47] -> [FAIL][48] ([i915#2122])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl10/igt@kms_flip@plain-flip-ts-check@a-edp1.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl6/igt@kms_flip@plain-flip-ts-check@a-edp1.html
* igt@kms_force_connector_basic@prune-stale-modes:
- shard-apl: NOTRUN -> [SKIP][49] ([fdo#109271]) +25 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@kms_force_connector_basic@prune-stale-modes.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-shrfb-plflip-blt:
- shard-iclb: NOTRUN -> [SKIP][50] ([fdo#109280]) +2 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-shrfb-plflip-blt.html
* igt@kms_multipipe_modeset@basic-max-pipe-crc-check:
- shard-iclb: NOTRUN -> [SKIP][51] ([i915#1839])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@kms_multipipe_modeset@basic-max-pipe-crc-check.html
* igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence:
- shard-apl: NOTRUN -> [SKIP][52] ([fdo#109271] / [i915#533]) +1 similar issue
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-skl: NOTRUN -> [FAIL][53] ([fdo#108145] / [i915#265]) +2 similar issues
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-skl: NOTRUN -> [FAIL][54] ([i915#265])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][55] ([fdo#109271] / [i915#658])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area.html
* igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][56] -> [SKIP][57] ([fdo#109441]) +1 similar issue
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@kms_psr@psr2_sprite_plane_move.html
* igt@prime_vgem@basic-userptr:
- shard-iclb: NOTRUN -> [SKIP][58] ([i915#3301])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@prime_vgem@basic-userptr.html
* igt@syncobj_timeline@transfer-timeline-point:
- shard-iclb: NOTRUN -> [DMESG-FAIL][59] ([i915#5098])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@syncobj_timeline@transfer-timeline-point.html
- shard-skl: NOTRUN -> [DMESG-FAIL][60] ([i915#5098])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@syncobj_timeline@transfer-timeline-point.html
#### Possible fixes ####
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [FAIL][61] ([i915#2842]) -> [PASS][62] +2 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-kbl1/igt@gem_exec_fair@basic-none@vcs0.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-kbl6/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_workarounds@suspend-resume:
- shard-apl: [DMESG-WARN][63] ([i915#180]) -> [PASS][64] +2 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl3/igt@gem_workarounds@suspend-resume.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@gem_workarounds@suspend-resume.html
* igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled:
- shard-snb: [SKIP][65] ([fdo#109271]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-snb4/igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-snb7/igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled.html
* igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a1:
- shard-glk: [FAIL][67] ([i915#79]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-glk4/igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a1.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-glk7/igt@kms_flip@flip-vs-expired-vblank@c-hdmi-a1.html
* igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a:
- shard-skl: [FAIL][69] ([i915#1188]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl10/igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl6/igt@kms_hdr@bpc-switch-suspend@bpc-switch-suspend-edp-1-pipe-a.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][71] ([fdo#108145] / [i915#265]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl10/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale:
- shard-iclb: [SKIP][73] ([i915#5235]) -> [PASS][74] +2 similar issues
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb7/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-edp-1-planes-upscale-downscale.html
* igt@kms_psr2_su@frontbuffer-xrgb8888:
- shard-iclb: [SKIP][75] ([fdo#109642] / [fdo#111068] / [i915#658]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb3/igt@kms_psr2_su@frontbuffer-xrgb8888.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb2/igt@kms_psr2_su@frontbuffer-xrgb8888.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [SKIP][77] ([fdo#109441]) -> [PASS][78] +1 similar issue
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb7/igt@kms_psr@psr2_suspend.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb2/igt@kms_psr@psr2_suspend.html
* igt@kms_sequence@queue-busy:
- shard-skl: [FAIL][79] ([i915#2995]) -> [PASS][80]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl6/igt@kms_sequence@queue-busy.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl10/igt@kms_sequence@queue-busy.html
#### Warnings ####
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [SKIP][81] ([i915#4525]) -> [DMESG-WARN][82] ([i915#5076])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb5/igt@gem_exec_balancer@parallel-contexts.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb4/igt@gem_exec_balancer@parallel-contexts.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-iclb: [SKIP][83] ([i915#4525]) -> [DMESG-FAIL][84] ([i915#5076])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb3/igt@gem_exec_balancer@parallel-ordering.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb2/igt@gem_exec_balancer@parallel-ordering.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [DMESG-WARN][85] ([i915#5076]) -> [SKIP][86] ([i915#4525]) +1 similar issue
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@gem_exec_balancer@parallel-out-fence.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_exec_balancer@parallel-out-fence.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][87] ([i915#2684]) -> [WARN][88] ([i915#1804] / [i915#2684])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@i915_pm_rc6_residency@rc6-fence.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb7/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-iclb: [SKIP][89] ([i915#2920]) -> [SKIP][90] ([fdo#111068] / [i915#658])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area.html
* igt@runner@aborted:
- shard-apl: ([FAIL][91], [FAIL][92], [FAIL][93], [FAIL][94], [FAIL][95], [FAIL][96], [FAIL][97]) ([fdo#109271] / [i915#180] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][98], [FAIL][99], [FAIL][100], [FAIL][101], [FAIL][102], [FAIL][103], [FAIL][104]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#5257])
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl7/igt@runner@aborted.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl3/igt@runner@aborted.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl4/igt@runner@aborted.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl6/igt@runner@aborted.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl3/igt@runner@aborted.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl2/igt@runner@aborted.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl1/igt@runner@aborted.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl8/igt@runner@aborted.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl7/igt@runner@aborted.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl1/igt@runner@aborted.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl3/igt@runner@aborted.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl1/igt@runner@aborted.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl2/igt@runner@aborted.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl7/igt@runner@aborted.html
- shard-skl: ([FAIL][105], [FAIL][106], [FAIL][107], [FAIL][108], [FAIL][109]) ([i915#1814] / [i915#2029] / [i915#3002] / [i915#4312] / [i915#5257]) -> ([FAIL][110], [FAIL][111], [FAIL][112]) ([i915#3002] / [i915#4312] / [i915#5257])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl3/igt@runner@aborted.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl2/igt@runner@aborted.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl8/igt@runner@aborted.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl10/igt@runner@aborted.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl10/igt@runner@aborted.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl4/igt@runner@aborted.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl8/igt@runner@aborted.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl10/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109290]: https://bugs.freedesktop.org/show_bug.cgi?id=109290
[fdo#109293]: https://bugs.freedesktop.org/show_bug.cgi?id=109293
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109506]: https://bugs.freedesktop.org/show_bug.cgi?id=109506
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1804]: https://gitlab.freedesktop.org/drm/intel/issues/1804
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2481]: https://gitlab.freedesktop.org/drm/intel/issues/2481
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#2684]: https://gitlab.freedesktop.org/drm/intel/issues/2684
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
[i915#2995]: https://gitlab.freedesktop.org/drm/intel/issues/2995
[i915#3002]: https://gitlab.freedesktop.org/drm/intel/issues/3002
[i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063
[i915#3070]: https://gitlab.freedesktop.org/drm/intel/issues/3070
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3323]: https://gitlab.freedesktop.org/drm/intel/issues/3323
[i915#3743]: https://gitlab.freedesktop.org/drm/intel/issues/3743
[i915#3777]: https://gitlab.freedesktop.org/drm/intel/issues/3777
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#4171]: https://gitlab.freedesktop.org/drm/intel/issues/4171
[i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4525]: https://gitlab.freedesktop.org/drm/intel/issues/4525
[i915#5076]: https://gitlab.freedesktop.org/drm/intel/issues/5076
[i915#5098]: https://gitlab.freedesktop.org/drm/intel/issues/5098
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#636]: https://gitlab.freedesktop.org/drm/intel/issues/636
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#768]: https://gitlab.freedesktop.org/drm/intel/issues/768
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
Build changes
-------------
* Linux: CI_DRM_11380 -> Patchwork_22612
CI-20190529: 20190529
CI_DRM_11380: fe83949cd4316608ea785fc376b6ed444224adad @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6385: f3df40281d93d5a63ee98fa30e90852d780673c9 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22612: fc7505c5f9a40dbbf242c8c37d63b972eddfbc46 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/index.html
[-- Attachment #2: Type: text/html, Size: 32395 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-18 12:21 ` [Intel-gfx] [PATCH] " 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
2022-03-21 16:58 ` Souza, Jose
@ 2022-03-22 7:48 ` Lisovskiy, Stanislav
2022-03-22 13:16 ` Souza, Jose
0 siblings, 1 reply; 23+ 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] 23+ 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] " Stanislav Lisovskiy
2022-03-21 16:58 ` Souza, Jose
@ 2022-03-21 17:01 ` Souza, Jose
2022-03-22 7:49 ` Lisovskiy, Stanislav
1 sibling, 1 reply; 23+ 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] 23+ 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] " Stanislav Lisovskiy
@ 2022-03-21 16:58 ` Souza, Jose
2022-03-22 7:48 ` Lisovskiy, Stanislav
2022-03-21 17:01 ` Souza, Jose
1 sibling, 1 reply; 23+ 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] 23+ messages in thread
* [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 16:58 ` Souza, Jose
2022-03-21 17:01 ` Souza, Jose
0 siblings, 2 replies; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread
end of thread, other threads:[~2022-03-29 13:53 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-18 8:52 [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used Stanislav Lisovskiy
2022-03-18 11:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-03-18 12:21 ` [Intel-gfx] [PATCH] " 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-03-18 12:30 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2022-03-21 10:49 [Intel-gfx] [PATCH] " Stanislav Lisovskiy
2022-03-21 16:58 ` 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-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.