intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
@ 2020-09-23 10:57 Daniel Vetter
  2020-09-23 10:57 ` [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY Daniel Vetter
                   ` (6 more replies)
  0 siblings, 7 replies; 19+ messages in thread
From: Daniel Vetter @ 2020-09-23 10:57 UTC (permalink / raw)
  To: DRI Development
  Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
	Simon Ser, Pekka Paalanen

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).

But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
  ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
  of the additional commit inserted by the kernel without userspace's
  knowledge

For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.

Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.

v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.

v3: Fix inverted WARN_ON (Pekka).

v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.

v5: Make the WARNING more informative (Daniel)

References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Simon Ser <contact@emersion.fr>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_atomic.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..e22669b64521 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -281,6 +281,10 @@ 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
@@ -1262,10 +1266,15 @@ 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, old_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) {
@@ -1313,6 +1322,24 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
 		}
 	}
 
+	for_each_new_crtc_in_state(state, crtc, old_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) {
+		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.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY
  2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
@ 2020-09-23 10:57 ` Daniel Vetter
  2020-09-25  8:27   ` Pekka Paalanen
  2020-09-23 11:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Patchwork
                   ` (5 subsequent siblings)
  6 siblings, 1 reply; 19+ messages in thread
From: Daniel Vetter @ 2020-09-23 10:57 UTC (permalink / raw)
  To: DRI Development
  Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
	Sean Paul, Simon Ser, Pekka Paalanen

Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Simon Ser <contact@emersion.fr>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_atomic.c        |  4 ++--
 drivers/gpu/drm/drm_atomic_helper.c | 20 +++++++++++++++++---
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index e22669b64521..6864e520269d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1272,7 +1272,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
 
 	DRM_DEBUG_ATOMIC("checking %p\n", state);
 
-	for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+	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) {
@@ -1322,7 +1322,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
 		}
 	}
 
-	for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
+	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
 		affected_crtc |= drm_crtc_mask(crtc);
 
 	/*
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index e8abaaaa7fd1..6b3bfabac26c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
 	 * overridden by a previous synchronous update's state.
 	 */
 	if (old_plane_state->commit &&
-	    !try_wait_for_completion(&old_plane_state->commit->hw_done))
+	    !try_wait_for_completion(&old_plane_state->commit->hw_done)) {
+		DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit preventing async commit\n",
+			plane->base.id, plane->name);
 		return -EBUSY;
+	}
 
 	return funcs->atomic_async_check(plane, new_plane_state);
 }
@@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool nonblock)
 			 * commit with nonblocking ones. */
 			if (!completed && nonblock) {
 				spin_unlock(&crtc->commit_lock);
+				DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a previous commit\n",
+					crtc->base.id, crtc->name);
+
 				return -EBUSY;
 			}
 		} else if (i == 1) {
@@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
 		/* Userspace is not allowed to get ahead of the previous
 		 * commit with nonblocking ones. */
 		if (nonblock && old_conn_state->commit &&
-		    !try_wait_for_completion(&old_conn_state->commit->flip_done))
+		    !try_wait_for_completion(&old_conn_state->commit->flip_done)) {
+			DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a previous commit\n",
+				conn->base.id, conn->name);
+
 			return -EBUSY;
+		}
 
 		/* Always track connectors explicitly for e.g. link retraining. */
 		commit = crtc_or_fake_commit(state, new_conn_state->crtc ?: old_conn_state->crtc);
@@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
 		/* Userspace is not allowed to get ahead of the previous
 		 * commit with nonblocking ones. */
 		if (nonblock && old_plane_state->commit &&
-		    !try_wait_for_completion(&old_plane_state->commit->flip_done))
+		    !try_wait_for_completion(&old_plane_state->commit->flip_done)) {
+			DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous commit\n",
+				plane->base.id, plane->name);
+
 			return -EBUSY;
+		}
 
 		/* Always track planes explicitly for async pageflip support. */
 		commit = crtc_or_fake_commit(state, new_plane_state->crtc ?: old_plane_state->crtc);
-- 
2.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
  2020-09-23 10:57 ` [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY Daniel Vetter
@ 2020-09-23 11:03 ` Patchwork
  2020-09-23 11:28 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
                   ` (4 subsequent siblings)
  6 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2020-09-23 11:03 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
URL   : https://patchwork.freedesktop.org/series/82023/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
a59f0f6c784d drm/atomic: document and enforce rules around "spurious" EBUSY
-:44: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#44: 
References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html

-:71: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#71: FILE: drivers/gpu/drm/drm_atomic.c:1269:
+	unsigned requested_crtc = 0;

-:72: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#72: FILE: drivers/gpu/drm/drm_atomic.c:1270:
+	unsigned affected_crtc = 0;

-:107: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 4 warnings, 0 checks, 49 lines checked
03a8bf062d50 drm/atomic: debug output for EBUSY
-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: drivers/gpu/drm/drm_atomic_helper.c:1741:
+		DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit preventing async commit\n",
+			plane->base.id, plane->name);

-:63: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#63: FILE: drivers/gpu/drm/drm_atomic_helper.c:1962:
+				DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a previous commit\n",
+					crtc->base.id, crtc->name);

-:75: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#75: FILE: drivers/gpu/drm/drm_atomic_helper.c:2140:
+			DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a previous commit\n",
+				conn->base.id, conn->name);

-:89: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#89: FILE: drivers/gpu/drm/drm_atomic_helper.c:2159:
+			DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous commit\n",
+				plane->base.id, plane->name);

-:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 4 checks, 63 lines checked


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
  2020-09-23 10:57 ` [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY Daniel Vetter
  2020-09-23 11:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Patchwork
@ 2020-09-23 11:28 ` Patchwork
  2020-09-23 14:33 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
                   ` (3 subsequent siblings)
  6 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2020-09-23 11:28 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 7637 bytes --]

== Series Details ==

Series: series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
URL   : https://patchwork.freedesktop.org/series/82023/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9042 -> Patchwork_18553
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/index.html

Known issues
------------

  Here are the changes found in Patchwork_18553 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_flink_basic@double-flink:
    - 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_9042/fi-tgl-y/igt@gem_flink_basic@double-flink.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@gem_flink_basic@double-flink.html

  * igt@i915_module_load@reload:
    - fi-tgl-y:           [PASS][3] -> [DMESG-WARN][4] ([i915#1982] / [k.org#205379])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@i915_module_load@reload.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@i915_module_load@reload.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-apl-guc:         [PASS][5] -> [DMESG-WARN][6] ([i915#1635] / [i915#1982])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-apl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-apl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
    - fi-icl-u2:          [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +1 similar issue
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html

  * igt@vgem_basic@unload:
    - fi-skl-guc:         [PASS][9] -> [DMESG-WARN][10] ([i915#2203])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-skl-guc/igt@vgem_basic@unload.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-skl-guc/igt@vgem_basic@unload.html

  
#### Possible fixes ####

  * igt@gem_huc_copy@huc-copy:
    - fi-tgl-y:           [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@gem_huc_copy@huc-copy.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@gem_huc_copy@huc-copy.html

  * igt@i915_module_load@reload:
    - {fi-tgl-dsi}:       [DMESG-WARN][13] ([i915#1982] / [k.org#205379]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_module_load@reload.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-dsi/igt@i915_module_load@reload.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-byt-j1900:       [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-byt-j1900/igt@i915_pm_rpm@basic-pci-d3-state.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-byt-j1900/igt@i915_pm_rpm@basic-pci-d3-state.html

  * igt@i915_selftest@live@execlists:
    - {fi-tgl-dsi}:       [INCOMPLETE][17] ([i915#2268]) -> [PASS][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-dsi/igt@i915_selftest@live@execlists.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-dsi/igt@i915_selftest@live@execlists.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-bsw-kefka:       [DMESG-WARN][19] ([i915#1982]) -> [PASS][20] +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  
#### Warnings ####

  * igt@i915_pm_rpm@module-reload:
    - fi-tgl-y:           [DMESG-WARN][21] ([i915#1982] / [i915#2411]) -> [DMESG-WARN][22] ([i915#2411])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-tgl-y/igt@i915_pm_rpm@module-reload.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-tgl-y/igt@i915_pm_rpm@module-reload.html
    - fi-kbl-guc:         [DMESG-FAIL][23] ([i915#2203]) -> [DMESG-WARN][24] ([i915#2203])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html

  * igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
    - fi-kbl-x1275:       [DMESG-WARN][25] ([i915#62] / [i915#92]) -> [DMESG-WARN][26] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-after-cursor-legacy.html

  * igt@kms_force_connector_basic@prune-stale-modes:
    - fi-kbl-x1275:       [DMESG-WARN][27] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][28] ([i915#62] / [i915#92]) +5 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2268]: https://gitlab.freedesktop.org/drm/intel/issues/2268
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#2417]: https://gitlab.freedesktop.org/drm/intel/issues/2417
  [i915#289]: https://gitlab.freedesktop.org/drm/intel/issues/289
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
  [k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379


Participating hosts (47 -> 40)
------------------------------

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9042 -> Patchwork_18553

  CI-20190529: 20190529
  CI_DRM_9042: 1535f1ea9693fe52edf544d584272c1fa283ff8c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18553: 03a8bf062d5071a0bbabb0d3715b2d94181fce82 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

03a8bf062d50 drm/atomic: debug output for EBUSY
a59f0f6c784d drm/atomic: document and enforce rules around "spurious" EBUSY

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/index.html

[-- Attachment #1.2: Type: text/html, Size: 9644 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] 19+ messages in thread

* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
                   ` (2 preceding siblings ...)
  2020-09-23 11:28 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2020-09-23 14:33 ` Patchwork
  2020-09-23 15:18 ` [Intel-gfx] [PATCH] " Daniel Vetter
                   ` (2 subsequent siblings)
  6 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2020-09-23 14:33 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 16013 bytes --]

== Series Details ==

Series: series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY
URL   : https://patchwork.freedesktop.org/series/82023/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_9042_full -> Patchwork_18553_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_18553_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@render:
    - shard-apl:          [PASS][1] -> [FAIL][2] ([i915#1635] / [i915#2374])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl7/igt@gem_ctx_persistence@legacy-engines-mixed-process@render.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-apl1/igt@gem_ctx_persistence@legacy-engines-mixed-process@render.html

  * igt@gem_exec_suspend@basic-s4-devices:
    - shard-hsw:          [PASS][3] -> [INCOMPLETE][4] ([i915#1888])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw2/igt@gem_exec_suspend@basic-s4-devices.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-hsw4/igt@gem_exec_suspend@basic-s4-devices.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-kbl:          [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +2 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-kbl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_flip@flip-vs-expired-vblank@c-edp1:
    - shard-skl:          [PASS][7] -> [FAIL][8] ([i915#79])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl5/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl7/igt@kms_flip@flip-vs-expired-vblank@c-edp1.html

  * igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1:
    - shard-hsw:          [PASS][9] -> [INCOMPLETE][10] ([i915#2055])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-hsw6/igt@kms_flip@flip-vs-suspend-interruptible@c-hdmi-a1.html

  * igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
    - shard-kbl:          [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
    - shard-tglb:         [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +2 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-tglb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
    - shard-iclb:         [PASS][15] -> [FAIL][16] ([i915#49]) +1 similar issue
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc:
    - shard-skl:          [PASS][17] -> [FAIL][18] ([i915#49]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl3/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl4/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html

  * igt@kms_hdr@bpc-switch-suspend:
    - shard-skl:          [PASS][19] -> [FAIL][20] ([i915#1188])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl10/igt@kms_hdr@bpc-switch-suspend.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl10/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
    - shard-iclb:         [PASS][21] -> [INCOMPLETE][22] ([i915#1185])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb5/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
    - shard-skl:          [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl4/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html

  * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping:
    - shard-skl:          [PASS][25] -> [DMESG-WARN][26] ([i915#1982]) +7 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl6/igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl4/igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [PASS][27] -> [SKIP][28] ([fdo#109441]) +3 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb2/igt@kms_psr@psr2_no_drrs.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb6/igt@kms_psr@psr2_no_drrs.html

  * igt@kms_vblank@pipe-b-query-busy:
    - shard-apl:          [PASS][29] -> [DMESG-WARN][30] ([i915#1635] / [i915#1982])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl8/igt@kms_vblank@pipe-b-query-busy.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-apl4/igt@kms_vblank@pipe-b-query-busy.html

  * igt@perf@polling-small-buf:
    - shard-iclb:         [PASS][31] -> [FAIL][32] ([i915#1722])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb1/igt@perf@polling-small-buf.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb2/igt@perf@polling-small-buf.html

  
#### Possible fixes ####

  * igt@gen9_exec_parse@allowed-all:
    - shard-kbl:          [DMESG-WARN][33] ([i915#1436] / [i915#716]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl1/igt@gen9_exec_parse@allowed-all.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-kbl6/igt@gen9_exec_parse@allowed-all.html

  * igt@i915_pm_dc@dc6-psr:
    - shard-iclb:         [FAIL][35] ([i915#1899]) -> [PASS][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb1/igt@i915_pm_dc@dc6-psr.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb2/igt@i915_pm_dc@dc6-psr.html

  * igt@i915_selftest@mock@contexts:
    - shard-apl:          [INCOMPLETE][37] ([i915#1635] / [i915#2278]) -> [PASS][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl2/igt@i915_selftest@mock@contexts.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-apl7/igt@i915_selftest@mock@contexts.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-offscreen:
    - shard-snb:          [SKIP][39] ([fdo#109271]) -> [PASS][40] +2 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-snb2/igt@kms_cursor_crc@pipe-b-cursor-128x128-offscreen.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-snb1/igt@kms_cursor_crc@pipe-b-cursor-128x128-offscreen.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
    - shard-skl:          [INCOMPLETE][41] ([i915#300]) -> [PASS][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl4/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl5/igt@kms_cursor_crc@pipe-b-cursor-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt:
    - shard-apl:          [DMESG-WARN][43] ([i915#1635] / [i915#1982]) -> [PASS][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-apl3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
    - shard-kbl:          [DMESG-WARN][45] ([i915#180]) -> [PASS][46] +8 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-kbl7/igt@kms_frontbuffer_tracking@fbc-suspend.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen:
    - shard-tglb:         [DMESG-WARN][47] ([i915#1982]) -> [PASS][48] +1 similar issue
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen.html

  * igt@kms_hdr@bpc-switch:
    - shard-skl:          [FAIL][49] ([i915#1188]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl1/igt@kms_hdr@bpc-switch.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl6/igt@kms_hdr@bpc-switch.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
    - shard-skl:          [INCOMPLETE][51] ([i915#198]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl8/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl8/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b.html

  * igt@kms_plane_lowres@pipe-b-tiling-none:
    - shard-skl:          [DMESG-WARN][53] ([i915#1982]) -> [PASS][54] +6 similar issues
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl10/igt@kms_plane_lowres@pipe-b-tiling-none.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl10/igt@kms_plane_lowres@pipe-b-tiling-none.html

  * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping:
    - shard-iclb:         [DMESG-WARN][55] ([i915#1982]) -> [PASS][56] +1 similar issue
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb3/igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb2/igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping.html

  * igt@kms_psr2_su@frontbuffer:
    - shard-iclb:         [SKIP][57] ([fdo#109642] / [fdo#111068]) -> [PASS][58] +1 similar issue
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb1/igt@kms_psr2_su@frontbuffer.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb2/igt@kms_psr2_su@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [SKIP][59] ([fdo#109441]) -> [PASS][60] +3 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-iclb1/igt@kms_psr@psr2_sprite_plane_move.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_setmode@basic:
    - shard-apl:          [FAIL][61] ([i915#1635] / [i915#31]) -> [PASS][62]
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl7/igt@kms_setmode@basic.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-apl8/igt@kms_setmode@basic.html

  
#### Warnings ####

  * igt@kms_content_protection@lic:
    - shard-apl:          [TIMEOUT][63] ([i915#1319] / [i915#1635] / [i915#1958]) -> [TIMEOUT][64] ([i915#1319] / [i915#1635])
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-apl8/igt@kms_content_protection@lic.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-apl4/igt@kms_content_protection@lic.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
    - shard-skl:          [DMESG-WARN][65] ([i915#1982]) -> [DMESG-FAIL][66] ([i915#1982] / [i915#79])
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl9/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html

  * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
    - shard-skl:          [DMESG-FAIL][67] ([fdo#108145] / [i915#1982]) -> [DMESG-WARN][68] ([i915#1982])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9042/shard-skl9/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18553/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html

  
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
  [fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
  [i915#1185]: https://gitlab.freedesktop.org/drm/intel/issues/1185
  [i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
  [i915#1319]: https://gitlab.freedesktop.org/drm/intel/issues/1319
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
  [i915#1722]: https://gitlab.freedesktop.org/drm/intel/issues/1722
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1899]: https://gitlab.freedesktop.org/drm/intel/issues/1899
  [i915#1958]: https://gitlab.freedesktop.org/drm/intel/issues/1958
  [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2055]: https://gitlab.freedesktop.org/drm/intel/issues/2055
  [i915#2278]: https://gitlab.freedesktop.org/drm/intel/issues/2278
  [i915#2374]: https://gitlab.freedesktop.org/drm/intel/issues/2374
  [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#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
  [i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
  [i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79


Participating hosts (11 -> 11)
------------------------------

  No changes in participating hosts


Build changes
-------------

  * Linux: CI_DRM_9042 -> Patchwork_18553

  CI-20190529: 20190529
  CI_DRM_9042: 1535f1ea9693fe52edf544d584272c1fa283ff8c @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18553: 03a8bf062d5071a0bbabb0d3715b2d94181fce82 @ 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_18553/index.html

[-- Attachment #1.2: Type: text/html, Size: 19045 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] 19+ messages in thread

* [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
                   ` (3 preceding siblings ...)
  2020-09-23 14:33 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
