* [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-10 0:14 ` Manasi Navare
0 siblings, 0 replies; 18+ messages in thread
From: Manasi Navare @ 2021-02-10 0:14 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: Daniel Vetter
This reverts commit fb6473a48b635c55d04eb94e579eede52ef39550.
These additional checks added to avoid EBUSY give unnecessary WARN_ON
in case of big joiner used in i915 in which case even if the modeset
is requested on a single pipe, internally another consecutive
pipe is stolen and used to drive half of the transcoder timings.
So in this case it is expected that requested crtc and affected crtcs
do not match. Hence the added WARN ON becomes irrelevant.
But there is no easy solution to get the bigjoiner information
here at drm level. So for now revert this until we work out
a better solution.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
---
drivers/gpu/drm/drm_atomic.c | 29 -----------------------------
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b1efa9322be2..48b2262d69f6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -320,10 +320,6 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
* needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
- * WARNING: Drivers may only add new CRTC states to a @state if
- * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
- * not created by userspace through an IOCTL call.
- *
* Returns:
*
* Either the allocated state or the error code encoded into the pointer. When
@@ -1306,15 +1302,10 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
- unsigned requested_crtc = 0;
- unsigned affected_crtc = 0;
int i, ret = 0;
DRM_DEBUG_ATOMIC("checking %p\n", state);
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
- requested_crtc |= drm_crtc_mask(crtc);
-
for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1362,26 +1353,6 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
- affected_crtc |= drm_crtc_mask(crtc);
-
- /*
- * For commits that allow modesets drivers can add other CRTCs to the
- * atomic commit, e.g. when they need to reallocate global resources.
- * This can cause spurious EBUSY, which robs compositors of a very
- * effective sanity check for their drawing loop. Therefor only allow
- * drivers to add unrelated CRTC states for modeset commits.
- *
- * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
- * so compositors know what's going on.
- */
- if (affected_crtc != requested_crtc) {
- DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, affected 0x%0x\n",
- requested_crtc, affected_crtc);
- WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n",
- requested_crtc, affected_crtc);
- }
-
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
2.19.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 0:14 ` [Intel-gfx] " Manasi Navare
(?)
@ 2021-02-10 2:05 ` Patchwork
-1 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2021-02-10 2:05 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 3013 bytes --]
== Series Details ==
Series: Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
URL : https://patchwork.freedesktop.org/series/86927/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9754 -> Patchwork_19647
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/index.html
Known issues
------------
Here are the changes found in Patchwork_19647 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@debugfs_test@read_all_entries:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-tgl-y/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@sanitycheck:
- fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2605])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-kbl-7500u/igt@i915_selftest@live@sanitycheck.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-kbl-7500u/igt@i915_selftest@live@sanitycheck.html
#### Possible fixes ####
* igt@gem_flink_basic@bad-flink:
- fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [FAIL][7] ([i915#2203] / [i915#579]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
Participating hosts (43 -> 38)
------------------------------
Missing (5): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_9754 -> Patchwork_19647
CI-20190529: 20190529
CI_DRM_9754: 115d43f1936b9d5da493e4ab324fada8938be783 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19647: 064f0782a30808570873507b3086843c2b561329 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
064f0782a308 Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/index.html
[-- Attachment #1.2: Type: text/html, Size: 3793 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread* [Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 0:14 ` [Intel-gfx] " Manasi Navare
(?)
(?)
@ 2021-02-10 6:19 ` Patchwork
-1 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2021-02-10 6:19 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 30293 bytes --]
== Series Details ==
Series: Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
URL : https://patchwork.freedesktop.org/series/86927/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9754_full -> Patchwork_19647_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_19647_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-kbl: NOTRUN -> [DMESG-WARN][1] ([i915#3002])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl6/igt@gem_create@create-massive.html
- shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#3002])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl4/igt@gem_create@create-massive.html
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#1037] / [i915#180])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl4/igt@gem_eio@in-flight-suspend.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl7/igt@gem_eio@in-flight-suspend.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#3063])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb6/igt@gem_eio@unwedge-stress.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb3/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl4/igt@gem_exec_fair@basic-none@vecs0.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@gem_exec_fair@basic-none@vecs0.html
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl2/igt@gem_exec_fair@basic-none@vecs0.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@gem_exec_fair@basic-none@vecs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb7/igt@gem_exec_fair@basic-pace@vcs0.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb6/igt@gem_exec_fair@basic-pace@vcs0.html
* igt@gem_exec_reloc@basic-parallel:
- shard-apl: NOTRUN -> [TIMEOUT][13] ([i915#1729])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@gem_exec_reloc@basic-parallel.html
* igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2389]) +1 similar issue
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb1/igt@gem_exec_reloc@basic-wide-active@vcs1.html
* igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1610])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl6/igt@gem_exec_schedule@u-fairslice@rcs0.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl7/igt@gem_exec_schedule@u-fairslice@rcs0.html
- shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb7/igt@gem_exec_schedule@u-fairslice@rcs0.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb6/igt@gem_exec_schedule@u-fairslice@rcs0.html
* igt@gem_userptr_blits@input-checking:
- shard-skl: NOTRUN -> [DMESG-WARN][19] ([i915#3002])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl6/igt@gem_userptr_blits@input-checking.html
* igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271]) +45 similar issues
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@gem_userptr_blits@mmap-offset-invalidate-active@wb.html
* igt@gem_vm_create@destroy-race:
- shard-tglb: [PASS][21] -> [FAIL][22] ([i915#2822])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb2/igt@gem_vm_create@destroy-race.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb7/igt@gem_vm_create@destroy-race.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][23] -> [FAIL][24] ([i915#454])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb7/igt@i915_pm_dc@dc6-psr.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb6/igt@i915_pm_dc@dc6-psr.html
* igt@i915_selftest@live@client:
- shard-glk: [PASS][25] -> [DMESG-FAIL][26] ([i915#3047])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-glk9/igt@i915_selftest@live@client.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-glk7/igt@i915_selftest@live@client.html
* igt@i915_suspend@sysfs-reader:
- shard-apl: [PASS][27] -> [DMESG-WARN][28] ([i915#180]) +2 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl6/igt@i915_suspend@sysfs-reader.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl6/igt@i915_suspend@sysfs-reader.html
* igt@kms_big_fb@linear-16bpp-rotate-90:
- shard-apl: NOTRUN -> [SKIP][29] ([fdo#109271]) +103 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl4/igt@kms_big_fb@linear-16bpp-rotate-90.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-270:
- shard-tglb: NOTRUN -> [SKIP][30] ([fdo#111615])
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb6/igt@kms_big_fb@yf-tiled-64bpp-rotate-270.html
* igt@kms_big_joiner@invalid-modeset:
- shard-kbl: NOTRUN -> [SKIP][31] ([fdo#109271] / [i915#2705])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@kms_big_joiner@invalid-modeset.html
- shard-apl: NOTRUN -> [SKIP][32] ([fdo#109271] / [i915#2705])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl8/igt@kms_big_joiner@invalid-modeset.html
* igt@kms_chamelium@dp-mode-timings:
- shard-apl: NOTRUN -> [SKIP][33] ([fdo#109271] / [fdo#111827]) +15 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl4/igt@kms_chamelium@dp-mode-timings.html
* igt@kms_chamelium@hdmi-hpd-storm-disable:
- shard-kbl: NOTRUN -> [SKIP][34] ([fdo#109271] / [fdo#111827]) +4 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@kms_chamelium@hdmi-hpd-storm-disable.html
* igt@kms_color@pipe-c-ctm-blue-to-red:
- shard-skl: [PASS][35] -> [DMESG-WARN][36] ([i915#1982]) +2 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl2/igt@kms_color@pipe-c-ctm-blue-to-red.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl8/igt@kms_color@pipe-c-ctm-blue-to-red.html
* igt@kms_color_chamelium@pipe-c-ctm-negative:
- shard-skl: NOTRUN -> [SKIP][37] ([fdo#109271] / [fdo#111827]) +5 similar issues
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl8/igt@kms_color_chamelium@pipe-c-ctm-negative.html
* igt@kms_color_chamelium@pipe-d-ctm-limited-range:
- shard-tglb: NOTRUN -> [SKIP][38] ([fdo#109284] / [fdo#111827]) +1 similar issue
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb7/igt@kms_color_chamelium@pipe-d-ctm-limited-range.html
* igt@kms_content_protection@lic:
- shard-apl: NOTRUN -> [TIMEOUT][39] ([i915#1319])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl8/igt@kms_content_protection@lic.html
- shard-kbl: NOTRUN -> [TIMEOUT][40] ([i915#1319])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@kms_content_protection@lic.html
* igt@kms_cursor_crc@pipe-b-cursor-256x85-random:
- shard-skl: [PASS][41] -> [FAIL][42] ([i915#54]) +6 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl10/igt@kms_cursor_crc@pipe-b-cursor-256x85-random.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl10/igt@kms_cursor_crc@pipe-b-cursor-256x85-random.html
* igt@kms_cursor_crc@pipe-b-cursor-512x170-random:
- shard-tglb: NOTRUN -> [SKIP][43] ([fdo#109279])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb7/igt@kms_cursor_crc@pipe-b-cursor-512x170-random.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-sliding:
- shard-skl: NOTRUN -> [FAIL][44] ([i915#54])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl9/igt@kms_cursor_crc@pipe-c-cursor-64x21-sliding.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][45] -> [FAIL][46] ([i915#79])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-glk9/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-tglb: [PASS][47] -> [FAIL][48] ([i915#2598])
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb8/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@b-dp1:
- shard-apl: NOTRUN -> [DMESG-WARN][49] ([i915#180])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@kms_flip@flip-vs-suspend-interruptible@b-dp1.html
* igt@kms_flip@flip-vs-suspend@c-edp1:
- shard-skl: [PASS][50] -> [INCOMPLETE][51] ([i915#198])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl1/igt@kms_flip@flip-vs-suspend@c-edp1.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl10/igt@kms_flip@flip-vs-suspend@c-edp1.html
* igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1:
- shard-skl: [PASS][52] -> [FAIL][53] ([i915#2122])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl9/igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl1/igt@kms_flip@plain-flip-ts-check-interruptible@a-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs:
- shard-kbl: NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#2672])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
- shard-apl: NOTRUN -> [SKIP][55] ([fdo#109271] / [i915#2672])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile:
- shard-skl: NOTRUN -> [FAIL][56] ([i915#2628])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-kbl: [PASS][57] -> [FAIL][58] ([i915#49])
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc.html
- shard-apl: [PASS][59] -> [FAIL][60] ([i915#49])
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-pwrite:
- shard-tglb: NOTRUN -> [SKIP][61] ([fdo#111825]) +4 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb6/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-onoff:
- shard-skl: NOTRUN -> [SKIP][62] ([fdo#109271]) +74 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl6/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-onoff.html
* igt@kms_pipe_crc_basic@read-crc-pipe-d:
- shard-kbl: NOTRUN -> [SKIP][63] ([fdo#109271] / [i915#533])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl1/igt@kms_pipe_crc_basic@read-crc-pipe-d.html
- shard-skl: NOTRUN -> [SKIP][64] ([fdo#109271] / [i915#533])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl8/igt@kms_pipe_crc_basic@read-crc-pipe-d.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl: [PASS][65] -> [DMESG-WARN][66] ([i915#180]) +3 similar issues
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl7/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-apl: NOTRUN -> [FAIL][67] ([fdo#108145] / [i915#265]) +1 similar issue
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-apl: NOTRUN -> [FAIL][68] ([i915#265])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl8/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
- shard-kbl: NOTRUN -> [FAIL][69] ([i915#265])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][70] -> [FAIL][71] ([fdo#108145] / [i915#265]) +1 similar issue
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl7/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: NOTRUN -> [FAIL][72] ([fdo#108145] / [i915#265]) +1 similar issue
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping:
- shard-apl: NOTRUN -> [SKIP][73] ([fdo#109271] / [i915#2733])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-c-scaler-with-clipping-clamping.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3:
- shard-apl: NOTRUN -> [SKIP][74] ([fdo#109271] / [i915#658]) +2 similar issues
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3.html
* igt@kms_psr2_su@frontbuffer:
- shard-skl: NOTRUN -> [SKIP][75] ([fdo#109271] / [i915#658]) +1 similar issue
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl8/igt@kms_psr2_su@frontbuffer.html
- shard-kbl: NOTRUN -> [SKIP][76] ([fdo#109271] / [i915#658]) +1 similar issue
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl1/igt@kms_psr2_su@frontbuffer.html
* igt@kms_psr@psr2_sprite_render:
- shard-iclb: [PASS][77] -> [SKIP][78] ([fdo#109441]) +1 similar issue
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb2/igt@kms_psr@psr2_sprite_render.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb1/igt@kms_psr@psr2_sprite_render.html
* igt@kms_vrr@flip-basic:
- shard-tglb: NOTRUN -> [SKIP][79] ([fdo#109502])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb7/igt@kms_vrr@flip-basic.html
* igt@perf@gen8-unprivileged-single-ctx-counters:
- shard-tglb: NOTRUN -> [SKIP][80] ([fdo#109289])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb7/igt@perf@gen8-unprivileged-single-ctx-counters.html
* igt@sysfs_clients@busy@bcs0:
- shard-kbl: [PASS][81] -> [FAIL][82] ([i915#3009])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl4/igt@sysfs_clients@busy@bcs0.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl7/igt@sysfs_clients@busy@bcs0.html
* igt@sysfs_heartbeat_interval@mixed@vecs0:
- shard-skl: NOTRUN -> [INCOMPLETE][83] ([i915#1731])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl1/igt@sysfs_heartbeat_interval@mixed@vecs0.html
#### Possible fixes ####
* igt@gem_eio@in-flight-contexts-immediate:
- shard-iclb: [TIMEOUT][84] -> [PASS][85]
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb1/igt@gem_eio@in-flight-contexts-immediate.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb5/igt@gem_eio@in-flight-contexts-immediate.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [FAIL][86] ([i915#2842]) -> [PASS][87]
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-glk2/igt@gem_exec_fair@basic-none@rcs0.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-glk5/igt@gem_exec_fair@basic-none@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [FAIL][88] ([i915#2842]) -> [PASS][89]
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl4/igt@gem_exec_fair@basic-none@vcs0.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@gem_exec_fair@basic-none@vcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-tglb: [FAIL][90] ([i915#2842]) -> [PASS][91]
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb7/igt@gem_exec_fair@basic-pace@vcs1.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb6/igt@gem_exec_fair@basic-pace@vcs1.html
* igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-tglb: [DMESG-WARN][92] ([i915#2803]) -> [PASS][93]
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb2/igt@gem_exec_schedule@u-fairslice@rcs0.html
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb7/igt@gem_exec_schedule@u-fairslice@rcs0.html
* igt@i915_suspend@sysfs-reader:
- shard-skl: [INCOMPLETE][94] ([i915#198]) -> [PASS][95]
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl7/igt@i915_suspend@sysfs-reader.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl6/igt@i915_suspend@sysfs-reader.html
* igt@kms_async_flips@test-time-stamp:
- shard-tglb: [FAIL][96] ([i915#2597]) -> [PASS][97]
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb5/igt@kms_async_flips@test-time-stamp.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb6/igt@kms_async_flips@test-time-stamp.html
* igt@kms_cursor_crc@pipe-b-cursor-128x128-random:
- shard-skl: [FAIL][98] ([i915#54]) -> [PASS][99] +10 similar issues
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl5/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl3/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-skl: [FAIL][100] ([i915#2346]) -> [PASS][101]
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl7/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl5/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [INCOMPLETE][102] ([i915#180]) -> [PASS][103]
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl3/igt@kms_fbcon_fbt@fbc-suspend.html
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1:
- shard-skl: [FAIL][104] ([i915#79]) -> [PASS][105]
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1.html
* igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2:
- shard-glk: [FAIL][106] ([i915#79]) -> [PASS][107]
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-glk1/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2.html
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-glk3/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [DMESG-WARN][108] ([i915#180]) -> [PASS][109] +4 similar issues
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-suspend.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-suspend.html
- shard-apl: [DMESG-WARN][110] ([i915#180]) -> [PASS][111] +4 similar issues
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl6/igt@kms_frontbuffer_tracking@fbc-suspend.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl4/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [FAIL][112] ([i915#1188]) -> [PASS][113] +1 similar issue
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl10/igt@kms_hdr@bpc-switch-suspend.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl10/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: [SKIP][114] ([fdo#109441]) -> [PASS][115] +1 similar issue
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb8/igt@kms_psr@psr2_cursor_blt.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [DMESG-WARN][116] ([i915#180] / [i915#295]) -> [PASS][117]
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl1/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* {igt@sysfs_clients@recycle-many}:
- shard-iclb: [FAIL][118] ([i915#3028]) -> [PASS][119]
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb3/igt@sysfs_clients@recycle-many.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb4/igt@sysfs_clients@recycle-many.html
* igt@sysfs_clients@sema-10@rcs0:
- shard-apl: [SKIP][120] ([fdo#109271] / [i915#3026]) -> [PASS][121]
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl8/igt@sysfs_clients@sema-10@rcs0.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl4/igt@sysfs_clients@sema-10@rcs0.html
* igt@sysfs_clients@sema-25@vecs0:
- shard-skl: [SKIP][122] ([fdo#109271]) -> [PASS][123] +1 similar issue
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl7/igt@sysfs_clients@sema-25@vecs0.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl10/igt@sysfs_clients@sema-25@vecs0.html
#### Warnings ####
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][124] ([i915#2681] / [i915#2684]) -> [WARN][125] ([i915#1804] / [i915#2684])
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb1/igt@i915_pm_rc6_residency@rc6-fence.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb4/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: [WARN][126] ([i915#1804] / [i915#2684]) -> [WARN][127] ([i915#2681] / [i915#2684])
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb7/igt@i915_pm_rc6_residency@rc6-idle.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb8/igt@i915_pm_rc6_residency@rc6-idle.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: [DMESG-FAIL][128] -> [FAIL][129] ([i915#2521])
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-skl9/igt@kms_async_flips@alternate-sync-async-flip.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl1/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-5:
- shard-iclb: [SKIP][130] ([i915#2920]) -> [SKIP][131] ([i915#658]) +1 similar issue
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb2/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-5.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb1/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-5.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3:
- shard-iclb: [SKIP][132] ([i915#658]) -> [SKIP][133] ([i915#2920]) +1 similar issue
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb4/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb2/igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area-3.html
* igt@runner@aborted:
- shard-kbl: ([FAIL][134], [FAIL][135], [FAIL][136], [FAIL][137], [FAIL][138], [FAIL][139], [FAIL][140], [FAIL][141]) ([fdo#109271] / [i915#1436] / [i915#1814] / [i915#2295] / [i915#2505] / [i915#3002] / [i915#602]) -> ([FAIL][142], [FAIL][143], [FAIL][144], [FAIL][145], [FAIL][146], [FAIL][147], [FAIL][148], [FAIL][149], [FAIL][150]) ([i915#1436] / [i915#1814] / [i915#2295] / [i915#2505] / [i915#3002] / [i915#602])
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl6/igt@runner@aborted.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl6/igt@runner@aborted.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl6/igt@runner@aborted.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl2/igt@runner@aborted.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl3/igt@runner@aborted.html
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl6/igt@runner@aborted.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl7/igt@runner@aborted.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl6/igt@runner@aborted.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl2/igt@runner@aborted.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl7/igt@runner@aborted.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl7/igt@runner@aborted.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl7/igt@runner@aborted.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl2/igt@runner@aborted.html
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl6/igt@runner@aborted.html
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl2/igt@runner@aborted.html
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl6/igt@runner@aborted.html
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@runner@aborted.html
- shard-iclb: ([FAIL][151], [FAIL][152], [FAIL][153]) ([i915#2295] / [i915#2724] / [i915#3002]) -> ([FAIL][154], [FAIL][155], [FAIL][156], [FAIL][157]) ([i915#2295] / [i915#2426] / [i915#2724] / [i915#3002])
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb8/igt@runner@aborted.html
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb6/igt@runner@aborted.html
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb6/igt@runner@aborted.html
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb4/igt@runner@aborted.html
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb1/igt@runner@aborted.html
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb6/igt@runner@aborted.html
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb6/igt@runner@aborted.html
- shard-apl: ([FAIL][158], [FAIL][159], [FAIL][160], [FAIL][161], [FAIL][162], [FAIL][163], [FAIL][164], [FAIL][165]) ([fdo#109271] / [i915#1814] / [i915#2295] / [i915#3002]) -> ([FAIL][166], [FAIL][167], [FAIL][168], [FAIL][169], [FAIL][170], [FAIL][171], [FAIL][172]) ([fdo#109271]
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/index.html
[-- Attachment #1.2: Type: text/html, Size: 33720 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 0:14 ` [Intel-gfx] " Manasi Navare
@ 2021-02-10 13:16 ` Daniel Vetter
-1 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-02-10 13:16 UTC (permalink / raw)
To: Manasi Navare; +Cc: Daniel Vetter, intel-gfx, dri-devel
On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> This reverts commit fb6473a48b635c55d04eb94e579eede52ef39550.
>
> These additional checks added to avoid EBUSY give unnecessary WARN_ON
> in case of big joiner used in i915 in which case even if the modeset
> is requested on a single pipe, internally another consecutive
> pipe is stolen and used to drive half of the transcoder timings.
> So in this case it is expected that requested crtc and affected crtcs
> do not match. Hence the added WARN ON becomes irrelevant.
> But there is no easy solution to get the bigjoiner information
> here at drm level. So for now revert this until we work out
> a better solution.
>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Nope. We can maybe rework this so that i915 can do stuff under the hood,
but wrt uapi this was the thing we discussed with compositors. Without
such a guarantee atomic is defacto broken from a compositor pov.
This WARN_ON is not unecessary, compositor people really do not want the
kernel to throw around spurious EBUSY they have no visibility into.
Please also cc all the compositor people from my original patch if you
change anything in this area.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 29 -----------------------------
> 1 file changed, 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b1efa9322be2..48b2262d69f6 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -320,10 +320,6 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> * needed. It will also grab the relevant CRTC lock to make sure that the state
> * is consistent.
> *
> - * WARNING: Drivers may only add new CRTC states to a @state if
> - * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
> - * not created by userspace through an IOCTL call.
> - *
> * Returns:
> *
> * Either the allocated state or the error code encoded into the pointer. When
> @@ -1306,15 +1302,10 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> struct drm_crtc_state *new_crtc_state;
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> - unsigned requested_crtc = 0;
> - unsigned affected_crtc = 0;
> int i, ret = 0;
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> - requested_crtc |= drm_crtc_mask(crtc);
> -
> for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
> ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> if (ret) {
> @@ -1362,26 +1353,6 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> }
> }
>
> - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> - affected_crtc |= drm_crtc_mask(crtc);
> -
> - /*
> - * For commits that allow modesets drivers can add other CRTCs to the
> - * atomic commit, e.g. when they need to reallocate global resources.
> - * This can cause spurious EBUSY, which robs compositors of a very
> - * effective sanity check for their drawing loop. Therefor only allow
> - * drivers to add unrelated CRTC states for modeset commits.
> - *
> - * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> - * so compositors know what's going on.
> - */
> - if (affected_crtc != requested_crtc) {
> - DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, affected 0x%0x\n",
> - requested_crtc, affected_crtc);
> - WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n",
> - requested_crtc, affected_crtc);
> - }
> -
> return 0;
> }
> EXPORT_SYMBOL(drm_atomic_check_only);
> --
> 2.19.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-10 13:16 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-02-10 13:16 UTC (permalink / raw)
To: Manasi Navare; +Cc: Daniel Vetter, intel-gfx, dri-devel
On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> This reverts commit fb6473a48b635c55d04eb94e579eede52ef39550.
>
> These additional checks added to avoid EBUSY give unnecessary WARN_ON
> in case of big joiner used in i915 in which case even if the modeset
> is requested on a single pipe, internally another consecutive
> pipe is stolen and used to drive half of the transcoder timings.
> So in this case it is expected that requested crtc and affected crtcs
> do not match. Hence the added WARN ON becomes irrelevant.
> But there is no easy solution to get the bigjoiner information
> here at drm level. So for now revert this until we work out
> a better solution.
>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Nope. We can maybe rework this so that i915 can do stuff under the hood,
but wrt uapi this was the thing we discussed with compositors. Without
such a guarantee atomic is defacto broken from a compositor pov.
This WARN_ON is not unecessary, compositor people really do not want the
kernel to throw around spurious EBUSY they have no visibility into.
Please also cc all the compositor people from my original patch if you
change anything in this area.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 29 -----------------------------
> 1 file changed, 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index b1efa9322be2..48b2262d69f6 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -320,10 +320,6 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
> * needed. It will also grab the relevant CRTC lock to make sure that the state
> * is consistent.
> *
> - * WARNING: Drivers may only add new CRTC states to a @state if
> - * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
> - * not created by userspace through an IOCTL call.
> - *
> * Returns:
> *
> * Either the allocated state or the error code encoded into the pointer. When
> @@ -1306,15 +1302,10 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> struct drm_crtc_state *new_crtc_state;
> struct drm_connector *conn;
> struct drm_connector_state *conn_state;
> - unsigned requested_crtc = 0;
> - unsigned affected_crtc = 0;
> int i, ret = 0;
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> - requested_crtc |= drm_crtc_mask(crtc);
> -
> for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
> ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
> if (ret) {
> @@ -1362,26 +1353,6 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> }
> }
>
> - for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> - affected_crtc |= drm_crtc_mask(crtc);
> -
> - /*
> - * For commits that allow modesets drivers can add other CRTCs to the
> - * atomic commit, e.g. when they need to reallocate global resources.
> - * This can cause spurious EBUSY, which robs compositors of a very
> - * effective sanity check for their drawing loop. Therefor only allow
> - * drivers to add unrelated CRTC states for modeset commits.
> - *
> - * FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
> - * so compositors know what's going on.
> - */
> - if (affected_crtc != requested_crtc) {
> - DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x, affected 0x%0x\n",
> - requested_crtc, affected_crtc);
> - WARN(!state->allow_modeset, "adding CRTC not allowed without modesets: requested 0x%x, affected 0x%0x\n",
> - requested_crtc, affected_crtc);
> - }
> -
> return 0;
> }
> EXPORT_SYMBOL(drm_atomic_check_only);
> --
> 2.19.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 13:16 ` Daniel Vetter
@ 2021-02-10 13:38 ` Simon Ser
-1 siblings, 0 replies; 18+ messages in thread
From: Simon Ser @ 2021-02-10 13:38 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Manasi Navare, Daniel Vetter, intel-gfx, dri-devel
On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
>
> > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > in case of big joiner used in i915 in which case even if the modeset
> > is requested on a single pipe, internally another consecutive
> > pipe is stolen and used to drive half of the transcoder timings.
> > So in this case it is expected that requested crtc and affected crtcs
> > do not match. Hence the added WARN ON becomes irrelevant.
The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
then the driver is allowed to steal an unrelated pipe.
Maybe i915 is stealing a pipe without allow_modeset?
> Nope. We can maybe rework this so that i915 can do stuff under the hood,
> but wrt uapi this was the thing we discussed with compositors. Without
> such a guarantee atomic is defacto broken from a compositor pov.
Agreed.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-10 13:38 ` Simon Ser
0 siblings, 0 replies; 18+ messages in thread
From: Simon Ser @ 2021-02-10 13:38 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, intel-gfx, dri-devel
On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
>
> > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > in case of big joiner used in i915 in which case even if the modeset
> > is requested on a single pipe, internally another consecutive
> > pipe is stolen and used to drive half of the transcoder timings.
> > So in this case it is expected that requested crtc and affected crtcs
> > do not match. Hence the added WARN ON becomes irrelevant.
The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
then the driver is allowed to steal an unrelated pipe.
Maybe i915 is stealing a pipe without allow_modeset?
> Nope. We can maybe rework this so that i915 can do stuff under the hood,
> but wrt uapi this was the thing we discussed with compositors. Without
> such a guarantee atomic is defacto broken from a compositor pov.
Agreed.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 13:38 ` Simon Ser
@ 2021-02-10 15:07 ` Ville Syrjälä
-1 siblings, 0 replies; 18+ messages in thread
From: Ville Syrjälä @ 2021-02-10 15:07 UTC (permalink / raw)
To: Simon Ser; +Cc: Daniel Vetter, intel-gfx, dri-devel
On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> >
> > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > in case of big joiner used in i915 in which case even if the modeset
> > > is requested on a single pipe, internally another consecutive
> > > pipe is stolen and used to drive half of the transcoder timings.
> > > So in this case it is expected that requested crtc and affected crtcs
> > > do not match. Hence the added WARN ON becomes irrelevant.
>
> The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> then the driver is allowed to steal an unrelated pipe.
>
> Maybe i915 is stealing a pipe without allow_modeset?
No. All page flips etc. will have to get split up internally
between multiple crtcs.
So I think there's basically three options:
a) massive rewrite of i915 to bypass even more of drm_atomic stuff
b) allow i915 to silence that warning, which opens up the question
whether the warn is doing any good if it can just be bypassed
c) nuke the warning entirely
a) is not going to happen, and it would any way allow i915 to
do things any which way it wants without tripping the warn,
rendering the warn entirely toothless.
Hmm. Maybe there is a d) which would be to ignore all crtcs
that are not logically enabled in the warn? Not sure if that
could allow something to slit through that people want it to
catch?
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-10 15:07 ` Ville Syrjälä
0 siblings, 0 replies; 18+ messages in thread
From: Ville Syrjälä @ 2021-02-10 15:07 UTC (permalink / raw)
To: Simon Ser; +Cc: Daniel Vetter, intel-gfx, dri-devel
On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> >
> > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > in case of big joiner used in i915 in which case even if the modeset
> > > is requested on a single pipe, internally another consecutive
> > > pipe is stolen and used to drive half of the transcoder timings.
> > > So in this case it is expected that requested crtc and affected crtcs
> > > do not match. Hence the added WARN ON becomes irrelevant.
>
> The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> then the driver is allowed to steal an unrelated pipe.
>
> Maybe i915 is stealing a pipe without allow_modeset?
No. All page flips etc. will have to get split up internally
between multiple crtcs.
So I think there's basically three options:
a) massive rewrite of i915 to bypass even more of drm_atomic stuff
b) allow i915 to silence that warning, which opens up the question
whether the warn is doing any good if it can just be bypassed
c) nuke the warning entirely
a) is not going to happen, and it would any way allow i915 to
do things any which way it wants without tripping the warn,
rendering the warn entirely toothless.
Hmm. Maybe there is a d) which would be to ignore all crtcs
that are not logically enabled in the warn? Not sure if that
could allow something to slit through that people want it to
catch?
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 15:07 ` Ville Syrjälä
@ 2021-02-10 23:26 ` Navare, Manasi
-1 siblings, 0 replies; 18+ messages in thread
From: Navare, Manasi @ 2021-02-10 23:26 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, dri-devel, Daniel Vetter
On Wed, Feb 10, 2021 at 05:07:03PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> > >
> > > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > > in case of big joiner used in i915 in which case even if the modeset
> > > > is requested on a single pipe, internally another consecutive
> > > > pipe is stolen and used to drive half of the transcoder timings.
> > > > So in this case it is expected that requested crtc and affected crtcs
> > > > do not match. Hence the added WARN ON becomes irrelevant.
> >
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > then the driver is allowed to steal an unrelated pipe.
> >
> > Maybe i915 is stealing a pipe without allow_modeset?
>
> No. All page flips etc. will have to get split up internally
> between multiple crtcs.
>
> So I think there's basically three options:
> a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> b) allow i915 to silence that warning, which opens up the question
> whether the warn is doing any good if it can just be bypassed
> c) nuke the warning entirely
>
> a) is not going to happen, and it would any way allow i915 to
> do things any which way it wants without tripping the warn,
> rendering the warn entirely toothless.
>
> Hmm. Maybe there is a d) which would be to ignore all crtcs
> that are not logically enabled in the warn? Not sure if that
> could allow something to slit through that people want it to
> catch?
So as per the offline IRC discussions,
- We can check for crtc_state->enable and only use the enabled crtcs
in the affected crtc calculation. And this enable would only
be set when modeset is done. So in case of bigjoiner no modeset on Pipe A,
even if Pipe B is stolen, since no modeset and because that pipe doesnt
get enabled the affected crtcs would still be 0x1.
This should solve the problem.
Ville, Danvet - I will make this change?
Manasi
>
> --
> Ville Syrjälä
> Intel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-10 23:26 ` Navare, Manasi
0 siblings, 0 replies; 18+ messages in thread
From: Navare, Manasi @ 2021-02-10 23:26 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Simon Ser, intel-gfx, dri-devel, Daniel Vetter
On Wed, Feb 10, 2021 at 05:07:03PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> > >
> > > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > > in case of big joiner used in i915 in which case even if the modeset
> > > > is requested on a single pipe, internally another consecutive
> > > > pipe is stolen and used to drive half of the transcoder timings.
> > > > So in this case it is expected that requested crtc and affected crtcs
> > > > do not match. Hence the added WARN ON becomes irrelevant.
> >
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > then the driver is allowed to steal an unrelated pipe.
> >
> > Maybe i915 is stealing a pipe without allow_modeset?
>
> No. All page flips etc. will have to get split up internally
> between multiple crtcs.
>
> So I think there's basically three options:
> a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> b) allow i915 to silence that warning, which opens up the question
> whether the warn is doing any good if it can just be bypassed
> c) nuke the warning entirely
>
> a) is not going to happen, and it would any way allow i915 to
> do things any which way it wants without tripping the warn,
> rendering the warn entirely toothless.
>
> Hmm. Maybe there is a d) which would be to ignore all crtcs
> that are not logically enabled in the warn? Not sure if that
> could allow something to slit through that people want it to
> catch?
So as per the offline IRC discussions,
- We can check for crtc_state->enable and only use the enabled crtcs
in the affected crtc calculation. And this enable would only
be set when modeset is done. So in case of bigjoiner no modeset on Pipe A,
even if Pipe B is stolen, since no modeset and because that pipe doesnt
get enabled the affected crtcs would still be 0x1.
This should solve the problem.
Ville, Danvet - I will make this change?
Manasi
>
> --
> Ville Syrjälä
> Intel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 23:26 ` Navare, Manasi
@ 2021-02-11 15:46 ` Daniel Vetter
-1 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-02-11 15:46 UTC (permalink / raw)
To: Navare, Manasi; +Cc: Daniel Vetter, intel-gfx, dri-devel
On Wed, Feb 10, 2021 at 03:26:00PM -0800, Navare, Manasi wrote:
> On Wed, Feb 10, 2021 at 05:07:03PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > > On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> > > >
> > > > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > > > in case of big joiner used in i915 in which case even if the modeset
> > > > > is requested on a single pipe, internally another consecutive
> > > > > pipe is stolen and used to drive half of the transcoder timings.
> > > > > So in this case it is expected that requested crtc and affected crtcs
> > > > > do not match. Hence the added WARN ON becomes irrelevant.
> > >
> > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > > then the driver is allowed to steal an unrelated pipe.
> > >
> > > Maybe i915 is stealing a pipe without allow_modeset?
> >
> > No. All page flips etc. will have to get split up internally
> > between multiple crtcs.
> >
> > So I think there's basically three options:
> > a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> > b) allow i915 to silence that warning, which opens up the question
> > whether the warn is doing any good if it can just be bypassed
> > c) nuke the warning entirely
> >
> > a) is not going to happen, and it would any way allow i915 to
> > do things any which way it wants without tripping the warn,
> > rendering the warn entirely toothless.
> >
> > Hmm. Maybe there is a d) which would be to ignore all crtcs
> > that are not logically enabled in the warn? Not sure if that
> > could allow something to slit through that people want it to
> > catch?
Yeah it's option d), because the warning is meant to catch funny uapi that
compositors don't want to deal with. So if this bigjoiner stuff in i915 is
_really_ fully transparent, then it's ok.
And excluding completely disabled CRTC from this check makes imo sense,
since userspace
- is not allowed to issue an atomic flip on these (it's off)
- is required to set allow_modeset to enable (at which point i915 can
internally move CRTC assignments around however it feels like and it's
all fine). Once that fully modeset is done we'd again be in sync with
userspace's understanding of what's going on.
- hence there cannot be a spurious EBUSY to userspace
I think what this needs is a big comment in the code explaining why we can
afford to not check this.
> So as per the offline IRC discussions,
> - We can check for crtc_state->enable and only use the enabled crtcs
> in the affected crtc calculation. And this enable would only
> be set when modeset is done. So in case of bigjoiner no modeset on Pipe A,
> even if Pipe B is stolen, since no modeset and because that pipe doesnt
> get enabled the affected crtcs would still be 0x1.
>
> This should solve the problem.
> Ville, Danvet - I will make this change?
I think you volunteered :-)
Pls Cc: all the people involved in the original patch discussion, so that
they can ack the change too.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-11 15:46 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-02-11 15:46 UTC (permalink / raw)
To: Navare, Manasi; +Cc: Daniel Vetter, intel-gfx, dri-devel
On Wed, Feb 10, 2021 at 03:26:00PM -0800, Navare, Manasi wrote:
> On Wed, Feb 10, 2021 at 05:07:03PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > > On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > > On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
> > > >
> > > > > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > > > > in case of big joiner used in i915 in which case even if the modeset
> > > > > is requested on a single pipe, internally another consecutive
> > > > > pipe is stolen and used to drive half of the transcoder timings.
> > > > > So in this case it is expected that requested crtc and affected crtcs
> > > > > do not match. Hence the added WARN ON becomes irrelevant.
> > >
> > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > > then the driver is allowed to steal an unrelated pipe.
> > >
> > > Maybe i915 is stealing a pipe without allow_modeset?
> >
> > No. All page flips etc. will have to get split up internally
> > between multiple crtcs.
> >
> > So I think there's basically three options:
> > a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> > b) allow i915 to silence that warning, which opens up the question
> > whether the warn is doing any good if it can just be bypassed
> > c) nuke the warning entirely
> >
> > a) is not going to happen, and it would any way allow i915 to
> > do things any which way it wants without tripping the warn,
> > rendering the warn entirely toothless.
> >
> > Hmm. Maybe there is a d) which would be to ignore all crtcs
> > that are not logically enabled in the warn? Not sure if that
> > could allow something to slit through that people want it to
> > catch?
Yeah it's option d), because the warning is meant to catch funny uapi that
compositors don't want to deal with. So if this bigjoiner stuff in i915 is
_really_ fully transparent, then it's ok.
And excluding completely disabled CRTC from this check makes imo sense,
since userspace
- is not allowed to issue an atomic flip on these (it's off)
- is required to set allow_modeset to enable (at which point i915 can
internally move CRTC assignments around however it feels like and it's
all fine). Once that fully modeset is done we'd again be in sync with
userspace's understanding of what's going on.
- hence there cannot be a spurious EBUSY to userspace
I think what this needs is a big comment in the code explaining why we can
afford to not check this.
> So as per the offline IRC discussions,
> - We can check for crtc_state->enable and only use the enabled crtcs
> in the affected crtc calculation. And this enable would only
> be set when modeset is done. So in case of bigjoiner no modeset on Pipe A,
> even if Pipe B is stolen, since no modeset and because that pipe doesnt
> get enabled the affected crtcs would still be 0x1.
>
> This should solve the problem.
> Ville, Danvet - I will make this change?
I think you volunteered :-)
Pls Cc: all the people involved in the original patch discussion, so that
they can ack the change too.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-10 15:07 ` Ville Syrjälä
@ 2021-02-11 16:14 ` Daniel Stone
-1 siblings, 0 replies; 18+ messages in thread
From: Daniel Stone @ 2021-02-11 16:14 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, dri-devel, Daniel Vetter
On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > then the driver is allowed to steal an unrelated pipe.
> >
> > Maybe i915 is stealing a pipe without allow_modeset?
>
> No. All page flips etc. will have to get split up internally
> between multiple crtcs.
I think this is the salient point.
> So I think there's basically three options:
> a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> b) allow i915 to silence that warning, which opens up the question
> whether the warn is doing any good if it can just be bypassed
> c) nuke the warning entirely
>
> a) is not going to happen, and it would any way allow i915 to
> do things any which way it wants without tripping the warn,
> rendering the warn entirely toothless.
>
> Hmm. Maybe there is a d) which would be to ignore all crtcs
> that are not logically enabled in the warn? Not sure if that
> could allow something to slit through that people want it to
> catch?
So from what I understand, if I enable CRTC 44 and the driver
magically decides to split it up as a 'big-joiner' output, it will
also steal CRTC 50 to work as the other half of the output. Then if I
attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me
getting atomic completion events for both CRTC 44 and CRTC 50?
That's not OK from a userspace perspective. If you want to do magic to
create the illusion of a single CRTC, then that magic needs to be
consistent. At the moment it's the worst kind of magic: it does
implicit things under the hood for you, but then leaks all of the
behind-the-scenes detail into userspace.
Continuing with that would force us all to just ignore whatever events
we see, because we can't reason about what they may be or why they're
generated. Which doesn't allow for any kind of best practice in
userspace.
Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-11 16:14 ` Daniel Stone
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Stone @ 2021-02-11 16:14 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Simon Ser, intel-gfx, dri-devel, Daniel Vetter
On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > then the driver is allowed to steal an unrelated pipe.
> >
> > Maybe i915 is stealing a pipe without allow_modeset?
>
> No. All page flips etc. will have to get split up internally
> between multiple crtcs.
I think this is the salient point.
> So I think there's basically three options:
> a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> b) allow i915 to silence that warning, which opens up the question
> whether the warn is doing any good if it can just be bypassed
> c) nuke the warning entirely
>
> a) is not going to happen, and it would any way allow i915 to
> do things any which way it wants without tripping the warn,
> rendering the warn entirely toothless.
>
> Hmm. Maybe there is a d) which would be to ignore all crtcs
> that are not logically enabled in the warn? Not sure if that
> could allow something to slit through that people want it to
> catch?
So from what I understand, if I enable CRTC 44 and the driver
magically decides to split it up as a 'big-joiner' output, it will
also steal CRTC 50 to work as the other half of the output. Then if I
attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me
getting atomic completion events for both CRTC 44 and CRTC 50?
That's not OK from a userspace perspective. If you want to do magic to
create the illusion of a single CRTC, then that magic needs to be
consistent. At the moment it's the worst kind of magic: it does
implicit things under the hood for you, but then leaks all of the
behind-the-scenes detail into userspace.
Continuing with that would force us all to just ignore whatever events
we see, because we can't reason about what they may be or why they're
generated. Which doesn't allow for any kind of best practice in
userspace.
Cheers,
Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
2021-02-11 16:14 ` Daniel Stone
@ 2021-02-11 16:55 ` Ville Syrjälä
-1 siblings, 0 replies; 18+ messages in thread
From: Ville Syrjälä @ 2021-02-11 16:55 UTC (permalink / raw)
To: Daniel Stone; +Cc: intel-gfx, dri-devel, Daniel Vetter
On Thu, Feb 11, 2021 at 04:14:02PM +0000, Daniel Stone wrote:
> On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > > then the driver is allowed to steal an unrelated pipe.
> > >
> > > Maybe i915 is stealing a pipe without allow_modeset?
> >
> > No. All page flips etc. will have to get split up internally
> > between multiple crtcs.
>
> I think this is the salient point.
>
> > So I think there's basically three options:
> > a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> > b) allow i915 to silence that warning, which opens up the question
> > whether the warn is doing any good if it can just be bypassed
> > c) nuke the warning entirely
> >
> > a) is not going to happen, and it would any way allow i915 to
> > do things any which way it wants without tripping the warn,
> > rendering the warn entirely toothless.
> >
> > Hmm. Maybe there is a d) which would be to ignore all crtcs
> > that are not logically enabled in the warn? Not sure if that
> > could allow something to slit through that people want it to
> > catch?
>
> So from what I understand, if I enable CRTC 44 and the driver
> magically decides to split it up as a 'big-joiner' output, it will
> also steal CRTC 50 to work as the other half of the output. Then if I
> attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me
> getting atomic completion events for both CRTC 44 and CRTC 50?
>
> That's not OK from a userspace perspective. If you want to do magic to
> create the illusion of a single CRTC, then that magic needs to be
> consistent. At the moment it's the worst kind of magic: it does
> implicit things under the hood for you, but then leaks all of the
> behind-the-scenes detail into userspace.
>
> Continuing with that would force us all to just ignore whatever events
> we see, because we can't reason about what they may be or why they're
> generated. Which doesn't allow for any kind of best practice in
> userspace.
You should only get externally visibile events for stuff in your
request. Or at least if that's not the case then the atomic
code is already bork regardless of bigjoiner.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
@ 2021-02-11 16:55 ` Ville Syrjälä
0 siblings, 0 replies; 18+ messages in thread
From: Ville Syrjälä @ 2021-02-11 16:55 UTC (permalink / raw)
To: Daniel Stone; +Cc: Simon Ser, intel-gfx, dri-devel, Daniel Vetter
On Thu, Feb 11, 2021 at 04:14:02PM +0000, Daniel Stone wrote:
> On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Wed, Feb 10, 2021 at 01:38:45PM +0000, Simon Ser wrote:
> > > The WARN_ON only happens if allow_modeset == false. If allow_modeset == true,
> > > then the driver is allowed to steal an unrelated pipe.
> > >
> > > Maybe i915 is stealing a pipe without allow_modeset?
> >
> > No. All page flips etc. will have to get split up internally
> > between multiple crtcs.
>
> I think this is the salient point.
>
> > So I think there's basically three options:
> > a) massive rewrite of i915 to bypass even more of drm_atomic stuff
> > b) allow i915 to silence that warning, which opens up the question
> > whether the warn is doing any good if it can just be bypassed
> > c) nuke the warning entirely
> >
> > a) is not going to happen, and it would any way allow i915 to
> > do things any which way it wants without tripping the warn,
> > rendering the warn entirely toothless.
> >
> > Hmm. Maybe there is a d) which would be to ignore all crtcs
> > that are not logically enabled in the warn? Not sure if that
> > could allow something to slit through that people want it to
> > catch?
>
> So from what I understand, if I enable CRTC 44 and the driver
> magically decides to split it up as a 'big-joiner' output, it will
> also steal CRTC 50 to work as the other half of the output. Then if I
> attach plane 47 to CRTC 44, posting a FB to plane 47 will result in me
> getting atomic completion events for both CRTC 44 and CRTC 50?
>
> That's not OK from a userspace perspective. If you want to do magic to
> create the illusion of a single CRTC, then that magic needs to be
> consistent. At the moment it's the worst kind of magic: it does
> implicit things under the hood for you, but then leaks all of the
> behind-the-scenes detail into userspace.
>
> Continuing with that would force us all to just ignore whatever events
> we see, because we can't reason about what they may be or why they're
> generated. Which doesn't allow for any kind of best practice in
> userspace.
You should only get externally visibile events for stuff in your
request. Or at least if that's not the case then the atomic
code is already bork regardless of bigjoiner.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread