[Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2)

[Patchwork]

== 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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev2)

[Patchwork]

== 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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Rodrigo Vivi]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Matt Roper]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Takashi Iwai]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Ville Syrjälä]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

[-- 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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Ville Syrjälä]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Takashi Iwai]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

[-- 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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Takashi Iwai]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

[-- 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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Ville Syrjälä]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Ville Syrjälä]

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only

[Kai Vehmanen]

[-- 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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)

[Patchwork]

== 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)

[Patchwork]

== 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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Limit audio CDCLK>=2*BCLK constraint back to GLK only (rev3)

[Patchwork]

== 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