@ 2020-09-23 15:18 ` Daniel Vetter
  2020-09-23 19:17   ` Marius Vlad
  2020-09-25  8:24   ` Pekka Paalanen
  2020-09-23 15:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2) Patchwork
  2020-09-23 16:16 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
  6 siblings, 2 replies; 19+ messages in thread
From: Daniel Vetter @ 2020-09-23 15:18 UTC (permalink / raw)
  To: DRI Development
  Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development,
	Simon Ser, Pekka Paalanen

When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).

But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CRTC is currently busy doing a page_flip the
  ALLOW_MODESET commit can fail with an EBUSY
- on the other CRTC a normal atomic flip can fail with EBUSY because
  of the additional commit inserted by the kernel without userspace's
  knowledge

For blocking commits this isn't a problem, because everyone else will
just block until all the CRTC are reconfigured. Only thing userspace
can notice is the dropped frames without any reason for why frames got
dropped.

Consensus is that we need new uapi to handle this properly, but no one
has any idea what exactly the new uapi should look like. Since this
has been shipping for years already compositors need to deal no matter
what, so as a first step just try to enforce this across drivers
better with some checks.

v2: Add comments and a WARN_ON to enforce this only when allowed - we
don't want to silently convert page flips into blocking plane updates
just because the driver is buggy.

v3: Fix inverted WARN_ON (Pekka).

v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
rules for drivers.

v5: Make the WARNING more informative (Daniel)

v6: Add unconditional debug output for compositor hackers to figure
out what's going on when they get an EBUSY (Daniel)

References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Simon Ser <contact@emersion.fr>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 58527f151984..f1a912e80846 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -281,6 +281,10 @@ 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
@@ -1262,10 +1266,15 @@ 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, old_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) {
@@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
 		}
 	}
 
+	for_each_new_crtc_in_state(state, crtc, old_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.28.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2)
  2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
                   ` (4 preceding siblings ...)
  2020-09-23 15:18 ` [Intel-gfx] [PATCH] " Daniel Vetter
@ 2020-09-23 15:47 ` Patchwork
  2020-09-23 16:16 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
  6 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2020-09-23 15:47 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2)
URL   : https://patchwork.freedesktop.org/series/82023/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2ae63b2182d7 drm/atomic: document and enforce rules around "spurious" EBUSY
-:47: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#47: 
References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html

-:74: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#74: FILE: drivers/gpu/drm/drm_atomic.c:1269:
+	unsigned requested_crtc = 0;

-:75: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#75: FILE: drivers/gpu/drm/drm_atomic.c:1270:
+	unsigned affected_crtc = 0;

-:112: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 4 warnings, 0 checks, 51 lines checked
126d6b5ccc51 drm/atomic: debug output for EBUSY
-:52: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#52: FILE: drivers/gpu/drm/drm_atomic_helper.c:1741:
+		DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit preventing async commit\n",
+			plane->base.id, plane->name);

-:63: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#63: FILE: drivers/gpu/drm/drm_atomic_helper.c:1962:
+				DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a previous commit\n",
+					crtc->base.id, crtc->name);

