* [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
@ 2019-12-31 14:00 Kai Vehmanen
2019-12-31 14:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2) Patchwork
` (5 more replies)
0 siblings, 6 replies; 23+ messages in thread
From: Kai Vehmanen @ 2019-12-31 14:00 UTC (permalink / raw)
To: intel-gfx
Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
communicate with i915 over HDA bus multiple times during system
boot-up and each of these transactions result in matching
get_power/put_power calls to i915, and depending on the platform,
a modeset change causing visible flicker.
GLK is the only platform with minimum CDCLK significantly lower
than BCLK, and thus for GLK setting a higher CDCLK is mandatory.
For other platforms, minimum CDCLK is close but below 2*BCLK
(e.g. on ICL, CDCLK=176.4kHz with BCLK=96kHz). Spec-wise the constraint
should be set, but in practise no communication errors have been
reported and the downside if set is the flicker observed at boot-time.
Revert to old behaviour until better mechanism to manage
probe-time clocks is available.
The full CDCLK>=2*BCLK constraint is still enforced at pipe
enable time in intel_crtc_compute_min_cdclk().
Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/913
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
---
Notes:
v2: d'oh, change put_power() as well
drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c b/drivers/gpu/drm/i915/display/intel_audio.c
index 27710098d056..e406719a6716 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -856,7 +856,7 @@ static unsigned long i915_audio_component_get_power(struct device *kdev)
}
/* Force CDCLK to 2*BCLK as long as we need audio powered. */
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ if (IS_GEMINILAKE(dev_priv))
glk_force_audio_cdclk(dev_priv, true);
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
@@ -875,7 +875,7 @@ static void i915_audio_component_put_power(struct device *kdev,
/* Stop forcing CDCLK to 2*BCLK if no need for audio to be powered. */
if (--dev_priv->audio_power_refcount == 0)
- if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
+ if (IS_GEMINILAKE(dev_priv))
glk_force_audio_cdclk(dev_priv, false);
intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO, cookie);
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2)
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
@ 2019-12-31 14:38 ` Patchwork
2019-12-31 20:06 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
` (4 subsequent siblings)
5 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2019-12-31 14:38 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2)
URL : https://patchwork.freedesktop.org/series/71525/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7657 -> Patchwork_15954
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/index.html
Known issues
------------
Here are the changes found in Patchwork_15954 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s3:
- fi-icl-u2: [PASS][1] -> [FAIL][2] ([fdo#103375])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-icl-u2/igt@gem_exec_suspend@basic-s3.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-icl-u2/igt@gem_exec_suspend@basic-s3.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u2: [PASS][3] -> [FAIL][4] ([fdo#111550])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-icl-u2/igt@gem_exec_suspend@basic-s4-devices.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-icl-u2/igt@gem_exec_suspend@basic-s4-devices.html
* igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6770hq: [PASS][5] -> [INCOMPLETE][6] ([i915#671])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-skl-6770hq/igt@i915_module_load@reload-with-fault-injection.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-skl-6770hq/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-lmem: [PASS][7] -> [DMESG-WARN][8] ([i915#592])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-skl-lmem/igt@i915_pm_rpm@module-reload.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-skl-lmem/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [PASS][9] -> [DMESG-FAIL][10] ([i915#725])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-hsw-4770r/igt@i915_selftest@live_blt.html
- fi-bsw-n3050: [PASS][11] -> [DMESG-FAIL][12] ([i915#723])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-bsw-n3050/igt@i915_selftest@live_blt.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-bsw-n3050/igt@i915_selftest@live_blt.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][13] -> [FAIL][14] ([fdo#109635] / [i915#217])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][15] -> [FAIL][16] ([fdo#111096] / [i915#323])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-y: [INCOMPLETE][17] ([fdo#111736] / [i915#460]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-tgl-y/igt@gem_exec_suspend@basic-s3.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-tgl-y/igt@gem_exec_suspend@basic-s3.html
* igt@kms_busy@basic-flip-pipe-a:
- fi-icl-u2: [INCOMPLETE][19] ([i915#140]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-icl-u2/igt@kms_busy@basic-flip-pipe-a.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-icl-u2/igt@kms_busy@basic-flip-pipe-a.html
#### Warnings ####
* igt@i915_selftest@live_blt:
- fi-ivb-3770: [DMESG-FAIL][21] ([i915#725]) -> [DMESG-FAIL][22] ([i915#770])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-ivb-3770/igt@i915_selftest@live_blt.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-ivb-3770/igt@i915_selftest@live_blt.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][24] ([i915#62] / [i915#92]) +5 similar issues
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-kbl-x1275/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-kbl-x1275/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-modeset:
- fi-kbl-x1275: [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95]) +6 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-modeset.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-modeset.html
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111550]: https://bugs.freedesktop.org/show_bug.cgi?id=111550
[fdo#111736]: https://bugs.freedesktop.org/show_bug.cgi?id=111736
[i915#140]: https://gitlab.freedesktop.org/drm/intel/issues/140
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
[i915#460]: https://gitlab.freedesktop.org/drm/intel/issues/460
[i915#592]: https://gitlab.freedesktop.org/drm/intel/issues/592
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#671]: https://gitlab.freedesktop.org/drm/intel/issues/671
[i915#723]: https://gitlab.freedesktop.org/drm/intel/issues/723
[i915#725]: https://gitlab.freedesktop.org/drm/intel/issues/725
[i915#770]: https://gitlab.freedesktop.org/drm/intel/issues/770
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (46 -> 38)
------------------------------
Additional (5): fi-tgl-u fi-hsw-peppy fi-glk-dsi fi-snb-2520m fi-blb-e6850
Missing (13): fi-bdw-5557u fi-hsw-4200u fi-skl-guc fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-cfl-guc fi-byt-clapper fi-whl-u fi-bdw-samus fi-snb-2600 fi-skl-6600u fi-kbl-r
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7657 -> Patchwork_15954
CI-20190529: 20190529
CI_DRM_7657: 265f77c05e67b37169ac1a9d750a2e2936928ea0 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5355: 2ead76177f2546d3eec0abbd0d9e47cd36588199 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15954: ed3398d25f0f23742e9d396c5f9e513010e6b1cb @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ed3398d25f0f drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2)
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
2019-12-31 14:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2) Patchwork
@ 2019-12-31 20:06 ` Patchwork
2020-01-02 18:28 ` [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Rodrigo Vivi
` (3 subsequent siblings)
5 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2019-12-31 20:06 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2)
URL : https://patchwork.freedesktop.org/series/71525/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7657_full -> Patchwork_15954_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_15954_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15954_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_15954_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_schedule@preempt-queue-contexts-vebox:
- shard-iclb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb4/igt@gem_exec_schedule@preempt-queue-contexts-vebox.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb8/igt@gem_exec_schedule@preempt-queue-contexts-vebox.html
Known issues
------------
Here are the changes found in Patchwork_15954_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +2 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-kbl6/igt@gem_ctx_isolation@rcs0-s3.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-kbl7/igt@gem_ctx_isolation@rcs0-s3.html
* igt@gem_ctx_persistence@vcs1-mixed-process:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276] / [fdo#112080]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb2/igt@gem_ctx_persistence@vcs1-mixed-process.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb7/igt@gem_ctx_persistence@vcs1-mixed-process.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110841])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb2/igt@gem_ctx_shared@exec-single-timeline-bsd.html
* igt@gem_eio@kms:
- shard-glk: [PASS][9] -> [INCOMPLETE][10] ([i915#58] / [k.org#198133])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-glk8/igt@gem_eio@kms.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-glk3/igt@gem_eio@kms.html
- shard-tglb: [PASS][11] -> [INCOMPLETE][12] ([i915#476])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb7/igt@gem_eio@kms.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb2/igt@gem_eio@kms.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#110854])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb2/igt@gem_exec_balancer@smoke.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb7/igt@gem_exec_balancer@smoke.html
* igt@gem_exec_reloc@basic-active:
- shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#472])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb6/igt@gem_exec_reloc@basic-active.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb8/igt@gem_exec_reloc@basic-active.html
* igt@gem_exec_reloc@basic-gtt-read-active:
- shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#109]) +1 similar issue
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl5/igt@gem_exec_reloc@basic-gtt-read-active.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl3/igt@gem_exec_reloc@basic-gtt-read-active.html
* igt@gem_exec_reuse@single:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#435])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb1/igt@gem_exec_reuse@single.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb6/igt@gem_exec_reuse@single.html
* igt@gem_exec_schedule@preempt-queue-contexts-chain-vebox:
- shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([fdo#111606] / [fdo#111677])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb3/igt@gem_exec_schedule@preempt-queue-contexts-chain-vebox.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb8/igt@gem_exec_schedule@preempt-queue-contexts-chain-vebox.html
* igt@gem_exec_schedule@preempt-queue-vebox:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([fdo#111677])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb5/igt@gem_exec_schedule@preempt-queue-vebox.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb5/igt@gem_exec_schedule@preempt-queue-vebox.html
* igt@gem_exec_schedule@promotion-bsd1:
- shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109276]) +20 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb1/igt@gem_exec_schedule@promotion-bsd1.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb6/igt@gem_exec_schedule@promotion-bsd1.html
* igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][27] -> [SKIP][28] ([fdo#112146]) +8 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb5/igt@gem_exec_schedule@reorder-wide-bsd.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb2/igt@gem_exec_schedule@reorder-wide-bsd.html
* igt@gem_exec_schedule@smoketest-blt:
- shard-tglb: [PASS][29] -> [INCOMPLETE][30] ([i915#470])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb8/igt@gem_exec_schedule@smoketest-blt.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb3/igt@gem_exec_schedule@smoketest-blt.html
* igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-tglb: [PASS][31] -> [FAIL][32] ([i915#520])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb4/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb2/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
* igt@gem_softpin@noreloc-s3:
- shard-skl: [PASS][33] -> [INCOMPLETE][34] ([i915#69])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl1/igt@gem_softpin@noreloc-s3.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl10/igt@gem_softpin@noreloc-s3.html
* igt@gem_sync@basic-all:
- shard-tglb: [PASS][35] -> [INCOMPLETE][36] ([i915#470] / [i915#472])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb2/igt@gem_sync@basic-all.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb8/igt@gem_sync@basic-all.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][37] -> [FAIL][38] ([i915#454])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb6/igt@i915_pm_dc@dc6-psr.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl: [PASS][39] -> [DMESG-WARN][40] ([i915#180]) +1 similar issue
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-apl8/igt@i915_suspend@fence-restore-tiled2untiled.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-apl1/igt@i915_suspend@fence-restore-tiled2untiled.html
* igt@kms_cursor_crc@pipe-b-cursor-128x42-onscreen:
- shard-skl: [PASS][41] -> [FAIL][42] ([i915#54]) +1 similar issue
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl3/igt@kms_cursor_crc@pipe-b-cursor-128x42-onscreen.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl6/igt@kms_cursor_crc@pipe-b-cursor-128x42-onscreen.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][43] -> [INCOMPLETE][44] ([i915#300])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: [PASS][45] -> [FAIL][46] ([i915#79])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-glk3/igt@kms_flip@2x-flip-vs-expired-vblank.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-apl: [PASS][47] -> [FAIL][48] ([i915#46])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-apl2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-apl8/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite:
- shard-tglb: [PASS][49] -> [FAIL][50] ([i915#49])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb9/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][51] -> [FAIL][52] ([fdo#108145] / [i915#265])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl6/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl5/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][53] -> [SKIP][54] ([fdo#109642] / [fdo#111068]) +1 similar issue
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb2/igt@kms_psr2_su@frontbuffer.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb8/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][55] -> [SKIP][56] ([fdo#109441]) +1 similar issue
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb7/igt@kms_psr@psr2_primary_page_flip.html
* igt@perf@disabled-read-error:
- shard-iclb: [PASS][57] -> [DMESG-WARN][58] ([i915#645])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb4/igt@perf@disabled-read-error.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb8/igt@perf@disabled-read-error.html
* igt@perf_pmu@busy-vcs1:
- shard-iclb: [PASS][59] -> [SKIP][60] ([fdo#112080]) +12 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb2/igt@perf_pmu@busy-vcs1.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb7/igt@perf_pmu@busy-vcs1.html
#### Possible fixes ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [SKIP][61] ([fdo#112080]) -> [PASS][62] +10 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb5/igt@gem_busy@busy-vcs1.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb1/igt@gem_busy@busy-vcs1.html
* igt@gem_ctx_isolation@vcs1-none:
- shard-iclb: [SKIP][63] ([fdo#109276] / [fdo#112080]) -> [PASS][64] +4 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb5/igt@gem_ctx_isolation@vcs1-none.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb2/igt@gem_ctx_isolation@vcs1-none.html
* igt@gem_ctx_persistence@vcs0-mixed-process:
- shard-skl: [FAIL][65] ([i915#679]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl5/igt@gem_ctx_persistence@vcs0-mixed-process.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl8/igt@gem_ctx_persistence@vcs0-mixed-process.html
* igt@gem_exec_await@wide-contexts:
- shard-tglb: [INCOMPLETE][67] ([fdo#111736]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb5/igt@gem_exec_await@wide-contexts.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb8/igt@gem_exec_await@wide-contexts.html
* igt@gem_exec_parallel@basic:
- shard-tglb: [INCOMPLETE][69] ([i915#476]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb9/igt@gem_exec_parallel@basic.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb1/igt@gem_exec_parallel@basic.html
* {igt@gem_exec_schedule@pi-common-bsd}:
- shard-iclb: [SKIP][71] ([i915#677]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb2/igt@gem_exec_schedule@pi-common-bsd.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb7/igt@gem_exec_schedule@pi-common-bsd.html
* igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-tglb: [INCOMPLETE][73] ([fdo#111677]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb5/igt@gem_exec_schedule@preempt-queue-bsd1.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb8/igt@gem_exec_schedule@preempt-queue-bsd1.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [SKIP][75] ([fdo#112146]) -> [PASS][76] +5 similar issues
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb8/igt@gem_exec_schedule@preemptive-hang-bsd.html
* igt@gem_exec_schedule@smoketest-vebox:
- shard-tglb: [INCOMPLETE][77] ([i915#707]) -> [PASS][78]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb9/igt@gem_exec_schedule@smoketest-vebox.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb1/igt@gem_exec_schedule@smoketest-vebox.html
* igt@gem_persistent_relocs@forked-faulting-reloc-thrashing:
- shard-iclb: [TIMEOUT][79] ([i915#530]) -> [PASS][80]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb5/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb2/igt@gem_persistent_relocs@forked-faulting-reloc-thrashing.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [DMESG-WARN][81] ([i915#180]) -> [PASS][82] +2 similar issues
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-apl3/igt@gem_softpin@noreloc-s3.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-apl6/igt@gem_softpin@noreloc-s3.html
* {igt@gen9_exec_parse@allowed-all}:
- shard-kbl: [DMESG-WARN][83] ([i915#716]) -> [PASS][84]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-kbl3/igt@gen9_exec_parse@allowed-all.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-kbl1/igt@gen9_exec_parse@allowed-all.html
* igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [FAIL][85] ([i915#447]) -> [PASS][86]
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb3/igt@i915_pm_dc@dc5-dpms.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb6/igt@i915_pm_dc@dc5-dpms.html
* igt@i915_pm_rps@waitboost:
- shard-iclb: [FAIL][87] ([i915#413]) -> [PASS][88]
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb6/igt@i915_pm_rps@waitboost.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb4/igt@i915_pm_rps@waitboost.html
* igt@kms_color@pipe-a-ctm-0-75:
- shard-skl: [DMESG-WARN][89] ([i915#109]) -> [PASS][90] +2 similar issues
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl4/igt@kms_color@pipe-a-ctm-0-75.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl7/igt@kms_color@pipe-a-ctm-0-75.html
* igt@kms_cursor_crc@pipe-c-cursor-128x128-sliding:
- shard-glk: [FAIL][91] ([i915#54]) -> [PASS][92]
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-glk6/igt@kms_cursor_crc@pipe-c-cursor-128x128-sliding.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-glk9/igt@kms_cursor_crc@pipe-c-cursor-128x128-sliding.html
* igt@kms_draw_crc@draw-method-xrgb8888-mmap-gtt-xtiled:
- shard-snb: [SKIP][93] ([fdo#109271]) -> [PASS][94] +3 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-snb2/igt@kms_draw_crc@draw-method-xrgb8888-mmap-gtt-xtiled.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-snb5/igt@kms_draw_crc@draw-method-xrgb8888-mmap-gtt-xtiled.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk: [FAIL][95] ([i915#46]) -> [PASS][96]
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-glk1/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
- shard-tglb: [FAIL][97] ([i915#49]) -> [PASS][98] +1 similar issue
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb5/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb2/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [DMESG-WARN][99] ([i915#180]) -> [PASS][100] +5 similar issues
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-kbl7/igt@kms_frontbuffer_tracking@fbc-suspend.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-skl: [DMESG-WARN][101] ([IGT#6]) -> [PASS][102]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl5/igt@kms_plane_multiple@atomic-pipe-c-tiling-y.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl3/igt@kms_plane_multiple@atomic-pipe-c-tiling-y.html
* igt@kms_psr@psr2_sprite_mmap_gtt:
- shard-iclb: [SKIP][103] ([fdo#109441]) -> [PASS][104] +5 similar issues
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_gtt.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][105] ([i915#31]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-apl8/igt@kms_setmode@basic.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-apl1/igt@kms_setmode@basic.html
- shard-skl: [FAIL][107] ([i915#31]) -> [PASS][108]
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl1/igt@kms_setmode@basic.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl2/igt@kms_setmode@basic.html
- shard-glk: [FAIL][109] ([i915#31]) -> [PASS][110]
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-glk3/igt@kms_setmode@basic.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-glk5/igt@kms_setmode@basic.html
* igt@perf@oa-exponents:
- shard-glk: [FAIL][111] ([i915#84]) -> [PASS][112]
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-glk8/igt@perf@oa-exponents.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-glk5/igt@perf@oa-exponents.html
* igt@perf_pmu@enable-race-vcs1:
- shard-tglb: [INCOMPLETE][113] ([i915#435]) -> [PASS][114] +1 similar issue
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-tglb5/igt@perf_pmu@enable-race-vcs1.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-tglb8/igt@perf_pmu@enable-race-vcs1.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [SKIP][115] ([fdo#109276]) -> [PASS][116] +19 similar issues
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb5/igt@prime_busy@hang-bsd2.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb2/igt@prime_busy@hang-bsd2.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [FAIL][117] ([IGT#28]) -> [SKIP][118] ([fdo#109276] / [fdo#112080]) +1 similar issue
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-iclb3/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@i915_suspend@debugfs-reader:
- shard-kbl: [INCOMPLETE][119] ([fdo#103665]) -> [DMESG-WARN][120] ([i915#180])
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-kbl4/igt@i915_suspend@debugfs-reader.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-kbl7/igt@i915_suspend@debugfs-reader.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [FAIL][121] ([i915#46]) -> [FAIL][122] ([i915#79])
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7657/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15954/shard-skl10/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[IGT#6]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/6
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111606]: https://bugs.freedesktop.org/show_bug.cgi?id=111606
[fdo#111677]: https://bugs.freedesktop.org/show_bug.cgi?id=111677
[fdo#111736]: https://bugs.freedesktop.org/show_bug.cgi?id=111736
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[i915#109]: https://gitlab.freedesktop.org/drm/intel/issues/109
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#300]: https://gitlab.freedesktop.org/drm/intel/issues/300
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#413]: https://gitlab.freedesktop.org/drm/intel/issues/413
[i915#435]: https://gitlab.freedesktop.org/drm/intel/issues/435
[i915#447]: https://gitlab.freedesktop.org/drm/intel/issues/447
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#46]: https://gitlab.freedesktop.org/drm/intel/issues/46
[i915#470]: https://gitlab.freedesktop.org/drm/intel/issues/470
[i915#472]: https://gitlab.freedesktop.org/drm/intel/issues/472
[i915#476]: https://gitlab.freedesktop.org/drm/intel/issues/476
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#520]: https://gitlab.freedesktop.org/drm/intel/issues/520
[i915#530]: https://gitlab.freedesktop.org/drm/intel/issues/530
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
[i915#645]: https://gitlab.freedesktop.org/drm/intel/issues/645
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#707]: https://gitlab.freedesktop.org/drm/intel/issues/707
[i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#84]: https://gitlab.freedesktop.org/drm/intel/issues/84
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (11 -> 10)
------------------------------
Missing (1): pig-hsw-4770r
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7657 -> Patchwork_15954
CI-20190529: 20190529
CI_DRM_7657: 265f77c05e67b37169ac1a9d750a2e2936928ea0 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5355: 2ead76177f2546d3eec0abbd0d9e47cd36588199 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15954: ed3398d25f0f23742e9d396c5f9e513010e6b1cb @ 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_15954/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
2019-12-31 14:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2) Patchwork
2019-12-31 20:06 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2020-01-02 18:28 ` Rodrigo Vivi
2020-01-03 15:28 ` Kai Vehmanen
2020-03-11 20:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3) Patchwork
` (2 subsequent siblings)
5 siblings, 1 reply; 23+ messages in thread
From: Rodrigo Vivi @ 2020-01-02 18:28 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: intel-gfx
On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
> CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
> communicate with i915 over HDA bus multiple times during system
> boot-up and each of these transactions result in matching
> get_power/put_power calls to i915, and depending on the platform,
> a modeset change causing visible flicker.
>
> GLK is the only platform with minimum CDCLK significantly lower
> than BCLK, and thus for GLK setting a higher CDCLK is mandatory.
>
> For other platforms, minimum CDCLK is close but below 2*BCLK
> (e.g. on ICL, CDCLK=176.4kHz with BCLK=96kHz). Spec-wise the constraint
> should be set, but in practise no communication errors have been
> reported and the downside if set is the flicker observed at boot-time.
>
> Revert to old behaviour until better mechanism to manage
> probe-time clocks is available.
>
> The full CDCLK>=2*BCLK constraint is still enforced at pipe
> enable time in intel_crtc_compute_min_cdclk().
>
> Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/913
> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
> ---
>
> Notes:
> v2: d'oh, change put_power() as well
>
> drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c b/drivers/gpu/drm/i915/display/intel_audio.c
> index 27710098d056..e406719a6716 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -856,7 +856,7 @@ static unsigned long i915_audio_component_get_power(struct device *kdev)
> }
>
> /* Force CDCLK to 2*BCLK as long as we need audio powered. */
> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + if (IS_GEMINILAKE(dev_priv))
I believe for correctness we should at least say this is for display_10 but
since we don't have display gen defined probably the right thing to do here
is to at least replace this per:
IS_GEN(dev_priv, 10) || IS_GEMINILAKE(dev_priv)
> glk_force_audio_cdclk(dev_priv, true);
>
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> @@ -875,7 +875,7 @@ static void i915_audio_component_put_power(struct device *kdev,
>
> /* Stop forcing CDCLK to 2*BCLK if no need for audio to be powered. */
> if (--dev_priv->audio_power_refcount == 0)
> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + if (IS_GEMINILAKE(dev_priv))
> glk_force_audio_cdclk(dev_priv, false);
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO, cookie);
> --
> 2.17.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-01-02 18:28 ` [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Rodrigo Vivi
@ 2020-01-03 15:28 ` Kai Vehmanen
2020-01-06 16:49 ` Matt Roper
0 siblings, 1 reply; 23+ messages in thread
From: Kai Vehmanen @ 2020-01-03 15:28 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx
Hi,
On Thu, 2 Jan 2020, Rodrigo Vivi wrote:
> On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
>> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
>> CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
[...]
>> /* Force CDCLK to 2*BCLK as long as we need audio powered. */
>> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
>> + if (IS_GEMINILAKE(dev_priv))
>
> I believe for correctness we should at least say this is for display_10 but
> since we don't have display gen defined probably the right thing to do here
> is to at least replace this per:
>
> IS_GEN(dev_priv, 10) || IS_GEMINILAKE(dev_priv)
I checked the cdclk tables for CNL in intel_cdclk.c and minimum CDCLK
is 168kHz, so it is similar (>BCLK and close to 2*BCLK) as ICL and
others and the workaround is not needed.
I do agree this still smells funny, but basicly my naive attempt to align
with the spec failed in wider testing and it seems this original solution
to have the WA for GLK only, is the least bad option at this point.
Possible longer term solutions for this:
(i) more clock configurations allowing to bump the freq without
a mode change on all platforms
(ii) avoid all HDA communication at probe time and only initialize
the HDA connection when a monitor is connected
(iii) guarantee min cdclk to be sufficient for HDA communication
Closing on feasibility of (i) and (iii) is going to be a longer
discussion.
The (ii) option would be quite a big change on audio side and might
potentially require changes to drm_audio_component.h (and impact other
drivers). To me, this feels wrong, the HDA bus supports discovery of
codecs, so we should be able to use it as with any HDA codec, including
graphics. Unless we hit deadends with (i) and (iii), I'd rather
not pursue this path.
Br, Kai
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-01-03 15:28 ` Kai Vehmanen
@ 2020-01-06 16:49 ` Matt Roper
2020-03-06 16:45 ` Kai Vehmanen
0 siblings, 1 reply; 23+ messages in thread
From: Matt Roper @ 2020-01-06 16:49 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: intel-gfx
On Fri, Jan 03, 2020 at 05:28:24PM +0200, Kai Vehmanen wrote:
> Hi,
>
> On Thu, 2 Jan 2020, Rodrigo Vivi wrote:
>
> > On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
> >> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
> >> CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
> [...]
> >> /* Force CDCLK to 2*BCLK as long as we need audio powered. */
> >> - if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> >> + if (IS_GEMINILAKE(dev_priv))
> >
> > I believe for correctness we should at least say this is for display_10 but
> > since we don't have display gen defined probably the right thing to do here
> > is to at least replace this per:
> >
> > IS_GEN(dev_priv, 10) || IS_GEMINILAKE(dev_priv)
>
> I checked the cdclk tables for CNL in intel_cdclk.c and minimum CDCLK
> is 168kHz, so it is similar (>BCLK and close to 2*BCLK) as ICL and
> others and the workaround is not needed.
Agreed; GLK's minimum cdclk goes down to 79.2 mhz so it makes sense that
it needs to be handled differently than CNL (and beyond). I.e., this
isn't a pure revert of the original patch.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
The only CI shard failure was an unrelated GEM false positive, so added
a Fixes: tag referencing the original patch and applied to dinq. Thanks
for the patch!
Matt
>
> I do agree this still smells funny, but basicly my naive attempt to align
> with the spec failed in wider testing and it seems this original solution
> to have the WA for GLK only, is the least bad option at this point.
>
> Possible longer term solutions for this:
> (i) more clock configurations allowing to bump the freq without
> a mode change on all platforms
> (ii) avoid all HDA communication at probe time and only initialize
> the HDA connection when a monitor is connected
> (iii) guarantee min cdclk to be sufficient for HDA communication
>
> Closing on feasibility of (i) and (iii) is going to be a longer
> discussion.
>
> The (ii) option would be quite a big change on audio side and might
> potentially require changes to drm_audio_component.h (and impact other
> drivers). To me, this feels wrong, the HDA bus supports discovery of
> codecs, so we should be able to use it as with any HDA codec, including
> graphics. Unless we hit deadends with (i) and (iii), I'd rather
> not pursue this path.
>
> Br, Kai
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-01-06 16:49 ` Matt Roper
@ 2020-03-06 16:45 ` Kai Vehmanen
2020-03-09 10:54 ` Takashi Iwai
0 siblings, 1 reply; 23+ messages in thread
From: Kai Vehmanen @ 2020-03-06 16:45 UTC (permalink / raw)
To: Matt Roper; +Cc: Takashi Iwai, intel-gfx
Hi folks,
[+Takashi from ALSA]
On Mon, 6 Jan 2020, Matt Roper wrote:
>>> On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
>>>> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
>>>> CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
>
> Agreed; GLK's minimum cdclk goes down to 79.2 mhz so it makes sense that
> it needs to be handled differently than CNL (and beyond). I.e., this
> isn't a pure revert of the original patch.
unfortunately it seems this fix that was done is not holding up in wider
testing. It now looks we need to enforce the constraint in one form or
another for newer platforms as well. We can't revert the revert as that
will bring the boot flicker back, so we'll need something else.
Now as we've gone back-and-forth multiple times, I want to get some early
feedback before opting for one path or another.
To recap in short:
- audio driver calls i915 acomp get_power() multiple times during boot
-> this can cause annoying flicker at boot on platforms where
each get_power() leads to a modeset change
- example: https://gitlab.freedesktop.org/drm/intel/issues/913
- systems with more complex audio subsystems (DSP enabled) will be
calling get_power() many more times (as i915 iDisp link is needed in
multiple phases of audio controller, DSP and codecs initialization),
making the flicker worse
I've gone through (once more) possible options, and it starts to seem that
trying to minimize # of get_power() cycles is not going to work well in
the long run. We could certainly reduce number of distinct get_power
calls e.g. during boot by refactoring the audio DSP setup, but there would
still be more than a few, and it's not just the boot. We now need to call
get_power() when the audio controller comes out from runtime suspend
(otherwise the HDA link is not ok between i915 and audio). This can be pretty
annoying if there are visible artifacts to the end-user in such a case
where potentially no HDMI/DP monitors are even connected).
Similarly on i915 side, it would seem pretty unlikely that we are going
to get smooth changes of CDCLK. It might work better on some platforms,
but generally (depending on the available dividers provided), it's not
going to be guaranteed to be flicker-free.
So how about: We move the glk_force_audio_cdclk() logic from
intel_audio.c:i915_audio_component_get_power() to acomp init.
This has some notable implications:
- audio driver can safely call get_power without worrying
about creating display artifacts,
- on some platforms, with specific HDA link params in BIOS,
this will mean some lower CDCLK frequencies, will not be used
at all
- e.g. on ICL system with 96Mhz BCLK for iDisp, 172800 and
180000 are blocked out, and 192000 is the practical minimum
unless you unload the audio driver
- if BCLK is 48Mhz, no impact to CDCLK selection on ICL
Any chance to get this through? I understand this effectively removes the
lower clocks from some systems, so this needs to be evaluated carefully.
I don't really have other options on the table now. We could maybe use
idle-timers to delay powering off the audio domain until certain amount of
inactivity, but this is both ugly and won't solve the full thing. Or we
just keep reducing get_power() calls on audio side, and just mitigate the
the severity of the flicker -- again not fully solving the problem.
Thoughts and feedback is welcome.
Br, Kai
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-06 16:45 ` Kai Vehmanen
@ 2020-03-09 10:54 ` Takashi Iwai
2020-03-10 11:20 ` Kai Vehmanen
2020-03-10 13:41 ` Ville Syrjälä
0 siblings, 2 replies; 23+ messages in thread
From: Takashi Iwai @ 2020-03-09 10:54 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: Takashi Iwai, intel-gfx
On Fri, 06 Mar 2020 17:45:44 +0100,
Kai Vehmanen wrote:
>
> Hi folks,
>
> [+Takashi from ALSA]
>
> On Mon, 6 Jan 2020, Matt Roper wrote:
> >>> On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
> >>>> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
> >>>> CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
> >
> > Agreed; GLK's minimum cdclk goes down to 79.2 mhz so it makes sense that
> > it needs to be handled differently than CNL (and beyond). I.e., this
> > isn't a pure revert of the original patch.
>
> unfortunately it seems this fix that was done is not holding up in wider
> testing. It now looks we need to enforce the constraint in one form or
> another for newer platforms as well. We can't revert the revert as that
> will bring the boot flicker back, so we'll need something else.
>
> Now as we've gone back-and-forth multiple times, I want to get some early
> feedback before opting for one path or another.
>
> To recap in short:
> - audio driver calls i915 acomp get_power() multiple times during boot
> -> this can cause annoying flicker at boot on platforms where
> each get_power() leads to a modeset change
> - example: https://gitlab.freedesktop.org/drm/intel/issues/913
> - systems with more complex audio subsystems (DSP enabled) will be
> calling get_power() many more times (as i915 iDisp link is needed in
> multiple phases of audio controller, DSP and codecs initialization),
> making the flicker worse
>
> I've gone through (once more) possible options, and it starts to seem that
> trying to minimize # of get_power() cycles is not going to work well in
> the long run. We could certainly reduce number of distinct get_power
> calls e.g. during boot by refactoring the audio DSP setup, but there would
> still be more than a few, and it's not just the boot. We now need to call
> get_power() when the audio controller comes out from runtime suspend
> (otherwise the HDA link is not ok between i915 and audio). This can be pretty
> annoying if there are visible artifacts to the end-user in such a case
> where potentially no HDMI/DP monitors are even connected).
>
> Similarly on i915 side, it would seem pretty unlikely that we are going
> to get smooth changes of CDCLK. It might work better on some platforms,
> but generally (depending on the available dividers provided), it's not
> going to be guaranteed to be flicker-free.
>
> So how about: We move the glk_force_audio_cdclk() logic from
> intel_audio.c:i915_audio_component_get_power() to acomp init.
> This has some notable implications:
>
> - audio driver can safely call get_power without worrying
> about creating display artifacts,
> - on some platforms, with specific HDA link params in BIOS,
> this will mean some lower CDCLK frequencies, will not be used
> at all
> - e.g. on ICL system with 96Mhz BCLK for iDisp, 172800 and
> 180000 are blocked out, and 192000 is the practical minimum
> unless you unload the audio driver
> - if BCLK is 48Mhz, no impact to CDCLK selection on ICL
>
> Any chance to get this through? I understand this effectively removes the
> lower clocks from some systems, so this needs to be evaluated carefully.
>
> I don't really have other options on the table now. We could maybe use
> idle-timers to delay powering off the audio domain until certain amount of
> inactivity, but this is both ugly and won't solve the full thing. Or we
> just keep reducing get_power() calls on audio side, and just mitigate the
> the severity of the flicker -- again not fully solving the problem.
>
> Thoughts and feedback is welcome.
>
> Br, Kai
That sounds reasonable to me. But it's basically the i915 stuff, so
I'd leave the decision to you guys :)
My another quick thought after reading this mail is whether we can
simply remove glk_force_audio_cdclk(false) in
i915_audio_component_put_power(). In this way, a flicker should be
reduced, at most only once at boot time, and the CDCLK is lowered only
when the audio is really used (once).
Or, similarly, it can be put into *_component_bind() and *_unbind()
instead of *_get_power() and *_put_power(). This indicates that the
corresponding audio device really exists.
thanks,
Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-09 10:54 ` Takashi Iwai
@ 2020-03-10 11:20 ` Kai Vehmanen
2020-03-10 13:41 ` Ville Syrjälä
1 sibling, 0 replies; 23+ messages in thread
From: Kai Vehmanen @ 2020-03-10 11:20 UTC (permalink / raw)
To: Takashi Iwai, intel-gfx
Hey,
On Mon, 9 Mar 2020, Takashi Iwai wrote:
> On Fri, 06 Mar 2020 17:45:44 +0100, Kai Vehmanen wrote:
>> unfortunately it seems this fix that was done is not holding up in wider
>> testing. It now looks we need to enforce the constraint in one form or
[...]
>> So how about: We move the glk_force_audio_cdclk() logic from
>> intel_audio.c:i915_audio_component_get_power() to acomp init.
>> This has some notable implications:
>
> That sounds reasonable to me. But it's basically the i915 stuff, so
> I'd leave the decision to you guys :)
thanks Takashi --let's wait for the comments. I'll add also Ville who
wrote the original glk_force_audio() code diretly to the thread.
> My another quick thought after reading this mail is whether we can
> simply remove glk_force_audio_cdclk(false) in
> i915_audio_component_put_power(). In this way, a flicker should be
> reduced, at most only once at boot time, and the CDCLK is lowered only
> when the audio is really used (once).
If we could really limit this to actual first-time use (i.e. only if
actual playback to HDMI/DP is done), that would be interesting compromise
indeed, but as the ALSA side probe will call get_power, this will have
limited benefit. I think this is in the end same as:
> Or, similarly, it can be put into *_component_bind() and *_unbind()
> instead of *_get_power() and *_put_power(). This indicates that the
> corresponding audio device really exists.
... doing it bind. But yes, you are right, bind() and unbind() would be
the appropriate places. Then if audio driver is not loaded, the freq
constraint is not put into effect, and similarly if audio driver is
unloaded, cdclk constraint is released.
Br, Kai
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-09 10:54 ` Takashi Iwai
2020-03-10 11:20 ` Kai Vehmanen
@ 2020-03-10 13:41 ` Ville Syrjälä
2020-03-10 17:18 ` Kai Vehmanen
1 sibling, 1 reply; 23+ messages in thread
From: Ville Syrjälä @ 2020-03-10 13:41 UTC (permalink / raw)
To: Takashi Iwai; +Cc: intel-gfx
On Mon, Mar 09, 2020 at 11:54:52AM +0100, Takashi Iwai wrote:
> On Fri, 06 Mar 2020 17:45:44 +0100,
> Kai Vehmanen wrote:
> >
> > Hi folks,
> >
> > [+Takashi from ALSA]
> >
> > On Mon, 6 Jan 2020, Matt Roper wrote:
> > >>> On Tue, Dec 31, 2019 at 04:00:07PM +0200, Kai Vehmanen wrote:
> > >>>> Revert changes done in commit f6ec9483091f ("drm/i915: extend audio
> > >>>> CDCLK>=2*BCLK constraint to more platforms"). Audio drivers
> > >
> > > Agreed; GLK's minimum cdclk goes down to 79.2 mhz so it makes sense that
> > > it needs to be handled differently than CNL (and beyond). I.e., this
> > > isn't a pure revert of the original patch.
> >
> > unfortunately it seems this fix that was done is not holding up in wider
> > testing. It now looks we need to enforce the constraint in one form or
> > another for newer platforms as well. We can't revert the revert as that
> > will bring the boot flicker back, so we'll need something else.
> >
> > Now as we've gone back-and-forth multiple times, I want to get some early
> > feedback before opting for one path or another.
> >
> > To recap in short:
> > - audio driver calls i915 acomp get_power() multiple times during boot
> > -> this can cause annoying flicker at boot on platforms where
> > each get_power() leads to a modeset change
> > - example: https://gitlab.freedesktop.org/drm/intel/issues/913
> > - systems with more complex audio subsystems (DSP enabled) will be
> > calling get_power() many more times (as i915 iDisp link is needed in
> > multiple phases of audio controller, DSP and codecs initialization),
> > making the flicker worse
> >
> > I've gone through (once more) possible options, and it starts to seem that
> > trying to minimize # of get_power() cycles is not going to work well in
> > the long run. We could certainly reduce number of distinct get_power
> > calls e.g. during boot by refactoring the audio DSP setup, but there would
> > still be more than a few, and it's not just the boot. We now need to call
> > get_power() when the audio controller comes out from runtime suspend
> > (otherwise the HDA link is not ok between i915 and audio). This can be pretty
> > annoying if there are visible artifacts to the end-user in such a case
> > where potentially no HDMI/DP monitors are even connected).
> >
> > Similarly on i915 side, it would seem pretty unlikely that we are going
> > to get smooth changes of CDCLK. It might work better on some platforms,
> > but generally (depending on the available dividers provided), it's not
> > going to be guaranteed to be flicker-free.
There is new hw in the pipeline that should allow cdclk changes
without a full modeset.
> >
> > So how about: We move the glk_force_audio_cdclk() logic from
> > intel_audio.c:i915_audio_component_get_power() to acomp init.
> > This has some notable implications:
> >
> > - audio driver can safely call get_power without worrying
> > about creating display artifacts,
> > - on some platforms, with specific HDA link params in BIOS,
> > this will mean some lower CDCLK frequencies, will not be used
> > at all
> > - e.g. on ICL system with 96Mhz BCLK for iDisp, 172800 and
> > 180000 are blocked out, and 192000 is the practical minimum
> > unless you unload the audio driver
> > - if BCLK is 48Mhz, no impact to CDCLK selection on ICL
> >
> > Any chance to get this through? I understand this effectively removes the
> > lower clocks from some systems, so this needs to be evaluated carefully.
If we're going to effectively force cdclk to remain high all the time
then we should just nuke the whole glk_force_audio_cdclk() thing. But
at least I'll have to shed a few tears for the wasted milliwatts.
Well, I guess we might want to keep glk_force_audio_cdclk() in its
current form for the upcoming hw that doesn't need the full modeset
for cdclk changes.
I guess we could also make i915 force the cdclk to the min required by
audio at init time. And we could maybe try to remove the modeset from the
put_power() so that at least if you get a blink it's just the one. I did
a similarsh thing for some other cdclk stuff recently where we want cdclk
to go up as needed, but it will not come back down unless someone else
already asked for a full modeset.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-10 13:41 ` Ville Syrjälä
@ 2020-03-10 17:18 ` Kai Vehmanen
2020-03-10 18:25 ` Ville Syrjälä
0 siblings, 1 reply; 23+ messages in thread
From: Kai Vehmanen @ 2020-03-10 17:18 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Takashi Iwai, intel-gfx
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
Hi,
On Tue, 10 Mar 2020, Ville Syrjälä wrote:
>> On Fri, 06 Mar 2020 17:45:44 +0100, Kai Vehmanen wrote:
>>> Similarly on i915 side, it would seem pretty unlikely that we are going
>>> to get smooth changes of CDCLK. It might work better on some platforms,
>
> There is new hw in the pipeline that should allow cdclk changes
> without a full modeset.
ok great, this is good to know. Especially we should not completely remove
the CDCLK constraints code from get_power/put_power, as this will be
later needed.
>>> intel_audio.c:i915_audio_component_get_power() to acomp init.
>>> This has some notable implications:
[...]
>>> Any chance to get this through? I understand this effectively removes the
>>> lower clocks from some systems, so this needs to be evaluated carefully.
>
> If we're going to effectively force cdclk to remain high all the time
> then we should just nuke the whole glk_force_audio_cdclk() thing. But
> at least I'll have to shed a few tears for the wasted milliwatts.
>
> Well, I guess we might want to keep glk_force_audio_cdclk() in its
> current form for the upcoming hw that doesn't need the full modeset
> for cdclk changes.
Yeah, we probably should keep it in any case, because later it's going to
be needed.
> I guess we could also make i915 force the cdclk to the min required by
> audio at init time. And we could maybe try to remove the modeset from the
> put_power() so that at least if you get a blink it's just the one. I did
> a similarsh thing for some other cdclk stuff recently where we want cdclk
> to go up as needed, but it will not come back down unless someone else
> already asked for a full modeset.
Hmm, this is interesting and maybe a better compromise for the in-between
generations. Could it be as simple as not setting
"cdclk.force_min_cdclk_changed" at put_power(), and just set the
min_cdclk...? I was trying to follow the modeset code and it seems without
the force set, this would avoid going to intel_modeset_checks(). If so, I
can try this out.
One problematic scenario that this doesn't cover:
- a single display is used (at low cdclk), and
- audio block goes to runtime suspend while display stays up.
Upon resume (for e.g. UI notification sound), audio will initialize the
HDA bus and call get_power() on i915, even if the notification goes to
internal speaker. A modeset at this point is potentially very annoying.
I just also noted if we keep the glk_force_audio function, we need to get
rid of the hardcoded 96Mhz BCLK value that is used now, and instead dig up
the effective used value (we do have this). This will at least offer the
possibility to configure the HDA link to 48Mhz in BIOS and avoid the cdclk
bump this way.
Br, Kai
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-10 17:18 ` Kai Vehmanen
@ 2020-03-10 18:25 ` Ville Syrjälä
2020-03-10 19:13 ` Takashi Iwai
2020-03-12 17:27 ` Kai Vehmanen
0 siblings, 2 replies; 23+ messages in thread
From: Ville Syrjälä @ 2020-03-10 18:25 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: Takashi Iwai, intel-gfx
On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
> Hi,
>
> On Tue, 10 Mar 2020, Ville Syrjälä wrote:
>
> >> On Fri, 06 Mar 2020 17:45:44 +0100, Kai Vehmanen wrote:
> >>> Similarly on i915 side, it would seem pretty unlikely that we are going
> >>> to get smooth changes of CDCLK. It might work better on some platforms,
> >
> > There is new hw in the pipeline that should allow cdclk changes
> > without a full modeset.
>
> ok great, this is good to know. Especially we should not completely remove
> the CDCLK constraints code from get_power/put_power, as this will be
> later needed.
>
> >>> intel_audio.c:i915_audio_component_get_power() to acomp init.
> >>> This has some notable implications:
> [...]
> >>> Any chance to get this through? I understand this effectively removes the
> >>> lower clocks from some systems, so this needs to be evaluated carefully.
> >
> > If we're going to effectively force cdclk to remain high all the time
> > then we should just nuke the whole glk_force_audio_cdclk() thing. But
> > at least I'll have to shed a few tears for the wasted milliwatts.
> >
> > Well, I guess we might want to keep glk_force_audio_cdclk() in its
> > current form for the upcoming hw that doesn't need the full modeset
> > for cdclk changes.
>
> Yeah, we probably should keep it in any case, because later it's going to
> be needed.
>
> > I guess we could also make i915 force the cdclk to the min required by
> > audio at init time. And we could maybe try to remove the modeset from the
> > put_power() so that at least if you get a blink it's just the one. I did
> > a similarsh thing for some other cdclk stuff recently where we want cdclk
> > to go up as needed, but it will not come back down unless someone else
> > already asked for a full modeset.
>
> Hmm, this is interesting and maybe a better compromise for the in-between
> generations. Could it be as simple as not setting
> "cdclk.force_min_cdclk_changed" at put_power(), and just set the
> min_cdclk...? I was trying to follow the modeset code and it seems without
> the force set, this would avoid going to intel_modeset_checks(). If so, I
> can try this out.
The logic around the cdclk computation is still a bit messy.
First draft of just doing the lazy force_min_cdclk reduction in put_power():
git://github.com/vsyrjala/linux.git no_cdclk_in_audio_put_power
Very lightly smoke tested, but not sure if it achieves anything useful :P
>
> One problematic scenario that this doesn't cover:
> - a single display is used (at low cdclk), and
> - audio block goes to runtime suspend while display stays up.
>
> Upon resume (for e.g. UI notification sound), audio will initialize the
> HDA bus and call get_power() on i915, even if the notification goes to
> internal speaker. A modeset at this point is potentially very annoying.
:( That seems much harder to deal with.
>
> I just also noted if we keep the glk_force_audio function, we need to get
> rid of the hardcoded 96Mhz BCLK value that is used now, and instead dig up
> the effective used value (we do have this). This will at least offer the
> possibility to configure the HDA link to 48Mhz in BIOS and avoid the cdclk
> bump this way.
I think when I last complained about the assumed 96 MHz BCLK
people said "48 MHz never happens". But I guess it can be made
to happen?
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-10 18:25 ` Ville Syrjälä
@ 2020-03-10 19:13 ` Takashi Iwai
2020-03-11 12:16 ` Kai Vehmanen
2020-03-12 17:27 ` Kai Vehmanen
1 sibling, 1 reply; 23+ messages in thread
From: Takashi Iwai @ 2020-03-10 19:13 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Tue, 10 Mar 2020 19:25:22 +0100,
Ville Syrjälä wrote:
>
> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
> > One problematic scenario that this doesn't cover:
> > - a single display is used (at low cdclk), and
> > - audio block goes to runtime suspend while display stays up.
> >
> > Upon resume (for e.g. UI notification sound), audio will initialize the
> > HDA bus and call get_power() on i915, even if the notification goes to
> > internal speaker. A modeset at this point is potentially very annoying.
>
> :( That seems much harder to deal with.
I guess it doesn't happen -- at least with the legacy HD-audio and the
recent chip, if I understand correctly. When the stream is on the
analog codec, the HDMI codec is kept closed / runtime-resumed. And
the additional get_power() in the controller side is done only for
HSW/BDW (where the HDA-bus is dedicated to HDMI).
Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-10 19:13 ` Takashi Iwai
@ 2020-03-11 12:16 ` Kai Vehmanen
[not found] ` <s5hk13q7uf6.wl-tiwai@suse.de>
0 siblings, 1 reply; 23+ messages in thread
From: Kai Vehmanen @ 2020-03-11 12:16 UTC (permalink / raw)
To: Takashi Iwai; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
Hey,
On Tue, 10 Mar 2020, Takashi Iwai wrote:
> On Tue, 10 Mar 2020 19:25:22 +0100, Ville Syrjälä wrote:
>> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
>>> One problematic scenario that this doesn't cover:
>>> - a single display is used (at low cdclk), and
>>> - audio block goes to runtime suspend while display stays up.
>>>
>>> Upon resume (for e.g. UI notification sound), audio will initialize the
>>> HDA bus and call get_power() on i915, even if the notification goes to
>>> internal speaker. A modeset at this point is potentially very annoying.
>>
>> :( That seems much harder to deal with.
>
> I guess it doesn't happen -- at least with the legacy HD-audio and the
> recent chip, if I understand correctly. When the stream is on the
> analog codec, the HDMI codec is kept closed / runtime-resumed. And
> the additional get_power() in the controller side is done only for
> HSW/BDW (where the HDA-bus is dedicated to HDMI).
I'm afraid it does -- I double checked the legacy driver code. Judging
from history, since commit "ALSA: hda - Fix Skylake codec timeout",
azx_runtime_resume() has called "display_power(chip, true)" on all
platforms, even if the stream is on analog codec. I just recently fixed
this logic to SOF driver as well. If you don't do this and the link
parameters are different from hw defaults on i915 side (more likely with
ICL and newer), you'll hit problems.
I don't currently know of a reliable way to recover. In theory, if HDMI/DP
monitor is connected, we could do a delayed call to i915 get_power and
reinitialize the HDA controller, but if we are actively streaming to
analog codec when this happens, this wouldn't work.
And until very recent times, this has not really been an issue. With
current i915, many conditions have to be met to actually hit this (only
affects GLK platforms, you need to be using HDA analog codec, runtime PM
needs to be enabled for HDA, etc). Problem is that going forward, there
are going to be more platforms that are affected and this starts to show
up in more places.
Ville: I'm checking your draft patch. I'll report back when I've
completed testing.
Br, Kai
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
[not found] ` <s5hk13q7uf6.wl-tiwai@suse.de>
@ 2020-03-11 17:04 ` Kai Vehmanen
2020-03-11 17:21 ` Takashi Iwai
0 siblings, 1 reply; 23+ messages in thread
From: Kai Vehmanen @ 2020-03-11 17:04 UTC (permalink / raw)
To: Takashi Iwai; +Cc: intel-gfx
Hey,
On Wed, 11 Mar 2020, Takashi Iwai wrote:
> The remaining question is whether this display_power() call is still
> needed for the recent chips. Basically it's there for HSW/BDW type
> chips that need already the power for the HDA link that is dedicated
> to HDMI. That is, a patch like below could work for the recent chips
yes, it is still needed. The newer chips (GLK, ICL and newer) have added
sw logic in i915 get_power() that must be run before audio controller is
initialized. So calling display_power() here is actually more critical
than before, power up from codec driver is too late. If it's not done,
you'll get verbs timing out (unless power management is disabled on i915
side).
Br, Kai
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-11 17:04 ` Kai Vehmanen
@ 2020-03-11 17:21 ` Takashi Iwai
0 siblings, 0 replies; 23+ messages in thread
From: Takashi Iwai @ 2020-03-11 17:21 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: Takashi Iwai, intel-gfx
On Wed, 11 Mar 2020 18:04:24 +0100,
Kai Vehmanen wrote:
>
> Hey,
>
> On Wed, 11 Mar 2020, Takashi Iwai wrote:
>
> > The remaining question is whether this display_power() call is still
> > needed for the recent chips. Basically it's there for HSW/BDW type
> > chips that need already the power for the HDA link that is dedicated
> > to HDMI. That is, a patch like below could work for the recent chips
>
> yes, it is still needed. The newer chips (GLK, ICL and newer) have added
> sw logic in i915 get_power() that must be run before audio controller is
> initialized. So calling display_power() here is actually more critical
> than before, power up from codec driver is too late. If it's not done,
> you'll get verbs timing out (unless power management is disabled on i915
> side).
Alright, then it's an unavoidable case. Then it seems rather natural
to limit the CDCLK statically when the audio device is present on the
system, rather than too frequent up and down...
Takashi
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
` (2 preceding siblings ...)
2020-01-02 18:28 ` [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Rodrigo Vivi
@ 2020-03-11 20:12 ` Patchwork
2020-03-11 20:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-12 13:05 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
5 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2020-03-11 20:12 UTC (permalink / raw)
To: Takashi Iwai; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
URL : https://patchwork.freedesktop.org/series/71525/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
76d4a408c88b drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#22:
> >>> Upon resume (for e.g. UI notification sound), audio will initialize the
-:91: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 0 checks, 22 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
` (3 preceding siblings ...)
2020-03-11 20:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3) Patchwork
@ 2020-03-11 20:37 ` Patchwork
2020-03-12 13:05 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
5 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2020-03-11 20:37 UTC (permalink / raw)
To: Takashi Iwai; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
URL : https://patchwork.freedesktop.org/series/71525/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8121 -> Patchwork_16933
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_16933:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/fi-tgl-dsi/igt@i915_module_load@reload.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/fi-tgl-dsi/igt@i915_module_load@reload.html
- {fi-tgl-u}: [PASS][3] -> [INCOMPLETE][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/fi-tgl-u/igt@i915_module_load@reload.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/fi-tgl-u/igt@i915_module_load@reload.html
Known issues
------------
Here are the changes found in Patchwork_16933 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_module_load@reload:
- fi-tgl-y: [PASS][5] -> [INCOMPLETE][6] ([CI#94])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/fi-tgl-y/igt@i915_module_load@reload.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/fi-tgl-y/igt@i915_module_load@reload.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111407])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (42 -> 41)
------------------------------
Additional (3): fi-ivb-3770 fi-skl-6600u fi-snb-2600
Missing (4): fi-ctg-p8600 fi-byt-clapper fi-bsw-cyan fi-cml-s
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_8121 -> Patchwork_16933
CI-20190529: 20190529
CI_DRM_8121: c2e15accdf0c2b6e8b766659acc8159dc19c8869 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5505: 8973d811f3fdfb4ace4aabab2095ce0309881648 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16933: 76d4a408c88bce5a8974c49df75fc8cca6879421 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
76d4a408c88b drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
` (4 preceding siblings ...)
2020-03-11 20:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2020-03-12 13:05 ` Patchwork
5 siblings, 0 replies; 23+ messages in thread
From: Patchwork @ 2020-03-12 13:05 UTC (permalink / raw)
To: Takashi Iwai; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)
URL : https://patchwork.freedesktop.org/series/71525/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8121_full -> Patchwork_16933_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_16933_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16933_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_16933_full:
### IGT changes ###
#### Possible regressions ####
* igt@i915_module_load@reload:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-tglb3/igt@i915_module_load@reload.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-tglb6/igt@i915_module_load@reload.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@perf}:
- shard-tglb: NOTRUN -> [INCOMPLETE][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-tglb5/igt@i915_selftest@perf.html
Known issues
------------
Here are the changes found in Patchwork_16933_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_isolation@vcs1-dirty-create:
- shard-iclb: [PASS][4] -> [SKIP][5] ([fdo#112080]) +10 similar issues
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb2/igt@gem_ctx_isolation@vcs1-dirty-create.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb5/igt@gem_ctx_isolation@vcs1-dirty-create.html
* igt@gem_ctx_persistence@close-replace-race:
- shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#1340])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb8/igt@gem_ctx_persistence@close-replace-race.html
* igt@gem_ctx_persistence@engines-mixed-process@vecs0:
- shard-skl: [PASS][8] -> [FAIL][9] ([i915#679])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl9/igt@gem_ctx_persistence@engines-mixed-process@vecs0.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl10/igt@gem_ctx_persistence@engines-mixed-process@vecs0.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#110841])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb8/igt@gem_ctx_shared@exec-single-timeline-bsd.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb4/igt@gem_ctx_shared@exec-single-timeline-bsd.html
* igt@gem_exec_schedule@implicit-both-bsd1:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109276] / [i915#677]) +1 similar issue
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb4/igt@gem_exec_schedule@implicit-both-bsd1.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb8/igt@gem_exec_schedule@implicit-both-bsd1.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#109276]) +16 similar issues
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb2/igt@gem_exec_schedule@independent-bsd2.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb3/igt@gem_exec_schedule@independent-bsd2.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][16] -> [SKIP][17] ([i915#677]) +2 similar issues
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb8/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb4/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#112146]) +7 similar issues
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb8/igt@gem_exec_schedule@preemptive-hang-bsd.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb4/igt@gem_exec_schedule@preemptive-hang-bsd.html
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- shard-iclb: [PASS][20] -> [INCOMPLETE][21] ([i915#189])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb7/igt@i915_pm_rpm@modeset-lpsp-stress-no-wait.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb2/igt@i915_pm_rpm@modeset-lpsp-stress-no-wait.html
* igt@i915_pm_rps@waitboost:
- shard-tglb: [PASS][22] -> [FAIL][23] ([i915#413])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-tglb8/igt@i915_pm_rps@waitboost.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-tglb6/igt@i915_pm_rps@waitboost.html
* igt@i915_selftest@live@execlists:
- shard-glk: [PASS][24] -> [INCOMPLETE][25] ([i915#58] / [i915#656] / [k.org#198133])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-glk6/igt@i915_selftest@live@execlists.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-glk4/igt@i915_selftest@live@execlists.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][26] -> [INCOMPLETE][27] ([i915#155])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-kbl6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
- shard-skl: [PASS][28] -> [INCOMPLETE][29] ([i915#300])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl8/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl9/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: [PASS][30] -> [FAIL][31] ([i915#79])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [PASS][32] -> [DMESG-WARN][33] ([i915#180])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-apl1/igt@kms_frontbuffer_tracking@fbc-suspend.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-apl2/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][34] -> [FAIL][35] ([i915#1188]) +1 similar issue
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl10/igt@kms_hdr@bpc-switch-suspend.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl5/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][36] -> [FAIL][37] ([fdo#108145] / [i915#265])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [PASS][38] -> [SKIP][39] ([fdo#109642] / [fdo#111068])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb2/igt@kms_psr2_su@page_flip.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb3/igt@kms_psr2_su@page_flip.html
* igt@kms_psr@psr2_sprite_plane_onoff:
- shard-iclb: [PASS][40] -> [SKIP][41] ([fdo#109441]) +1 similar issue
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb2/igt@kms_psr@psr2_sprite_plane_onoff.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb3/igt@kms_psr@psr2_sprite_plane_onoff.html
* igt@kms_setmode@basic:
- shard-skl: [PASS][42] -> [FAIL][43] ([i915#31])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl8/igt@kms_setmode@basic.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl9/igt@kms_setmode@basic.html
#### Possible fixes ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [SKIP][44] ([fdo#112080]) -> [PASS][45] +16 similar issues
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb7/igt@gem_busy@busy-vcs1.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb2/igt@gem_busy@busy-vcs1.html
* igt@gem_ctx_persistence@close-replace-race:
- shard-skl: [INCOMPLETE][46] ([i915#1402]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl6/igt@gem_ctx_persistence@close-replace-race.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl7/igt@gem_ctx_persistence@close-replace-race.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [SKIP][48] ([fdo#110854]) -> [PASS][49]
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb7/igt@gem_exec_balancer@smoke.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb2/igt@gem_exec_balancer@smoke.html
* igt@gem_exec_schedule@implicit-write-read-bsd2:
- shard-iclb: [SKIP][50] ([fdo#109276] / [i915#677]) -> [PASS][51]
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb7/igt@gem_exec_schedule@implicit-write-read-bsd2.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb2/igt@gem_exec_schedule@implicit-write-read-bsd2.html
* igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [SKIP][52] ([i915#677]) -> [PASS][53]
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb2/igt@gem_exec_schedule@pi-shared-iova-bsd.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb5/igt@gem_exec_schedule@pi-shared-iova-bsd.html
* igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [SKIP][54] ([fdo#109276]) -> [PASS][55] +26 similar issues
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb8/igt@gem_exec_schedule@preempt-queue-bsd1.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb4/igt@gem_exec_schedule@preempt-queue-bsd1.html
* igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [SKIP][56] ([fdo#112146]) -> [PASS][57] +5 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb1/igt@gem_exec_schedule@reorder-wide-bsd.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb8/igt@gem_exec_schedule@reorder-wide-bsd.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][58] ([i915#454]) -> [PASS][59]
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb3/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rps@waitboost:
- shard-iclb: [FAIL][60] ([i915#413]) -> [PASS][61]
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb8/igt@i915_pm_rps@waitboost.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb4/igt@i915_pm_rps@waitboost.html
* igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen:
- shard-skl: [FAIL][62] ([i915#54]) -> [PASS][63] +1 similar issue
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl6/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl7/igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [DMESG-WARN][64] ([i915#180]) -> [PASS][65] +3 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-kbl4/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled:
- shard-skl: [FAIL][66] ([i915#52] / [i915#54]) -> [PASS][67]
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl9/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl10/igt@kms_draw_crc@draw-method-xrgb8888-mmap-cpu-ytiled.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw: [INCOMPLETE][68] ([i915#61]) -> [PASS][69]
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-hsw5/igt@kms_flip@flip-vs-suspend-interruptible.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-hsw4/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-skl: [FAIL][70] ([i915#34]) -> [PASS][71]
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl9/igt@kms_flip@plain-flip-fb-recreate-interruptible.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl7/igt@kms_flip@plain-flip-fb-recreate-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-gtt:
- shard-skl: [FAIL][72] ([i915#49]) -> [PASS][73]
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl9/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-gtt.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl10/igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-shrfb-draw-mmap-gtt.html
* igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl: [INCOMPLETE][74] ([i915#123] / [i915#69]) -> [PASS][75]
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl4/igt@kms_frontbuffer_tracking@psr-suspend.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl6/igt@kms_frontbuffer_tracking@psr-suspend.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [FAIL][76] ([i915#1188]) -> [PASS][77]
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl4/igt@kms_hdr@bpc-switch-dpms.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [FAIL][78] ([fdo#108145]) -> [PASS][79] +2 similar issues
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-skl5/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [SKIP][80] ([fdo#109441]) -> [PASS][81] +2 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb6/igt@kms_psr@psr2_suspend.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb2/igt@kms_psr@psr2_suspend.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][82] ([i915#31]) -> [PASS][83]
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-apl2/igt@kms_setmode@basic.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-apl1/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-apl: [DMESG-WARN][84] ([i915#180]) -> [PASS][85] +2 similar issues
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-apl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-apl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
#### Warnings ####
* igt@gem_ctx_persistence@close-replace-race:
- shard-kbl: [INCOMPLETE][86] ([i915#1402]) -> [TIMEOUT][87] ([i915#1340])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-kbl4/igt@gem_ctx_persistence@close-replace-race.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-kbl2/igt@gem_ctx_persistence@close-replace-race.html
* igt@gem_linear_blits@normal:
- shard-apl: [TIMEOUT][88] ([i915#1322]) -> [TIMEOUT][89] ([fdo#111732] / [i915#1322])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-apl3/igt@gem_linear_blits@normal.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-apl3/igt@gem_linear_blits@normal.html
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-iclb: [SKIP][90] ([i915#588]) -> [SKIP][91] ([i915#658])
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-iclb5/igt@i915_pm_dc@dc3co-vpb-simulation.html
* igt@runner@aborted:
- shard-kbl: ([FAIL][92], [FAIL][93]) ([i915#1389] / [i915#1402] / [i915#92]) -> [FAIL][94] ([i915#92])
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-kbl4/igt@runner@aborted.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8121/shard-kbl4/igt@runner@aborted.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16933/shard-kbl7/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#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#110841]: https://bugs.freedesktop.org/show_bug.cgi?id=110841
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111732]: https://bugs.freedesktop.org/show_bug.cgi?id=111732
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#123]: https://gitlab.freedesktop.org/drm/intel/issues/123
[i915#1322]: https://gitlab.freedesktop.org/drm/intel/issues/1322
[i915#1340]: https://gitlab.freedesktop.org/drm/intel/issues/1340
[i915#1389]: https://gitlab.freedesktop.org/drm/intel/issues/1389
[i915#1402]: https://gitlab.freedesktop.org/drm/intel/issues/1402
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#300]: https://gitlab.freedesktop.org/drm/intel/issues/300
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
[i915#413]: https://gitlab.freedesktop.org/drm/intel/issues/413
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#52]: https://gitlab.freedesktop.org/drm/intel/issues/52
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#58]: https://gitlab.freedesktop.org/drm/intel/issues/58
[i915#588]: https://gitlab.freedesktop.org/drm/intel/issues/588
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_8121 -> Patchwork_16933
CI-20190529: 20190529
CI_DRM_8121: c2e15accdf0c2b6e8b766659acc8159dc19c8869 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5505: 8973d811f3fdfb4ace4aabab2095ce0309881648 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16933: 76d4a408c88bce5a8974c49df75fc8cca6879421 @ 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_16933/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-10 18:25 ` Ville Syrjälä
2020-03-10 19:13 ` Takashi Iwai
@ 2020-03-12 17:27 ` Kai Vehmanen
2020-03-12 17:48 ` Ville Syrjälä
2020-03-12 17:50 ` Ville Syrjälä
1 sibling, 2 replies; 23+ messages in thread
From: Kai Vehmanen @ 2020-03-12 17:27 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Takashi Iwai, intel-gfx
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]
Hey,
On Tue, 10 Mar 2020, Ville Syrjälä wrote:
> On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
>> On Tue, 10 Mar 2020, Ville Syrjälä wrote:
>>> audio at init time. And we could maybe try to remove the modeset from the
>>> put_power() so that at least if you get a blink it's just the one. I did
>>
>> Hmm, this is interesting and maybe a better compromise for the in-between
>> generations. Could it be as simple as not setting
>
> The logic around the cdclk computation is still a bit messy.
>
> First draft of just doing the lazy force_min_cdclk reduction in put_power():
> git://github.com/vsyrjala/linux.git no_cdclk_in_audio_put_power
>
> Very lightly smoke tested, but not sure if it achieves anything useful :P
I tested this today and no issues found. I can see clock bumped if there
is audio activity, but clock is kept after audio goes back to sleep.
But then e.g. at next display-off timeout, clk is brought back down.
So works as expected.
But, but, then I also tested...
>> One problematic scenario that this doesn't cover:
>> - a single display is used (at low cdclk), and
>> - audio block goes to runtime suspend while display stays up.
>>
>> Upon resume (for e.g. UI notification sound), audio will initialize the
>> HDA bus and call get_power() on i915, even if the notification goes to
Now actually hitting this requires some effort. On most systems I tried,
with display active, the clock will stay above the limit for other
reasons, but yup, when this happens, it is pretty, pretty bad.
Your no_cdclk_in_audio_put_power patch does reduce the level of annoyance
also in this case -- you only get one flash instead of two. But does not
seem acceptable still. If you happen to have a system where the conditions
are met, then this happens all the time. In case of UI notification sounds
being the trigger, we could consider the visual flash as a feature, but
probably not widely appreciated. ;) .. and especially as you cannot turn
it off.
So I think this starts to look that we should move calling glk_force_audio
to bind/unbind pair. I can make a patch for this.
>> I just also noted if we keep the glk_force_audio function, we need to get
>> rid of the hardcoded 96Mhz BCLK value that is used now, and instead dig up
>
> I think when I last complained about the assumed 96 MHz BCLK
> people said "48 MHz never happens". But I guess it can be made
> to happen?
Indeed the recommendation still is 96 Mhz and that will be the dominant
value, but 48 Mhz is still an option. To keep the system open for
configurability, I think the bind/unbind restriction should take the
effective BCLK value into account. So if 48 Mhz is chosen, you get the
benefits with just a BIOS change and no need to muck around the
kernel as well.
Br, Kai
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-12 17:27 ` Kai Vehmanen
@ 2020-03-12 17:48 ` Ville Syrjälä
2020-03-12 17:50 ` Ville Syrjälä
1 sibling, 0 replies; 23+ messages in thread
From: Ville Syrjälä @ 2020-03-12 17:48 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: Takashi Iwai, intel-gfx
On Thu, Mar 12, 2020 at 07:27:58PM +0200, Kai Vehmanen wrote:
> Hey,
>
> On Tue, 10 Mar 2020, Ville Syrjälä wrote:
>
> > On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
> >> On Tue, 10 Mar 2020, Ville Syrjälä wrote:
> >>> audio at init time. And we could maybe try to remove the modeset from the
> >>> put_power() so that at least if you get a blink it's just the one. I did
> >>
> >> Hmm, this is interesting and maybe a better compromise for the in-between
> >> generations. Could it be as simple as not setting
> >
> > The logic around the cdclk computation is still a bit messy.
> >
> > First draft of just doing the lazy force_min_cdclk reduction in put_power():
> > git://github.com/vsyrjala/linux.git no_cdclk_in_audio_put_power
> >
> > Very lightly smoke tested, but not sure if it achieves anything useful :P
>
> I tested this today and no issues found. I can see clock bumped if there
> is audio activity, but clock is kept after audio goes back to sleep.
> But then e.g. at next display-off timeout, clk is brought back down.
> So works as expected.
>
> But, but, then I also tested...
>
> >> One problematic scenario that this doesn't cover:
> >> - a single display is used (at low cdclk), and
> >> - audio block goes to runtime suspend while display stays up.
> >>
> >> Upon resume (for e.g. UI notification sound), audio will initialize the
> >> HDA bus and call get_power() on i915, even if the notification goes to
>
> Now actually hitting this requires some effort. On most systems I tried,
> with display active, the clock will stay above the limit for other
> reasons, but yup, when this happens, it is pretty, pretty bad.
>
> Your no_cdclk_in_audio_put_power patch does reduce the level of annoyance
> also in this case -- you only get one flash instead of two. But does not
> seem acceptable still. If you happen to have a system where the conditions
> are met, then this happens all the time. In case of UI notification sounds
> being the trigger, we could consider the visual flash as a feature, but
> probably not widely appreciated. ;) .. and especially as you cannot turn
> it off.
>
> So I think this starts to look that we should move calling glk_force_audio
> to bind/unbind pair. I can make a patch for this.
>
> >> I just also noted if we keep the glk_force_audio function, we need to get
> >> rid of the hardcoded 96Mhz BCLK value that is used now, and instead dig up
> >
> > I think when I last complained about the assumed 96 MHz BCLK
> > people said "48 MHz never happens". But I guess it can be made
> > to happen?
>
> Indeed the recommendation still is 96 Mhz and that will be the dominant
> value, but 48 Mhz is still an option. To keep the system open for
> configurability, I think the bind/unbind restriction should take the
> effective BCLK value into account.
IMO no. We should just figure out what the bclk is and let the display
driver enfoce the 2xbclk requirement on its own regardless of the bclk
frequency. I don't want the audio driver start assuming cdclk can
never go below the 2*48MHz magic limit.
I think there was a register somewhere where we could read the BCLK.
And if not we should extend the interface between the drivers so the
audio driver can pass in that information.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-12 17:27 ` Kai Vehmanen
2020-03-12 17:48 ` Ville Syrjälä
@ 2020-03-12 17:50 ` Ville Syrjälä
2020-03-13 14:54 ` Kai Vehmanen
1 sibling, 1 reply; 23+ messages in thread
From: Ville Syrjälä @ 2020-03-12 17:50 UTC (permalink / raw)
To: Kai Vehmanen; +Cc: Takashi Iwai, intel-gfx
On Thu, Mar 12, 2020 at 07:27:58PM +0200, Kai Vehmanen wrote:
> Hey,
>
> On Tue, 10 Mar 2020, Ville Syrjälä wrote:
>
> > On Tue, Mar 10, 2020 at 07:18:58PM +0200, Kai Vehmanen wrote:
> >> On Tue, 10 Mar 2020, Ville Syrjälä wrote:
> >>> audio at init time. And we could maybe try to remove the modeset from the
> >>> put_power() so that at least if you get a blink it's just the one. I did
> >>
> >> Hmm, this is interesting and maybe a better compromise for the in-between
> >> generations. Could it be as simple as not setting
> >
> > The logic around the cdclk computation is still a bit messy.
> >
> > First draft of just doing the lazy force_min_cdclk reduction in put_power():
> > git://github.com/vsyrjala/linux.git no_cdclk_in_audio_put_power
> >
> > Very lightly smoke tested, but not sure if it achieves anything useful :P
>
> I tested this today and no issues found. I can see clock bumped if there
> is audio activity, but clock is kept after audio goes back to sleep.
> But then e.g. at next display-off timeout, clk is brought back down.
> So works as expected.
>
> But, but, then I also tested...
>
> >> One problematic scenario that this doesn't cover:
> >> - a single display is used (at low cdclk), and
> >> - audio block goes to runtime suspend while display stays up.
> >>
> >> Upon resume (for e.g. UI notification sound), audio will initialize the
> >> HDA bus and call get_power() on i915, even if the notification goes to
>
> Now actually hitting this requires some effort. On most systems I tried,
> with display active, the clock will stay above the limit for other
> reasons, but yup, when this happens, it is pretty, pretty bad.
>
> Your no_cdclk_in_audio_put_power patch does reduce the level of annoyance
> also in this case -- you only get one flash instead of two. But does not
> seem acceptable still. If you happen to have a system where the conditions
> are met, then this happens all the time. In case of UI notification sounds
> being the trigger, we could consider the visual flash as a feature, but
> probably not widely appreciated. ;) .. and especially as you cannot turn
> it off.
>
> So I think this starts to look that we should move calling glk_force_audio
> to bind/unbind pair. I can make a patch for this.
That would stop us from doing dynamic cdclk changes once we get the hw
that can do that properly. Rather I think I'd just hardcode the 2xbclk
requirement in i915 for the platforms that suck.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only
2020-03-12 17:50 ` Ville Syrjälä
@ 2020-03-13 14:54 ` Kai Vehmanen
0 siblings, 0 replies; 23+ messages in thread
From: Kai Vehmanen @ 2020-03-13 14:54 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Takashi Iwai, intel-gfx
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
Hey,
On Thu, 12 Mar 2020, Ville Syrjälä wrote:
> On Thu, Mar 12, 2020 at 07:27:58PM +0200, Kai Vehmanen wrote:
>> So I think this starts to look that we should move calling glk_force_audio
>> to bind/unbind pair. I can make a patch for this.
>
> That would stop us from doing dynamic cdclk changes once we get the hw
> that can do that properly. Rather I think I'd just hardcode the 2xbclk
> requirement in i915 for the platforms that suck.
well, you can always code in both places -- i.e. have the clock
constraints set up at bind() for older (the current) platforms, and have a
different callplace in get_power() for newer platforms. This code is
anyways conditional on the hardware that is used.
I now send a patch implementing this, plus code to at runtime figure
out the effective BCLK, to the list. Please have a look at comment.
Br, Kai
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-03-13 14:54 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-31 14:00 [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Kai Vehmanen
2019-12-31 14:38 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2) Patchwork
2019-12-31 20:06 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-01-02 18:28 ` [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only Rodrigo Vivi
2020-01-03 15:28 ` Kai Vehmanen
2020-01-06 16:49 ` Matt Roper
2020-03-06 16:45 ` Kai Vehmanen
2020-03-09 10:54 ` Takashi Iwai
2020-03-10 11:20 ` Kai Vehmanen
2020-03-10 13:41 ` Ville Syrjälä
2020-03-10 17:18 ` Kai Vehmanen
2020-03-10 18:25 ` Ville Syrjälä
2020-03-10 19:13 ` Takashi Iwai
2020-03-11 12:16 ` Kai Vehmanen
[not found] ` <s5hk13q7uf6.wl-tiwai@suse.de>
2020-03-11 17:04 ` Kai Vehmanen
2020-03-11 17:21 ` Takashi Iwai
2020-03-12 17:27 ` Kai Vehmanen
2020-03-12 17:48 ` Ville Syrjälä
2020-03-12 17:50 ` Ville Syrjälä
2020-03-13 14:54 ` Kai Vehmanen
2020-03-11 20:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3) Patchwork
2020-03-11 20:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-12 13:05 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).