-:75: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#75: FILE: drivers/gpu/drm/drm_atomic_helper.c:2140:
+			DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a previous commit\n",
+				conn->base.id, conn->name);

-:89: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#89: FILE: drivers/gpu/drm/drm_atomic_helper.c:2159:
+			DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous commit\n",
+				plane->base.id, plane->name);

-:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter <daniel.vetter@ffwll.ch>'

total: 0 errors, 1 warnings, 4 checks, 63 lines checked


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2)
  2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
                   ` (5 preceding siblings ...)
  2020-09-23 15:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2) Patchwork
@ 2020-09-23 16:16 ` Patchwork
  6 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2020-09-23 16:16 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx


[-- Attachment #1.1: Type: text/plain, Size: 9122 bytes --]

== Series Details ==

Series: series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2)
URL   : https://patchwork.freedesktop.org/series/82023/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_9043 -> Patchwork_18558
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_18558 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18558, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_18558:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@execlists:
    - fi-cml-u2:          [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-cml-u2/igt@i915_selftest@live@execlists.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-cml-u2/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@live@gt_heartbeat:
    - fi-bsw-kefka:       [PASS][3] -> [INCOMPLETE][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html

  
Known issues
------------

  Here are the changes found in Patchwork_18558 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ringfill@basic-all:
    - fi-tgl-y:           [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-y/igt@gem_ringfill@basic-all.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-tgl-y/igt@gem_ringfill@basic-all.html

  * igt@kms_busy@basic@flip:
    - fi-kbl-x1275:       [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] / [i915#95])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@kms_busy@basic@flip.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-x1275/igt@kms_busy@basic@flip.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-icl-u2:          [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  
#### Possible fixes ####

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-bsw-kefka:       [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html

  * igt@kms_chamelium@dp-crc-fast:
    - fi-kbl-7500u:       [FAIL][13] ([i915#1372]) -> [PASS][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
    - fi-icl-u2:          [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html

  * igt@kms_flip@basic-plain-flip@d-dsi1:
    - {fi-tgl-dsi}:       [DMESG-WARN][17] ([i915#1982]) -> [PASS][18] +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-dsi/igt@kms_flip@basic-plain-flip@d-dsi1.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-tgl-dsi/igt@kms_flip@basic-plain-flip@d-dsi1.html

  * igt@vgem_basic@setversion:
    - fi-tgl-y:           [DMESG-WARN][19] ([i915#402]) -> [PASS][20] +1 similar issue
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-y/igt@vgem_basic@setversion.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-tgl-y/igt@vgem_basic@setversion.html

  * igt@vgem_basic@unload:
    - fi-skl-guc:         [DMESG-WARN][21] ([i915#2203]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-skl-guc/igt@vgem_basic@unload.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-skl-guc/igt@vgem_basic@unload.html
    - fi-kbl-x1275:       [DMESG-WARN][23] ([i915#62] / [i915#92]) -> [PASS][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@vgem_basic@unload.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-x1275/igt@vgem_basic@unload.html

  
#### Warnings ####

  * igt@gem_exec_suspend@basic-s0:
    - fi-kbl-x1275:       [DMESG-WARN][25] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][26] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html

  * igt@gem_exec_suspend@basic-s3:
    - fi-tgl-y:           [DMESG-WARN][27] ([i915#2411]) -> [DMESG-WARN][28] ([i915#2411] / [i915#402])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-tgl-y/igt@gem_exec_suspend@basic-s3.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-tgl-y/igt@gem_exec_suspend@basic-s3.html

  * igt@i915_pm_rpm@module-reload:
    - fi-kbl-x1275:       [DMESG-FAIL][29] ([i915#62] / [i915#95]) -> [DMESG-FAIL][30] ([i915#62])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
    - fi-skl-guc:         [INCOMPLETE][31] ([i915#151] / [i915#2203]) -> [DMESG-WARN][32] ([i915#2203])
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-skl-guc/igt@i915_pm_rpm@module-reload.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-skl-guc/igt@i915_pm_rpm@module-reload.html

  * igt@kms_force_connector_basic@force-edid:
    - fi-kbl-x1275:       [DMESG-WARN][33] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][34] ([i915#62] / [i915#92]) +3 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html

  * igt@kms_force_connector_basic@prune-stale-modes:
    - fi-kbl-x1275:       [DMESG-WARN][35] ([i915#62] / [i915#92]) -> [DMESG-WARN][36] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9043/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
  [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
  [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
  [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95


Participating hosts (46 -> 40)
------------------------------

  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * Linux: CI_DRM_9043 -> Patchwork_18558

  CI-20190529: 20190529
  CI_DRM_9043: 51069e2949f3b0ed967c0125ffe9ca4bf0b9b4fe @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18558: 126d6b5ccc511aef034b531eaffbf1a0ec3ca83b @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

126d6b5ccc51 drm/atomic: debug output for EBUSY
2ae63b2182d7 drm/atomic: document and enforce rules around "spurious" EBUSY

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18558/index.html

[-- Attachment #1.2: Type: text/html, Size: 12147 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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 15:18 ` [Intel-gfx] [PATCH] " Daniel Vetter
@ 2020-09-23 19:17   ` Marius Vlad
  2020-09-23 20:01     ` Daniel Vetter
  2020-09-25  8:24   ` Pekka Paalanen
  1 sibling, 1 reply; 19+ messages in thread
From: Marius Vlad @ 2020-09-23 19:17 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Pekka Paalanen


[-- Attachment #1.1: Type: text/plain, Size: 5270 bytes --]

On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
> 
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
>   ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
>   of the additional commit inserted by the kernel without userspace's
>   knowledge
> 
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
> 
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. Since this
> has been shipping for years already compositors need to deal no matter
> what, so as a first step just try to enforce this across drivers
> better with some checks.
> 
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
> 
> v3: Fix inverted WARN_ON (Pekka).
> 
> v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> rules for drivers.
> 
> v5: Make the WARNING more informative (Daniel)
> 
> v6: Add unconditional debug output for compositor hackers to figure
> out what's going on when they get an EBUSY (Daniel)
> 
> References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> Cc: Daniel Stone <daniel@fooishbar.org>
> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> Cc: Simon Ser <contact@emersion.fr>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58527f151984..f1a912e80846 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -281,6 +281,10 @@ 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
> @@ -1262,10 +1266,15 @@ 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, old_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) {
> @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>  		}
>  	}
>  
> +	for_each_new_crtc_in_state(state, crtc, old_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);
Previous patch had the warn on state->allow_modeset now is
!state->allow_modeset. Is that correct?

I haven't followed the entire thread on this matter, but I guess the idea
is that somehow the kernel would pass to userspace a CRTC mask of
affected_crtc (somehow, we don't know how atm) and with it, userspace
can then issue a new commit (this commit blocking) with those?
> +	}
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_check_only);
> -- 
> 2.28.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 19:17   ` Marius Vlad
@ 2020-09-23 20:01     ` Daniel Vetter
  2020-09-24  7:41       ` Pekka Paalanen
  0 siblings, 1 reply; 19+ messages in thread
From: Daniel Vetter @ 2020-09-23 20:01 UTC (permalink / raw)
  To: Marius Vlad
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Pekka Paalanen

On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@collabora.com> wrote:
>
> On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> >   ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> >   of the additional commit inserted by the kernel without userspace's
> >   knowledge
> >
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> >
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. Since this
> > has been shipping for years already compositors need to deal no matter
> > what, so as a first step just try to enforce this across drivers
> > better with some checks.
> >
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> >
> > v3: Fix inverted WARN_ON (Pekka).
> >
> > v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> > rules for drivers.
> >
> > v5: Make the WARNING more informative (Daniel)
> >
> > v6: Add unconditional debug output for compositor hackers to figure
> > out what's going on when they get an EBUSY (Daniel)
> >
> > References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html
> > Bugzilla: https://gitlab.freedesktop.org/wayland/weston/issues/24#note_9568
> > Cc: Daniel Stone <daniel@fooishbar.org>
> > Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
> > Cc: Simon Ser <contact@emersion.fr>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58527f151984..f1a912e80846 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -281,6 +281,10 @@ 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
> > @@ -1262,10 +1266,15 @@ 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, old_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) {
> > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> >               }
> >       }
> >
> > +     for_each_new_crtc_in_state(state, crtc, old_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);
> Previous patch had the warn on state->allow_modeset now is
> !state->allow_modeset. Is that correct?

We need to fire a warning when allow_modeset is _not_ set. An earlier
version got that wrong, and yes that would have caused a _ton_ of
warnings on any fairly new intel platform.

> I haven't followed the entire thread on this matter, but I guess the idea
> is that somehow the kernel would pass to userspace a CRTC mask of
> affected_crtc (somehow, we don't know how atm) and with it, userspace
> can then issue a new commit (this commit blocking) with those?

Either that, or just use that to track all the in-flight drm events.
Userspace will get events for all the crtc, not just the one it asked
to update. If that's easier to do by re-issuing the commit with the
full set of crtc, then I guess that's an option. But not required (I
think at least, would need to test that to make sure).
-Daniel

> > +     }
> > +
> >       return 0;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_check_only);
> > --
> > 2.28.0
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 20:01     ` Daniel Vetter
@ 2020-09-24  7:41       ` Pekka Paalanen
  2020-09-24  8:04         ` Daniel Vetter
  0 siblings, 1 reply; 19+ messages in thread
From: Pekka Paalanen @ 2020-09-24  7:41 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, Marius Vlad, DRI Development


[-- Attachment #1.1: Type: text/plain, Size: 3028 bytes --]

On Wed, 23 Sep 2020 22:01:25 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> >
> > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:  
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > reconfiguring global resources).

...

> > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> > >               }
> > >       }
> > >
> > > +     for_each_new_crtc_in_state(state, crtc, old_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);  
> > Previous patch had the warn on state->allow_modeset now is
> > !state->allow_modeset. Is that correct?  
> 
> We need to fire a warning when allow_modeset is _not_ set. An earlier
> version got that wrong, and yes that would have caused a _ton_ of
> warnings on any fairly new intel platform.
> 
> > I haven't followed the entire thread on this matter, but I guess the idea
> > is that somehow the kernel would pass to userspace a CRTC mask of
> > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > can then issue a new commit (this commit blocking) with those?  
> 
> Either that, or just use that to track all the in-flight drm events.
> Userspace will get events for all the crtc, not just the one it asked
> to update.

Wait, does that happen already? Getting CRTC events for CRTCs userspace
didn't include in the atomic commit?

That could explain why Weston freaks out in
https://gitlab.freedesktop.org/wayland/weston/-/issues/435


Thanks,
pq


> If that's easier to do by re-issuing the commit with the
> full set of crtc, then I guess that's an option. But not required (I
> think at least, would need to test that to make sure).
> -Daniel
> 
> > > +     }
> > > +
> > >       return 0;
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_check_only);

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-24  7:41       ` Pekka Paalanen
@ 2020-09-24  8:04         ` Daniel Vetter
  2020-09-24 10:10           ` Pekka Paalanen
  0 siblings, 1 reply; 19+ messages in thread
From: Daniel Vetter @ 2020-09-24  8:04 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: Daniel Vetter, Intel Graphics Development, Marius Vlad, DRI Development

On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Wed, 23 Sep 2020 22:01:25 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> > >
> > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > reconfiguring global resources).
>
> ...
>
> > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> > > >               }
> > > >       }
> > > >
> > > > +     for_each_new_crtc_in_state(state, crtc, old_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);
> > > Previous patch had the warn on state->allow_modeset now is
> > > !state->allow_modeset. Is that correct?
> >
> > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > version got that wrong, and yes that would have caused a _ton_ of
> > warnings on any fairly new intel platform.
> >
> > > I haven't followed the entire thread on this matter, but I guess the idea
> > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > > can then issue a new commit (this commit blocking) with those?
> >
> > Either that, or just use that to track all the in-flight drm events.
> > Userspace will get events for all the crtc, not just the one it asked
> > to update.
>
> Wait, does that happen already? Getting CRTC events for CRTCs userspace
> didn't include in the atomic commit?

Yeah I'm pretty sure. With the affected_crtc mask you could update
your internal book-keeping to catch these, which should also prevent
all the spurious EBUSY. But I'm not entirely sure, I just read the
code, haven't tested.

> That could explain why Weston freaks out in
> https://gitlab.freedesktop.org/wayland/weston/-/issues/435

Hm it's strange that you first get an EBUSY, and only on the next
modeset get the spurious event. You should get one already on the
first modeset.
-Daniel

>
>
> Thanks,
> pq
>
>
> > If that's easier to do by re-issuing the commit with the
> > full set of crtc, then I guess that's an option. But not required (I
> > think at least, would need to test that to make sure).
> > -Daniel
> >
> > > > +     }
> > > > +
> > > >       return 0;
> > > >  }
> > > >  EXPORT_SYMBOL(drm_atomic_check_only);



-- 
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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-24  8:04         ` Daniel Vetter
@ 2020-09-24 10:10           ` Pekka Paalanen
  2020-09-24 11:01             ` Ville Syrjälä
  0 siblings, 1 reply; 19+ messages in thread
From: Pekka Paalanen @ 2020-09-24 10:10 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, Marius Vlad, DRI Development


[-- Attachment #1.1: Type: text/plain, Size: 4548 bytes --]

On Thu, 24 Sep 2020 10:04:12 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Wed, 23 Sep 2020 22:01:25 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >  
> > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@collabora.com> wrote:  
> > > >
> > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:  
> > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > reconfiguring global resources).  
> >
> > ...
> >  
> > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> > > > >               }
> > > > >       }
> > > > >
> > > > > +     for_each_new_crtc_in_state(state, crtc, old_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);  
> > > > Previous patch had the warn on state->allow_modeset now is
> > > > !state->allow_modeset. Is that correct?  
> > >
> > > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > > version got that wrong, and yes that would have caused a _ton_ of
> > > warnings on any fairly new intel platform.
> > >  
> > > > I haven't followed the entire thread on this matter, but I guess the idea
> > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > > > can then issue a new commit (this commit blocking) with those?  
> > >
> > > Either that, or just use that to track all the in-flight drm events.
> > > Userspace will get events for all the crtc, not just the one it asked
> > > to update.  
> >
> > Wait, does that happen already? Getting CRTC events for CRTCs userspace
> > didn't include in the atomic commit?  
> 
> Yeah I'm pretty sure. With the affected_crtc mask you could update
> your internal book-keeping to catch these, which should also prevent
> all the spurious EBUSY. But I'm not entirely sure, I just read the
> code, haven't tested.

If that actually happens, how does userspace know whether the
userdata argument with the event is valid or not?

The kernel should expect the userdata argument to be one-shot, because
it may be a pointer to a malloc()'d struct that gets freed the moment
the originally expected event is handled, so re-using userdata is going
to break userspace (ISTR Mutter uses this style with legacy, Weston
passes somewhat more persistent pointers with both legacy and atomic).
Does the kernel reset it to zero? What if userspace doesn't use a
pointer but e.g. an index where 0 may be a legal value but also wrong?


Thanks,
pq

> > That could explain why Weston freaks out in
> > https://gitlab.freedesktop.org/wayland/weston/-/issues/435  
> 
> Hm it's strange that you first get an EBUSY, and only on the next
> modeset get the spurious event. You should get one already on the
> first modeset.
> -Daniel
> 
> >
> >
> > Thanks,
> > pq
> >
> >  
> > > If that's easier to do by re-issuing the commit with the
> > > full set of crtc, then I guess that's an option. But not required (I
> > > think at least, would need to test that to make sure).
> > > -Daniel
> > >  
> > > > > +     }
> > > > > +
> > > > >       return 0;
> > > > >  }
> > > > >  EXPORT_SYMBOL(drm_atomic_check_only);  
> 
> 
> 


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-24 10:10           ` Pekka Paalanen
@ 2020-09-24 11:01             ` Ville Syrjälä
  2020-09-24 11:13               ` Daniel Vetter
  0 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjälä @ 2020-09-24 11:01 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: Daniel Vetter, Intel Graphics Development, Marius Vlad,
	DRI Development, Daniel Vetter

On Thu, Sep 24, 2020 at 01:10:56PM +0300, Pekka Paalanen wrote:
> On Thu, 24 Sep 2020 10:04:12 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
> > > On Wed, 23 Sep 2020 22:01:25 +0200
> > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >  
> > > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@collabora.com> wrote:  
> > > > >
> > > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:  
> > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > > reconfiguring global resources).  
> > >
> > > ...
> > >  
> > > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> > > > > >               }
> > > > > >       }
> > > > > >
> > > > > > +     for_each_new_crtc_in_state(state, crtc, old_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);  
> > > > > Previous patch had the warn on state->allow_modeset now is
> > > > > !state->allow_modeset. Is that correct?  
> > > >
> > > > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > > > version got that wrong, and yes that would have caused a _ton_ of
> > > > warnings on any fairly new intel platform.
> > > >  
> > > > > I haven't followed the entire thread on this matter, but I guess the idea
> > > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > > > > can then issue a new commit (this commit blocking) with those?  
> > > >
> > > > Either that, or just use that to track all the in-flight drm events.
> > > > Userspace will get events for all the crtc, not just the one it asked
> > > > to update.  
> > >
> > > Wait, does that happen already? Getting CRTC events for CRTCs userspace
> > > didn't include in the atomic commit?  
> > 
> > Yeah I'm pretty sure. With the affected_crtc mask you could update
> > your internal book-keeping to catch these, which should also prevent
> > all the spurious EBUSY. But I'm not entirely sure, I just read the
> > code, haven't tested.
> 
> If that actually happens, how does userspace know whether the
> userdata argument with the event is valid or not?

At some point I was worried about the kernel potentially sending spurious
events, but IIRC I managed to convince myself that it shouldn't happen.
I think I came to the conclusion the events were populated before the
core calls into the driver. But maybe I misanalyzed it, or something
has since broken?

-- 
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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-24 11:01             ` Ville Syrjälä
@ 2020-09-24 11:13               ` Daniel Vetter
  2020-09-24 11:32                 ` Ville Syrjälä
  0 siblings, 1 reply; 19+ messages in thread
From: Daniel Vetter @ 2020-09-24 11:13 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Vetter, Pekka Paalanen, Intel Graphics Development,
	DRI Development, Marius Vlad

On Thu, Sep 24, 2020 at 1:01 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Thu, Sep 24, 2020 at 01:10:56PM +0300, Pekka Paalanen wrote:
> > On Thu, 24 Sep 2020 10:04:12 +0200
> > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > > On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > >
> > > > On Wed, 23 Sep 2020 22:01:25 +0200
> > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > >
> > > > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> > > > > >
> > > > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > > > reconfiguring global resources).
> > > >
> > > > ...
> > > >
> > > > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> > > > > > >               }
> > > > > > >       }
> > > > > > >
> > > > > > > +     for_each_new_crtc_in_state(state, crtc, old_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);
> > > > > > Previous patch had the warn on state->allow_modeset now is
> > > > > > !state->allow_modeset. Is that correct?
> > > > >
> > > > > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > > > > version got that wrong, and yes that would have caused a _ton_ of
> > > > > warnings on any fairly new intel platform.
> > > > >
> > > > > > I haven't followed the entire thread on this matter, but I guess the idea
> > > > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > > > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > > > > > can then issue a new commit (this commit blocking) with those?
> > > > >
> > > > > Either that, or just use that to track all the in-flight drm events.
> > > > > Userspace will get events for all the crtc, not just the one it asked
> > > > > to update.
> > > >
> > > > Wait, does that happen already? Getting CRTC events for CRTCs userspace
> > > > didn't include in the atomic commit?
> > >
> > > Yeah I'm pretty sure. With the affected_crtc mask you could update
> > > your internal book-keeping to catch these, which should also prevent
> > > all the spurious EBUSY. But I'm not entirely sure, I just read the
> > > code, haven't tested.
> >
> > If that actually happens, how does userspace know whether the
> > userdata argument with the event is valid or not?
>
> At some point I was worried about the kernel potentially sending spurious
> events, but IIRC I managed to convince myself that it shouldn't happen.
> I think I came to the conclusion the events were populated before the
> core calls into the driver. But maybe I misanalyzed it, or something
> has since broken?

Hm right this shouldn't happen, I misread the code. So if userspace
wants events for all affected crtc, it needs to add them explicitly to
the atomic ioctl (just set an arbitrary property on each crtc to its
current value or something like that). That also means that the bug
Pekka posted shouldn't have been caused by this stuff here.

Note for code readers: There's a retry loop for ww-mutex backoff, but
we do completely clear all states, so crtc states shouldn't be able to
persist and then get events when userspace didn't ask for them.
-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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-24 11:13               ` Daniel Vetter
@ 2020-09-24 11:32                 ` Ville Syrjälä
  0 siblings, 0 replies; 19+ messages in thread
From: Ville Syrjälä @ 2020-09-24 11:32 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Pekka Paalanen, Intel Graphics Development,
	DRI Development, Marius Vlad

On Thu, Sep 24, 2020 at 01:13:17PM +0200, Daniel Vetter wrote:
> On Thu, Sep 24, 2020 at 1:01 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Thu, Sep 24, 2020 at 01:10:56PM +0300, Pekka Paalanen wrote:
> > > On Thu, 24 Sep 2020 10:04:12 +0200
> > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > >
> > > > On Thu, Sep 24, 2020 at 9:41 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > > >
> > > > > On Wed, 23 Sep 2020 22:01:25 +0200
> > > > > Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > > >
> > > > > > On Wed, Sep 23, 2020 at 9:17 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> > > > > > >
> > > > > > > On Wed, Sep 23, 2020 at 05:18:52PM +0200, Daniel Vetter wrote:
> > > > > > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > > > > > > pull in arbitrary other resources, including CRTCs (e.g. when
> > > > > > > > reconfiguring global resources).
> > > > >
> > > > > ...
> > > > >
> > > > > > > > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> > > > > > > >               }
> > > > > > > >       }
> > > > > > > >
> > > > > > > > +     for_each_new_crtc_in_state(state, crtc, old_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);
> > > > > > > Previous patch had the warn on state->allow_modeset now is
> > > > > > > !state->allow_modeset. Is that correct?
> > > > > >
> > > > > > We need to fire a warning when allow_modeset is _not_ set. An earlier
> > > > > > version got that wrong, and yes that would have caused a _ton_ of
> > > > > > warnings on any fairly new intel platform.
> > > > > >
> > > > > > > I haven't followed the entire thread on this matter, but I guess the idea
> > > > > > > is that somehow the kernel would pass to userspace a CRTC mask of
> > > > > > > affected_crtc (somehow, we don't know how atm) and with it, userspace
> > > > > > > can then issue a new commit (this commit blocking) with those?
> > > > > >
> > > > > > Either that, or just use that to track all the in-flight drm events.
> > > > > > Userspace will get events for all the crtc, not just the one it asked
> > > > > > to update.
> > > > >
> > > > > Wait, does that happen already? Getting CRTC events for CRTCs userspace
> > > > > didn't include in the atomic commit?
> > > >
> > > > Yeah I'm pretty sure. With the affected_crtc mask you could update
> > > > your internal book-keeping to catch these, which should also prevent
> > > > all the spurious EBUSY. But I'm not entirely sure, I just read the
> > > > code, haven't tested.
> > >
> > > If that actually happens, how does userspace know whether the
> > > userdata argument with the event is valid or not?
> >
> > At some point I was worried about the kernel potentially sending spurious
> > events, but IIRC I managed to convince myself that it shouldn't happen.
> > I think I came to the conclusion the events were populated before the
> > core calls into the driver. But maybe I misanalyzed it, or something
> > has since broken?
> 
> Hm right this shouldn't happen, I misread the code. So if userspace
> wants events for all affected crtc, it needs to add them explicitly to
> the atomic ioctl (just set an arbitrary property on each crtc to its
> current value or something like that).

Hmm. I thought we wouldn't even need the dummy prop. But looking at
the code we do in fact need it. The ioctl structure itself should
allow adding an object without any properties, but the code then
skips the get_crtc_state() and thus no event for that crtc. I guess
it's been like that forever so not much point in trying to change
that anymore.

-- 
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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-23 15:18 ` [Intel-gfx] [PATCH] " Daniel Vetter
  2020-09-23 19:17   ` Marius Vlad
@ 2020-09-25  8:24   ` Pekka Paalanen
  2020-09-25  8:45     ` Daniel Vetter
  1 sibling, 1 reply; 19+ messages in thread
From: Pekka Paalanen @ 2020-09-25  8:24 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development


[-- Attachment #1.1: Type: text/plain, Size: 4649 bytes --]

On Wed, 23 Sep 2020 17:18:52 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
> 
> But in nonblocking mode userspace has then no idea this happened,
> which can lead to spurious EBUSY calls, both:
> - when that other CRTC is currently busy doing a page_flip the
>   ALLOW_MODESET commit can fail with an EBUSY
> - on the other CRTC a normal atomic flip can fail with EBUSY because
>   of the additional commit inserted by the kernel without userspace's
>   knowledge
> 
> For blocking commits this isn't a problem, because everyone else will
> just block until all the CRTC are reconfigured. Only thing userspace
> can notice is the dropped frames without any reason for why frames got
> dropped.
> 
> Consensus is that we need new uapi to handle this properly, but no one
> has any idea what exactly the new uapi should look like. Since this
> has been shipping for years already compositors need to deal no matter
> what, so as a first step just try to enforce this across drivers
> better with some checks.
> 
> v2: Add comments and a WARN_ON to enforce this only when allowed - we
> don't want to silently convert page flips into blocking plane updates
> just because the driver is buggy.
> 
> v3: Fix inverted WARN_ON (Pekka).
> 
> v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> rules for drivers.
> 
> v5: Make the WARNING more informative (Daniel)
> 
> v6: Add unconditional debug output for compositor hackers to figure
> out what's going on when they get an EBUSY (Daniel)

... gmail workaround ...

> ---
>  drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58527f151984..f1a912e80846 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -281,6 +281,10 @@ 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
> @@ -1262,10 +1266,15 @@ 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, old_crtc_state, i)
> +		requested_crtc |= drm_crtc_mask(crtc);

Is "old crtc state" the state that userspace is requesting as the new
state?

> +
>  	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) {
> @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>  		}
>  	}
>  
> +	for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> +		affected_crtc |= drm_crtc_mask(crtc);

And after driver check processing, the "old crtc state" has been
modified by the driver to add anything it will necessarily need like
other CRTCs?

What is "new state" then?

> +
> +	/*
> +	 * 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);
> +	}

This hunk looks good to me.


Thanks,
pq

> +
>  	return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_check_only);


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY
  2020-09-23 10:57 ` [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY Daniel Vetter
@ 2020-09-25  8:27   ` Pekka Paalanen
  0 siblings, 0 replies; 19+ messages in thread
From: Pekka Paalanen @ 2020-09-25  8:27 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Vetter, Intel Graphics Development, Sean Paul, DRI Development


[-- Attachment #1.1: Type: text/plain, Size: 4088 bytes --]

On Wed, 23 Sep 2020 12:57:37 +0200
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
> 

These debug messages will be especially useful with the flight
recorder, but also without. :-)

...

> ---
>  drivers/gpu/drm/drm_atomic.c        |  4 ++--
>  drivers/gpu/drm/drm_atomic_helper.c | 20 +++++++++++++++++---
>  2 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index e22669b64521..6864e520269d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1272,7 +1272,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>  
>  	DRM_DEBUG_ATOMIC("checking %p\n", state);
>  
> -	for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> +	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) {
> @@ -1322,7 +1322,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
>  		}
>  	}
>  
> -	for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> +	for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
>  		affected_crtc |= drm_crtc_mask(crtc);

Oops, these belong in the previous patch?

>  
>  	/*
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index e8abaaaa7fd1..6b3bfabac26c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1740,8 +1740,11 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
>  	 * overridden by a previous synchronous update's state.
>  	 */
>  	if (old_plane_state->commit &&
> -	    !try_wait_for_completion(&old_plane_state->commit->hw_done))
> +	    !try_wait_for_completion(&old_plane_state->commit->hw_done)) {
> +		DRM_DEBUG_ATOMIC("[PLANE:%d:%s] inflight previous commit preventing async commit\n",
> +			plane->base.id, plane->name);
>  		return -EBUSY;
> +	}
>  
>  	return funcs->atomic_async_check(plane, new_plane_state);
>  }
> @@ -1964,6 +1967,9 @@ static int stall_checks(struct drm_crtc *crtc, bool nonblock)
>  			 * commit with nonblocking ones. */
>  			if (!completed && nonblock) {
>  				spin_unlock(&crtc->commit_lock);
> +				DRM_DEBUG_ATOMIC("[CRTC:%d:%s] busy with a previous commit\n",
> +					crtc->base.id, crtc->name);
> +
>  				return -EBUSY;
>  			}
>  		} else if (i == 1) {
> @@ -2132,8 +2138,12 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
>  		/* Userspace is not allowed to get ahead of the previous
>  		 * commit with nonblocking ones. */
>  		if (nonblock && old_conn_state->commit &&
> -		    !try_wait_for_completion(&old_conn_state->commit->flip_done))
> +		    !try_wait_for_completion(&old_conn_state->commit->flip_done)) {
> +			DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] busy with a previous commit\n",
> +				conn->base.id, conn->name);
> +
>  			return -EBUSY;
> +		}
>  
>  		/* Always track connectors explicitly for e.g. link retraining. */
>  		commit = crtc_or_fake_commit(state, new_conn_state->crtc ?: old_conn_state->crtc);
> @@ -2147,8 +2157,12 @@ int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
>  		/* Userspace is not allowed to get ahead of the previous
>  		 * commit with nonblocking ones. */
>  		if (nonblock && old_plane_state->commit &&
> -		    !try_wait_for_completion(&old_plane_state->commit->flip_done))
> +		    !try_wait_for_completion(&old_plane_state->commit->flip_done)) {
> +			DRM_DEBUG_ATOMIC("[PLANE:%d:%s] busy with a previous commit\n",
> +				plane->base.id, plane->name);
> +
>  			return -EBUSY;
> +		}
>  
>  		/* Always track planes explicitly for async pageflip support. */
>  		commit = crtc_or_fake_commit(state, new_plane_state->crtc ?: old_plane_state->crtc);

The new debug messages sound good to me.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 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] 19+ messages in thread

* Re: [Intel-gfx] [PATCH] drm/atomic: document and enforce rules around "spurious" EBUSY
  2020-09-25  8:24   ` Pekka Paalanen
@ 2020-09-25  8:45     ` Daniel Vetter
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2020-09-25  8:45 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
	Daniel Vetter

On Fri, Sep 25, 2020 at 11:24:46AM +0300, Pekka Paalanen wrote:
> On Wed, 23 Sep 2020 17:18:52 +0200
> Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> > 
> > But in nonblocking mode userspace has then no idea this happened,
> > which can lead to spurious EBUSY calls, both:
> > - when that other CRTC is currently busy doing a page_flip the
> >   ALLOW_MODESET commit can fail with an EBUSY
> > - on the other CRTC a normal atomic flip can fail with EBUSY because
> >   of the additional commit inserted by the kernel without userspace's
> >   knowledge
> > 
> > For blocking commits this isn't a problem, because everyone else will
> > just block until all the CRTC are reconfigured. Only thing userspace
> > can notice is the dropped frames without any reason for why frames got
> > dropped.
> > 
> > Consensus is that we need new uapi to handle this properly, but no one
> > has any idea what exactly the new uapi should look like. Since this
> > has been shipping for years already compositors need to deal no matter
> > what, so as a first step just try to enforce this across drivers
> > better with some checks.
> > 
> > v2: Add comments and a WARN_ON to enforce this only when allowed - we
> > don't want to silently convert page flips into blocking plane updates
> > just because the driver is buggy.
> > 
> > v3: Fix inverted WARN_ON (Pekka).
> > 
> > v4: Drop the uapi changes, only add a WARN_ON for now to enforce some
> > rules for drivers.
> > 
> > v5: Make the WARNING more informative (Daniel)
> > 
> > v6: Add unconditional debug output for compositor hackers to figure
> > out what's going on when they get an EBUSY (Daniel)
> 
> ... gmail workaround ...
> 
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 58527f151984..f1a912e80846 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -281,6 +281,10 @@ 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
> > @@ -1262,10 +1266,15 @@ 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, old_crtc_state, i)
> > +		requested_crtc |= drm_crtc_mask(crtc);
> 
> Is "old crtc state" the state that userspace is requesting as the new
> state?

It's a dummy iterator variable we don't care about, all we really want is
to know which crtc are all part of the update. But everyone else also
wants the state.

I'll shuffle the patches so the hunk Ville requested is in the right
patch.
-Daniel

> 
> > +
> >  	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) {
> > @@ -1313,6 +1322,26 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> >  		}
> >  	}
> >  
> > +	for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> > +		affected_crtc |= drm_crtc_mask(crtc);
> 
> And after driver check processing, the "old crtc state" has been
> modified by the driver to add anything it will necessarily need like
> other CRTCs?
> 
> What is "new state" then?
> 
> > +
> > +	/*
> > +	 * 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);
> > +	}
> 
> This hunk looks good to me.
> 
> 
> Thanks,
> pq
> 
> > +
> >  	return 0;
> >  }
> >  EXPORT_SYMBOL(drm_atomic_check_only);
> 



-- 
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] 19+ messages in thread

end of thread, other threads:[~2020-09-25  8:45 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-23 10:57 [Intel-gfx] [PATCH 1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Daniel Vetter
2020-09-23 10:57 ` [Intel-gfx] [PATCH 2/2] drm/atomic: debug output for EBUSY Daniel Vetter
2020-09-25  8:27   ` Pekka Paalanen
2020-09-23 11:03 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/atomic: document and enforce rules around "spurious" EBUSY Patchwork
2020-09-23 11:28 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-09-23 14:33 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-09-23 15:18 ` [Intel-gfx] [PATCH] " Daniel Vetter
2020-09-23 19:17   ` Marius Vlad
2020-09-23 20:01     ` Daniel Vetter
2020-09-24  7:41       ` Pekka Paalanen
2020-09-24  8:04         ` Daniel Vetter
2020-09-24 10:10           ` Pekka Paalanen
2020-09-24 11:01             ` Ville Syrjälä
2020-09-24 11:13               ` Daniel Vetter
2020-09-24 11:32                 ` Ville Syrjälä
2020-09-25  8:24   ` Pekka Paalanen
2020-09-25  8:45     ` Daniel Vetter
2020-09-23 15:47 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/atomic: document and enforce rules around "spurious" EBUSY (rev2) Patchwork
2020-09-23 16:16 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).