All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 11:50 ` Daniel Vetter
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-02-25 11:50 UTC (permalink / raw)
  To: DRI Development
  Cc: Intel Graphics Development, Daniel Vetter, Daniel Stone,
	Pekka Paalanen, stable, Daniel Stone, Daniel Vetter

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. As a stop-gap
plug this problem by demoting nonblocking commits which might cause
issues by including CRTCs not in the original request to blocking
commits.

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).

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: stable@vger.kernel.org
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9ccfbf213d72..4c035abf98b8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
 int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
 {
 	struct drm_mode_config *config = &state->dev->mode_config;
-	int ret;
+	unsigned requested_crtc = 0;
+	unsigned affected_crtc = 0;
+	struct drm_crtc *crtc;
+	struct drm_crtc_state *crtc_state;
+	bool nonblocking = true;
+	int ret, i;
+
+	/*
+	 * For commits that allow modesets drivers can add other CRTCs to the
+	 * atomic commit, e.g. when they need to reallocate global resources.
+	 *
+	 * But when userspace also requests a nonblocking commit then userspace
+	 * cannot know that the commit affects other CRTCs, which can result in
+	 * spurious EBUSY failures. Until we have better uapi plug this by
+	 * demoting such commits to blocking mode.
+	 */
+	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+		requested_crtc |= drm_crtc_mask(crtc);
 
 	ret = drm_atomic_check_only(state);
 	if (ret)
 		return ret;
 
-	DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+		affected_crtc |= drm_crtc_mask(crtc);
+
+	if (affected_crtc != requested_crtc) {
+		/* adding other CRTC is only allowed for modeset commits */
+		WARN_ON(!state->allow_modeset);
+
+		DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
+		nonblocking = false;
+	} else {
+		DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+	}
 
-	return config->funcs->atomic_commit(state->dev, state, true);
+	return config->funcs->atomic_commit(state->dev, state, nonblocking);
 }
 EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
 
-- 
2.24.1


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

* [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 11:50 ` Daniel Vetter
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-02-25 11:50 UTC (permalink / raw)
  To: DRI Development
  Cc: Daniel Stone, Daniel Vetter, Intel Graphics Development, stable,
	Daniel Vetter, 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. As a stop-gap
plug this problem by demoting nonblocking commits which might cause
issues by including CRTCs not in the original request to blocking
commits.

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).

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: stable@vger.kernel.org
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9ccfbf213d72..4c035abf98b8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
 int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
 {
 	struct drm_mode_config *config = &state->dev->mode_config;
-	int ret;
+	unsigned requested_crtc = 0;
+	unsigned affected_crtc = 0;
+	struct drm_crtc *crtc;
+	struct drm_crtc_state *crtc_state;
+	bool nonblocking = true;
+	int ret, i;
+
+	/*
+	 * For commits that allow modesets drivers can add other CRTCs to the
+	 * atomic commit, e.g. when they need to reallocate global resources.
+	 *
+	 * But when userspace also requests a nonblocking commit then userspace
+	 * cannot know that the commit affects other CRTCs, which can result in
+	 * spurious EBUSY failures. Until we have better uapi plug this by
+	 * demoting such commits to blocking mode.
+	 */
+	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+		requested_crtc |= drm_crtc_mask(crtc);
 
 	ret = drm_atomic_check_only(state);
 	if (ret)
 		return ret;
 
-	DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+		affected_crtc |= drm_crtc_mask(crtc);
+
+	if (affected_crtc != requested_crtc) {
+		/* adding other CRTC is only allowed for modeset commits */
+		WARN_ON(!state->allow_modeset);
+
+		DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
+		nonblocking = false;
+	} else {
+		DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+	}
 
-	return config->funcs->atomic_commit(state->dev, state, true);
+	return config->funcs->atomic_commit(state->dev, state, nonblocking);
 }
 EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
 
-- 
2.24.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 11:50 ` Daniel Vetter
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-02-25 11:50 UTC (permalink / raw)
  To: DRI Development
  Cc: Daniel Stone, Daniel Vetter, Intel Graphics Development, stable,
	Daniel Vetter, 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. As a stop-gap
plug this problem by demoting nonblocking commits which might cause
issues by including CRTCs not in the original request to blocking
commits.

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).

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: stable@vger.kernel.org
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 9ccfbf213d72..4c035abf98b8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
 int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
 {
 	struct drm_mode_config *config = &state->dev->mode_config;
-	int ret;
+	unsigned requested_crtc = 0;
+	unsigned affected_crtc = 0;
+	struct drm_crtc *crtc;
+	struct drm_crtc_state *crtc_state;
+	bool nonblocking = true;
+	int ret, i;
+
+	/*
+	 * For commits that allow modesets drivers can add other CRTCs to the
+	 * atomic commit, e.g. when they need to reallocate global resources.
+	 *
+	 * But when userspace also requests a nonblocking commit then userspace
+	 * cannot know that the commit affects other CRTCs, which can result in
+	 * spurious EBUSY failures. Until we have better uapi plug this by
+	 * demoting such commits to blocking mode.
+	 */
+	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+		requested_crtc |= drm_crtc_mask(crtc);
 
 	ret = drm_atomic_check_only(state);
 	if (ret)
 		return ret;
 
-	DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+		affected_crtc |= drm_crtc_mask(crtc);
+
+	if (affected_crtc != requested_crtc) {
+		/* adding other CRTC is only allowed for modeset commits */
+		WARN_ON(!state->allow_modeset);
+
+		DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
+		nonblocking = false;
+	} else {
+		DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
+	}
 
-	return config->funcs->atomic_commit(state->dev, state, true);
+	return config->funcs->atomic_commit(state->dev, state, nonblocking);
 }
 EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
 
-- 
2.24.1

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

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

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3)
  2020-02-25 11:50 ` Daniel Vetter
  (?)
  (?)
@ 2020-02-25 13:46 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-02-25 13:46 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3)
URL   : https://patchwork.freedesktop.org/series/45968/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fa89a2596808 drm: avoid spurious EBUSY due to nonblocking atomic modesets
-:35: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#35: 
References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html

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

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

-:93: 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, 46 lines checked

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

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

* [Intel-gfx] ✓ Fi.CI.BAT: success for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3)
  2020-02-25 11:50 ` Daniel Vetter
                   ` (2 preceding siblings ...)
  (?)
@ 2020-02-25 14:39 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-02-25 14:39 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3)
URL   : https://patchwork.freedesktop.org/series/45968/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8004 -> Patchwork_16701
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * {igt@kms_busy@basic@modeset}:
    - fi-apl-guc:         [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-apl-guc/igt@kms_busy@basic@modeset.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-apl-guc/igt@kms_busy@basic@modeset.html
    - fi-icl-dsi:         [PASS][3] -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-dsi/igt@kms_busy@basic@modeset.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-dsi/igt@kms_busy@basic@modeset.html
    - {fi-tgl-u}:         [PASS][5] -> [FAIL][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-u/igt@kms_busy@basic@modeset.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-tgl-u/igt@kms_busy@basic@modeset.html
    - {fi-tgl-dsi}:       [PASS][7] -> [FAIL][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-dsi/igt@kms_busy@basic@modeset.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-tgl-dsi/igt@kms_busy@basic@modeset.html
    - fi-bxt-dsi:         [PASS][9] -> [FAIL][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-bxt-dsi/igt@kms_busy@basic@modeset.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-bxt-dsi/igt@kms_busy@basic@modeset.html
    - fi-cfl-guc:         [PASS][11] -> [FAIL][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cfl-guc/igt@kms_busy@basic@modeset.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cfl-guc/igt@kms_busy@basic@modeset.html
    - fi-skl-6600u:       NOTRUN -> [FAIL][13]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-skl-6600u/igt@kms_busy@basic@modeset.html
    - fi-cml-s:           [PASS][14] -> [FAIL][15]
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cml-s/igt@kms_busy@basic@modeset.html
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cml-s/igt@kms_busy@basic@modeset.html
    - fi-skl-lmem:        [PASS][16] -> [FAIL][17]
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-skl-lmem/igt@kms_busy@basic@modeset.html
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-skl-lmem/igt@kms_busy@basic@modeset.html
    - {fi-ehl-1}:         NOTRUN -> [FAIL][18]
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-ehl-1/igt@kms_busy@basic@modeset.html
    - fi-bsw-n3050:       [PASS][19] -> [FAIL][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-bsw-n3050/igt@kms_busy@basic@modeset.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-bsw-n3050/igt@kms_busy@basic@modeset.html
    - fi-icl-guc:         [PASS][21] -> [FAIL][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-guc/igt@kms_busy@basic@modeset.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-guc/igt@kms_busy@basic@modeset.html
    - fi-byt-n2820:       [PASS][23] -> [FAIL][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-byt-n2820/igt@kms_busy@basic@modeset.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-byt-n2820/igt@kms_busy@basic@modeset.html
    - fi-skl-6700k2:      [PASS][25] -> [FAIL][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-skl-6700k2/igt@kms_busy@basic@modeset.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-skl-6700k2/igt@kms_busy@basic@modeset.html
    - fi-glk-dsi:         [PASS][27] -> [FAIL][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-glk-dsi/igt@kms_busy@basic@modeset.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-glk-dsi/igt@kms_busy@basic@modeset.html
    - fi-bsw-kefka:       [PASS][29] -> [FAIL][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-bsw-kefka/igt@kms_busy@basic@modeset.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-bsw-kefka/igt@kms_busy@basic@modeset.html
    - fi-skl-guc:         [PASS][31] -> [FAIL][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-skl-guc/igt@kms_busy@basic@modeset.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-skl-guc/igt@kms_busy@basic@modeset.html
    - fi-kbl-x1275:       [PASS][33] -> [FAIL][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-kbl-x1275/igt@kms_busy@basic@modeset.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-kbl-x1275/igt@kms_busy@basic@modeset.html
    - fi-kbl-7500u:       [PASS][35] -> [FAIL][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-kbl-7500u/igt@kms_busy@basic@modeset.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-kbl-7500u/igt@kms_busy@basic@modeset.html
    - fi-cfl-8109u:       [PASS][37] -> [FAIL][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cfl-8109u/igt@kms_busy@basic@modeset.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cfl-8109u/igt@kms_busy@basic@modeset.html
    - fi-icl-y:           [PASS][39] -> [FAIL][40]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-y/igt@kms_busy@basic@modeset.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-y/igt@kms_busy@basic@modeset.html
    - fi-cfl-8700k:       [PASS][41] -> [FAIL][42]
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cfl-8700k/igt@kms_busy@basic@modeset.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cfl-8700k/igt@kms_busy@basic@modeset.html
    - fi-kbl-r:           [PASS][43] -> [FAIL][44]
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-kbl-r/igt@kms_busy@basic@modeset.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-kbl-r/igt@kms_busy@basic@modeset.html
    - fi-icl-u2:          [PASS][45] -> [FAIL][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-u2/igt@kms_busy@basic@modeset.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-u2/igt@kms_busy@basic@modeset.html
    - fi-cml-u2:          [PASS][47] -> [FAIL][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cml-u2/igt@kms_busy@basic@modeset.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cml-u2/igt@kms_busy@basic@modeset.html
    - fi-byt-j1900:       [PASS][49] -> [FAIL][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-byt-j1900/igt@kms_busy@basic@modeset.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-byt-j1900/igt@kms_busy@basic@modeset.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-icl-u2:          [PASS][51] -> [FAIL][52] ([i915#217])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@prime_self_import@basic-with_one_bo_two_files:
    - fi-tgl-y:           [PASS][53] -> [DMESG-WARN][54] ([CI#94] / [i915#402]) +1 similar issue
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-tgl-y/igt@prime_self_import@basic-with_one_bo_two_files.html

  
#### Possible fixes ####

  * igt@i915_selftest@live_execlists:
    - fi-icl-y:           [INCOMPLETE][55] ([i915#140]) -> [PASS][56]
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-icl-y/igt@i915_selftest@live_execlists.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-icl-y/igt@i915_selftest@live_execlists.html

  * igt@kms_addfb_basic@addfb25-bad-modifier:
    - fi-tgl-y:           [DMESG-WARN][57] ([CI#94] / [i915#402]) -> [PASS][58] +1 similar issue
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-tgl-y/igt@kms_addfb_basic@addfb25-bad-modifier.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-tgl-y/igt@kms_addfb_basic@addfb25-bad-modifier.html

  * igt@kms_chamelium@dp-edid-read:
    - fi-cml-u2:          [FAIL][59] ([i915#217] / [i915#976]) -> [PASS][60]
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8004/fi-cml-u2/igt@kms_chamelium@dp-edid-read.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/fi-cml-u2/igt@kms_chamelium@dp-edid-read.html

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

  [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
  [i915#140]: https://gitlab.freedesktop.org/drm/intel/issues/140
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976


Participating hosts (43 -> 44)
------------------------------

  Additional (7): fi-ehl-1 fi-ilk-650 fi-snb-2520m fi-gdg-551 fi-elk-e7500 fi-blb-e6850 fi-skl-6600u 
  Missing    (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-byt-clapper fi-bsw-nick fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8004 -> Patchwork_16701

  CI-20190529: 20190529
  CI_DRM_8004: 1a2e0cce5af4a9ad9694995610ed64578ccc430f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5464: 8cf2f8684992052ab89de1cf328c418224c0c2a7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16701: fa89a2596808b056b52d6c22b5e5ddc3fe07e25a @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

fa89a2596808 drm: avoid spurious EBUSY due to nonblocking atomic modesets

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16701/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
  2020-02-25 11:50 ` Daniel Vetter
  (?)
@ 2020-02-25 14:48   ` Ville Syrjälä
  -1 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-02-25 14:48 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: DRI Development, Daniel Stone, Intel Graphics Development,
	stable, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> plug this problem by demoting nonblocking commits which might cause
> issues by including CRTCs not in the original request to blocking
> commits.
> 
> 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).
> 
> 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: stable@vger.kernel.org
> Reviewed-by: Daniel Stone <daniels@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
>  1 file changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9ccfbf213d72..4c035abf98b8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
>  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
>  {
>  	struct drm_mode_config *config = &state->dev->mode_config;
> -	int ret;
> +	unsigned requested_crtc = 0;
> +	unsigned affected_crtc = 0;
> +	struct drm_crtc *crtc;
> +	struct drm_crtc_state *crtc_state;
> +	bool nonblocking = true;
> +	int ret, i;
> +
> +	/*
> +	 * For commits that allow modesets drivers can add other CRTCs to the
> +	 * atomic commit, e.g. when they need to reallocate global resources.
> +	 *
> +	 * But when userspace also requests a nonblocking commit then userspace
> +	 * cannot know that the commit affects other CRTCs, which can result in
> +	 * spurious EBUSY failures. Until we have better uapi plug this by
> +	 * demoting such commits to blocking mode.
> +	 */
> +	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> +		requested_crtc |= drm_crtc_mask(crtc);
>  
>  	ret = drm_atomic_check_only(state);
>  	if (ret)
>  		return ret;
>  
> -	DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> +	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> +		affected_crtc |= drm_crtc_mask(crtc);
> +
> +	if (affected_crtc != requested_crtc) {
> +		/* adding other CRTC is only allowed for modeset commits */
> +		WARN_ON(!state->allow_modeset);

Not sure that's really true. What if the driver needs to eg.
redistribute FIFO space or something between the pipes? Or do we
expect drivers to now examine state->allow_modeset to figure out
if they're allowed to do certain things?

> +
> +		DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
> +		nonblocking = false;
> +	} else {
> +		DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> +	}
>  
> -	return config->funcs->atomic_commit(state->dev, state, true);
> +	return config->funcs->atomic_commit(state->dev, state, nonblocking);
>  }
>  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
>  
> -- 
> 2.24.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 14:48   ` Ville Syrjälä
  0 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-02-25 14:48 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> plug this problem by demoting nonblocking commits which might cause
> issues by including CRTCs not in the original request to blocking
> commits.
> 
> 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).
> 
> 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: stable@vger.kernel.org
> Reviewed-by: Daniel Stone <daniels@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
>  1 file changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9ccfbf213d72..4c035abf98b8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
>  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
>  {
>  	struct drm_mode_config *config = &state->dev->mode_config;
> -	int ret;
> +	unsigned requested_crtc = 0;
> +	unsigned affected_crtc = 0;
> +	struct drm_crtc *crtc;
> +	struct drm_crtc_state *crtc_state;
> +	bool nonblocking = true;
> +	int ret, i;
> +
> +	/*
> +	 * For commits that allow modesets drivers can add other CRTCs to the
> +	 * atomic commit, e.g. when they need to reallocate global resources.
> +	 *
> +	 * But when userspace also requests a nonblocking commit then userspace
> +	 * cannot know that the commit affects other CRTCs, which can result in
> +	 * spurious EBUSY failures. Until we have better uapi plug this by
> +	 * demoting such commits to blocking mode.
> +	 */
> +	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> +		requested_crtc |= drm_crtc_mask(crtc);
>  
>  	ret = drm_atomic_check_only(state);
>  	if (ret)
>  		return ret;
>  
> -	DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> +	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> +		affected_crtc |= drm_crtc_mask(crtc);
> +
> +	if (affected_crtc != requested_crtc) {
> +		/* adding other CRTC is only allowed for modeset commits */
> +		WARN_ON(!state->allow_modeset);

Not sure that's really true. What if the driver needs to eg.
redistribute FIFO space or something between the pipes? Or do we
expect drivers to now examine state->allow_modeset to figure out
if they're allowed to do certain things?

> +
> +		DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
> +		nonblocking = false;
> +	} else {
> +		DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> +	}
>  
> -	return config->funcs->atomic_commit(state->dev, state, true);
> +	return config->funcs->atomic_commit(state->dev, state, nonblocking);
>  }
>  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
>  
> -- 
> 2.24.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 14:48   ` Ville Syrjälä
  0 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-02-25 14:48 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> plug this problem by demoting nonblocking commits which might cause
> issues by including CRTCs not in the original request to blocking
> commits.
> 
> 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).
> 
> 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: stable@vger.kernel.org
> Reviewed-by: Daniel Stone <daniels@collabora.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
>  1 file changed, 31 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 9ccfbf213d72..4c035abf98b8 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
>  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
>  {
>  	struct drm_mode_config *config = &state->dev->mode_config;
> -	int ret;
> +	unsigned requested_crtc = 0;
> +	unsigned affected_crtc = 0;
> +	struct drm_crtc *crtc;
> +	struct drm_crtc_state *crtc_state;
> +	bool nonblocking = true;
> +	int ret, i;
> +
> +	/*
> +	 * For commits that allow modesets drivers can add other CRTCs to the
> +	 * atomic commit, e.g. when they need to reallocate global resources.
> +	 *
> +	 * But when userspace also requests a nonblocking commit then userspace
> +	 * cannot know that the commit affects other CRTCs, which can result in
> +	 * spurious EBUSY failures. Until we have better uapi plug this by
> +	 * demoting such commits to blocking mode.
> +	 */
> +	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> +		requested_crtc |= drm_crtc_mask(crtc);
>  
>  	ret = drm_atomic_check_only(state);
>  	if (ret)
>  		return ret;
>  
> -	DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> +	for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> +		affected_crtc |= drm_crtc_mask(crtc);
> +
> +	if (affected_crtc != requested_crtc) {
> +		/* adding other CRTC is only allowed for modeset commits */
> +		WARN_ON(!state->allow_modeset);

Not sure that's really true. What if the driver needs to eg.
redistribute FIFO space or something between the pipes? Or do we
expect drivers to now examine state->allow_modeset to figure out
if they're allowed to do certain things?

> +
> +		DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
> +		nonblocking = false;
> +	} else {
> +		DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> +	}
>  
> -	return config->funcs->atomic_commit(state->dev, state, true);
> +	return config->funcs->atomic_commit(state->dev, state, nonblocking);
>  }
>  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
>  
> -- 
> 2.24.1
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
  2020-02-25 14:48   ` Ville Syrjälä
  (?)
@ 2020-02-25 15:09     ` Daniel Vetter
  -1 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-02-25 15:09 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: DRI Development, Daniel Stone, Intel Graphics Development,
	stable, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > plug this problem by demoting nonblocking commits which might cause
> > issues by including CRTCs not in the original request to blocking
> > commits.
> >
> > 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).
> >
> > 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: stable@vger.kernel.org
> > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> >  1 file changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 9ccfbf213d72..4c035abf98b8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> >  {
> >       struct drm_mode_config *config = &state->dev->mode_config;
> > -     int ret;
> > +     unsigned requested_crtc = 0;
> > +     unsigned affected_crtc = 0;
> > +     struct drm_crtc *crtc;
> > +     struct drm_crtc_state *crtc_state;
> > +     bool nonblocking = true;
> > +     int ret, i;
> > +
> > +     /*
> > +      * For commits that allow modesets drivers can add other CRTCs to the
> > +      * atomic commit, e.g. when they need to reallocate global resources.
> > +      *
> > +      * But when userspace also requests a nonblocking commit then userspace
> > +      * cannot know that the commit affects other CRTCs, which can result in
> > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > +      * demoting such commits to blocking mode.
> > +      */
> > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +             requested_crtc |= drm_crtc_mask(crtc);
> >
> >       ret = drm_atomic_check_only(state);
> >       if (ret)
> >               return ret;
> >
> > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +             affected_crtc |= drm_crtc_mask(crtc);
> > +
> > +     if (affected_crtc != requested_crtc) {
> > +             /* adding other CRTC is only allowed for modeset commits */
> > +             WARN_ON(!state->allow_modeset);
>
> Not sure that's really true. What if the driver needs to eg.
> redistribute FIFO space or something between the pipes? Or do we
> expect drivers to now examine state->allow_modeset to figure out
> if they're allowed to do certain things?

Maybe we need more fine-grained flags here, but adding other states
(and blocking a commit flow) is exactly the uapi headaches this patch
tries to solve here. So if our driver currently adds crtc states to
reallocate fifo between pipes for an atomic flip then yes we're
breaking userspace. Well, everyone figured out by now that you get
random EBUSY and dropped frames for no apparent reason at all, and
work around it. But happy, they are not.

Also we've already crossed that bridge a bit with mucking around with
allow_modeset from driver code with the self refresh helpers.

Cheers, Daniel

>
> > +
> > +             DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
> > +             nonblocking = false;
> > +     } else {
> > +             DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > +     }
> >
> > -     return config->funcs->atomic_commit(state->dev, state, true);
> > +     return config->funcs->atomic_commit(state->dev, state, nonblocking);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
> >
> > --
> > 2.24.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 15:09     ` Daniel Vetter
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-02-25 15:09 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > plug this problem by demoting nonblocking commits which might cause
> > issues by including CRTCs not in the original request to blocking
> > commits.
> >
> > 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).
> >
> > 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: stable@vger.kernel.org
> > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> >  1 file changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 9ccfbf213d72..4c035abf98b8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> >  {
> >       struct drm_mode_config *config = &state->dev->mode_config;
> > -     int ret;
> > +     unsigned requested_crtc = 0;
> > +     unsigned affected_crtc = 0;
> > +     struct drm_crtc *crtc;
> > +     struct drm_crtc_state *crtc_state;
> > +     bool nonblocking = true;
> > +     int ret, i;
> > +
> > +     /*
> > +      * For commits that allow modesets drivers can add other CRTCs to the
> > +      * atomic commit, e.g. when they need to reallocate global resources.
> > +      *
> > +      * But when userspace also requests a nonblocking commit then userspace
> > +      * cannot know that the commit affects other CRTCs, which can result in
> > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > +      * demoting such commits to blocking mode.
> > +      */
> > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +             requested_crtc |= drm_crtc_mask(crtc);
> >
> >       ret = drm_atomic_check_only(state);
> >       if (ret)
> >               return ret;
> >
> > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +             affected_crtc |= drm_crtc_mask(crtc);
> > +
> > +     if (affected_crtc != requested_crtc) {
> > +             /* adding other CRTC is only allowed for modeset commits */
> > +             WARN_ON(!state->allow_modeset);
>
> Not sure that's really true. What if the driver needs to eg.
> redistribute FIFO space or something between the pipes? Or do we
> expect drivers to now examine state->allow_modeset to figure out
> if they're allowed to do certain things?

Maybe we need more fine-grained flags here, but adding other states
(and blocking a commit flow) is exactly the uapi headaches this patch
tries to solve here. So if our driver currently adds crtc states to
reallocate fifo between pipes for an atomic flip then yes we're
breaking userspace. Well, everyone figured out by now that you get
random EBUSY and dropped frames for no apparent reason at all, and
work around it. But happy, they are not.

Also we've already crossed that bridge a bit with mucking around with
allow_modeset from driver code with the self refresh helpers.

Cheers, Daniel

>
> > +
> > +             DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
> > +             nonblocking = false;
> > +     } else {
> > +             DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > +     }
> >
> > -     return config->funcs->atomic_commit(state->dev, state, true);
> > +     return config->funcs->atomic_commit(state->dev, state, nonblocking);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
> >
> > --
> > 2.24.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 15:09     ` Daniel Vetter
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-02-25 15:09 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > plug this problem by demoting nonblocking commits which might cause
> > issues by including CRTCs not in the original request to blocking
> > commits.
> >
> > 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).
> >
> > 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: stable@vger.kernel.org
> > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> >  1 file changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 9ccfbf213d72..4c035abf98b8 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> >  {
> >       struct drm_mode_config *config = &state->dev->mode_config;
> > -     int ret;
> > +     unsigned requested_crtc = 0;
> > +     unsigned affected_crtc = 0;
> > +     struct drm_crtc *crtc;
> > +     struct drm_crtc_state *crtc_state;
> > +     bool nonblocking = true;
> > +     int ret, i;
> > +
> > +     /*
> > +      * For commits that allow modesets drivers can add other CRTCs to the
> > +      * atomic commit, e.g. when they need to reallocate global resources.
> > +      *
> > +      * But when userspace also requests a nonblocking commit then userspace
> > +      * cannot know that the commit affects other CRTCs, which can result in
> > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > +      * demoting such commits to blocking mode.
> > +      */
> > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +             requested_crtc |= drm_crtc_mask(crtc);
> >
> >       ret = drm_atomic_check_only(state);
> >       if (ret)
> >               return ret;
> >
> > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > +             affected_crtc |= drm_crtc_mask(crtc);
> > +
> > +     if (affected_crtc != requested_crtc) {
> > +             /* adding other CRTC is only allowed for modeset commits */
> > +             WARN_ON(!state->allow_modeset);
>
> Not sure that's really true. What if the driver needs to eg.
> redistribute FIFO space or something between the pipes? Or do we
> expect drivers to now examine state->allow_modeset to figure out
> if they're allowed to do certain things?

Maybe we need more fine-grained flags here, but adding other states
(and blocking a commit flow) is exactly the uapi headaches this patch
tries to solve here. So if our driver currently adds crtc states to
reallocate fifo between pipes for an atomic flip then yes we're
breaking userspace. Well, everyone figured out by now that you get
random EBUSY and dropped frames for no apparent reason at all, and
work around it. But happy, they are not.

Also we've already crossed that bridge a bit with mucking around with
allow_modeset from driver code with the self refresh helpers.

Cheers, Daniel

>
> > +
> > +             DRM_DEBUG_ATOMIC("demoting %p to blocking mode to avoid EBUSY\n", state);
> > +             nonblocking = false;
> > +     } else {
> > +             DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > +     }
> >
> > -     return config->funcs->atomic_commit(state->dev, state, true);
> > +     return config->funcs->atomic_commit(state->dev, state, nonblocking);
> >  }
> >  EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
> >
> > --
> > 2.24.1
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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] 26+ messages in thread

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
  2020-02-25 15:09     ` Daniel Vetter
  (?)
@ 2020-02-25 15:34       ` Ville Syrjälä
  -1 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-02-25 15:34 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: DRI Development, Daniel Stone, Intel Graphics Development,
	stable, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > plug this problem by demoting nonblocking commits which might cause
> > > issues by including CRTCs not in the original request to blocking
> > > commits.
> > >
> > > 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).
> > >
> > > 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: stable@vger.kernel.org
> > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 9ccfbf213d72..4c035abf98b8 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > >  {
> > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > -     int ret;
> > > +     unsigned requested_crtc = 0;
> > > +     unsigned affected_crtc = 0;
> > > +     struct drm_crtc *crtc;
> > > +     struct drm_crtc_state *crtc_state;
> > > +     bool nonblocking = true;
> > > +     int ret, i;
> > > +
> > > +     /*
> > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > +      *
> > > +      * But when userspace also requests a nonblocking commit then userspace
> > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > +      * demoting such commits to blocking mode.
> > > +      */
> > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > +             requested_crtc |= drm_crtc_mask(crtc);
> > >
> > >       ret = drm_atomic_check_only(state);
> > >       if (ret)
> > >               return ret;
> > >
> > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > +
> > > +     if (affected_crtc != requested_crtc) {
> > > +             /* adding other CRTC is only allowed for modeset commits */
> > > +             WARN_ON(!state->allow_modeset);
> >
> > Not sure that's really true. What if the driver needs to eg.
> > redistribute FIFO space or something between the pipes? Or do we
> > expect drivers to now examine state->allow_modeset to figure out
> > if they're allowed to do certain things?
> 
> Maybe we need more fine-grained flags here, but adding other states
> (and blocking a commit flow) is exactly the uapi headaches this patch
> tries to solve here. So if our driver currently adds crtc states to
> reallocate fifo between pipes for an atomic flip then yes we're
> breaking userspace. Well, everyone figured out by now that you get
> random EBUSY and dropped frames for no apparent reason at all, and
> work around it. But happy, they are not.

I don't think we do this currently for the FIFO, but in theory we
could.

The one thing we might do currently is cdclk reprogramming, but that
can only happen without a full modeset when there's only a single
active pipe. So we shouldn't hit this right now. But that restriction
is going to disappear in the future, at which point we may want to
do this even with multiple active pipes.

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 15:34       ` Ville Syrjälä
  0 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-02-25 15:34 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > plug this problem by demoting nonblocking commits which might cause
> > > issues by including CRTCs not in the original request to blocking
> > > commits.
> > >
> > > 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).
> > >
> > > 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: stable@vger.kernel.org
> > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 9ccfbf213d72..4c035abf98b8 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > >  {
> > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > -     int ret;
> > > +     unsigned requested_crtc = 0;
> > > +     unsigned affected_crtc = 0;
> > > +     struct drm_crtc *crtc;
> > > +     struct drm_crtc_state *crtc_state;
> > > +     bool nonblocking = true;
> > > +     int ret, i;
> > > +
> > > +     /*
> > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > +      *
> > > +      * But when userspace also requests a nonblocking commit then userspace
> > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > +      * demoting such commits to blocking mode.
> > > +      */
> > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > +             requested_crtc |= drm_crtc_mask(crtc);
> > >
> > >       ret = drm_atomic_check_only(state);
> > >       if (ret)
> > >               return ret;
> > >
> > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > +
> > > +     if (affected_crtc != requested_crtc) {
> > > +             /* adding other CRTC is only allowed for modeset commits */
> > > +             WARN_ON(!state->allow_modeset);
> >
> > Not sure that's really true. What if the driver needs to eg.
> > redistribute FIFO space or something between the pipes? Or do we
> > expect drivers to now examine state->allow_modeset to figure out
> > if they're allowed to do certain things?
> 
> Maybe we need more fine-grained flags here, but adding other states
> (and blocking a commit flow) is exactly the uapi headaches this patch
> tries to solve here. So if our driver currently adds crtc states to
> reallocate fifo between pipes for an atomic flip then yes we're
> breaking userspace. Well, everyone figured out by now that you get
> random EBUSY and dropped frames for no apparent reason at all, and
> work around it. But happy, they are not.

I don't think we do this currently for the FIFO, but in theory we
could.

The one thing we might do currently is cdclk reprogramming, but that
can only happen without a full modeset when there's only a single
active pipe. So we shouldn't hit this right now. But that restriction
is going to disappear in the future, at which point we may want to
do this even with multiple active pipes.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-02-25 15:34       ` Ville Syrjälä
  0 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-02-25 15:34 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >
> > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > plug this problem by demoting nonblocking commits which might cause
> > > issues by including CRTCs not in the original request to blocking
> > > commits.
> > >
> > > 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).
> > >
> > > 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: stable@vger.kernel.org
> > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 9ccfbf213d72..4c035abf98b8 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > >  {
> > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > -     int ret;
> > > +     unsigned requested_crtc = 0;
> > > +     unsigned affected_crtc = 0;
> > > +     struct drm_crtc *crtc;
> > > +     struct drm_crtc_state *crtc_state;
> > > +     bool nonblocking = true;
> > > +     int ret, i;
> > > +
> > > +     /*
> > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > +      *
> > > +      * But when userspace also requests a nonblocking commit then userspace
> > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > +      * demoting such commits to blocking mode.
> > > +      */
> > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > +             requested_crtc |= drm_crtc_mask(crtc);
> > >
> > >       ret = drm_atomic_check_only(state);
> > >       if (ret)
> > >               return ret;
> > >
> > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > +
> > > +     if (affected_crtc != requested_crtc) {
> > > +             /* adding other CRTC is only allowed for modeset commits */
> > > +             WARN_ON(!state->allow_modeset);
> >
> > Not sure that's really true. What if the driver needs to eg.
> > redistribute FIFO space or something between the pipes? Or do we
> > expect drivers to now examine state->allow_modeset to figure out
> > if they're allowed to do certain things?
> 
> Maybe we need more fine-grained flags here, but adding other states
> (and blocking a commit flow) is exactly the uapi headaches this patch
> tries to solve here. So if our driver currently adds crtc states to
> reallocate fifo between pipes for an atomic flip then yes we're
> breaking userspace. Well, everyone figured out by now that you get
> random EBUSY and dropped frames for no apparent reason at all, and
> work around it. But happy, they are not.

I don't think we do this currently for the FIFO, but in theory we
could.

The one thing we might do currently is cdclk reprogramming, but that
can only happen without a full modeset when there's only a single
active pipe. So we shouldn't hit this right now. But that restriction
is going to disappear in the future, at which point we may want to
do this even with multiple active pipes.

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

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev4)
  2020-02-25 11:50 ` Daniel Vetter
                   ` (4 preceding siblings ...)
  (?)
@ 2020-03-06 22:45 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-03-06 22:45 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev4)
URL   : https://patchwork.freedesktop.org/series/45968/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
6cecc5b22da8 drm: avoid spurious EBUSY due to nonblocking atomic modesets
-:35: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#35: 
References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html

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

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

-:93: 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, 46 lines checked

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

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

* [Intel-gfx] ✗ Fi.CI.DOCS: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev4)
  2020-02-25 11:50 ` Daniel Vetter
                   ` (5 preceding siblings ...)
  (?)
@ 2020-03-06 23:00 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-03-06 23:00 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev4)
URL   : https://patchwork.freedesktop.org/series/45968/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs'

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

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

* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev4)
  2020-02-25 11:50 ` Daniel Vetter
                   ` (6 preceding siblings ...)
  (?)
@ 2020-03-06 23:11 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-03-06 23:11 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev4)
URL   : https://patchwork.freedesktop.org/series/45968/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8086 -> Patchwork_16864
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_16864 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_16864, 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_16864/index.html

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

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

### IGT changes ###

#### Possible regressions ####

  * igt@kms_busy@basic@modeset:
    - fi-apl-guc:         [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-apl-guc/igt@kms_busy@basic@modeset.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-apl-guc/igt@kms_busy@basic@modeset.html
    - fi-icl-dsi:         [PASS][3] -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-icl-dsi/igt@kms_busy@basic@modeset.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-icl-dsi/igt@kms_busy@basic@modeset.html
    - fi-bxt-dsi:         [PASS][5] -> [FAIL][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-bxt-dsi/igt@kms_busy@basic@modeset.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-bxt-dsi/igt@kms_busy@basic@modeset.html
    - fi-cfl-guc:         [PASS][7] -> [FAIL][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-cfl-guc/igt@kms_busy@basic@modeset.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-cfl-guc/igt@kms_busy@basic@modeset.html
    - fi-skl-6600u:       [PASS][9] -> [FAIL][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-skl-6600u/igt@kms_busy@basic@modeset.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-skl-6600u/igt@kms_busy@basic@modeset.html
    - fi-cml-s:           [PASS][11] -> [FAIL][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-cml-s/igt@kms_busy@basic@modeset.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-cml-s/igt@kms_busy@basic@modeset.html
    - fi-kbl-soraka:      [PASS][13] -> [FAIL][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-kbl-soraka/igt@kms_busy@basic@modeset.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-kbl-soraka/igt@kms_busy@basic@modeset.html
    - fi-bsw-n3050:       [PASS][15] -> [FAIL][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-bsw-n3050/igt@kms_busy@basic@modeset.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-bsw-n3050/igt@kms_busy@basic@modeset.html
    - fi-icl-guc:         [PASS][17] -> [FAIL][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-icl-guc/igt@kms_busy@basic@modeset.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-icl-guc/igt@kms_busy@basic@modeset.html
    - fi-skl-6700k2:      [PASS][19] -> [FAIL][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-skl-6700k2/igt@kms_busy@basic@modeset.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-skl-6700k2/igt@kms_busy@basic@modeset.html
    - fi-glk-dsi:         [PASS][21] -> [FAIL][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-glk-dsi/igt@kms_busy@basic@modeset.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-glk-dsi/igt@kms_busy@basic@modeset.html
    - fi-bsw-kefka:       [PASS][23] -> [FAIL][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-bsw-kefka/igt@kms_busy@basic@modeset.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-bsw-kefka/igt@kms_busy@basic@modeset.html
    - fi-skl-guc:         NOTRUN -> [FAIL][25]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-skl-guc/igt@kms_busy@basic@modeset.html
    - fi-kbl-x1275:       [PASS][26] -> [FAIL][27]
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-kbl-x1275/igt@kms_busy@basic@modeset.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-kbl-x1275/igt@kms_busy@basic@modeset.html
    - fi-kbl-7500u:       [PASS][28] -> [FAIL][29]
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-kbl-7500u/igt@kms_busy@basic@modeset.html
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-kbl-7500u/igt@kms_busy@basic@modeset.html
    - fi-cfl-8109u:       [PASS][30] -> [FAIL][31]
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-cfl-8109u/igt@kms_busy@basic@modeset.html
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-cfl-8109u/igt@kms_busy@basic@modeset.html
    - fi-icl-y:           [PASS][32] -> [FAIL][33]
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-icl-y/igt@kms_busy@basic@modeset.html
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-icl-y/igt@kms_busy@basic@modeset.html
    - fi-cfl-8700k:       [PASS][34] -> [FAIL][35]
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-cfl-8700k/igt@kms_busy@basic@modeset.html
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-cfl-8700k/igt@kms_busy@basic@modeset.html
    - fi-kbl-r:           [PASS][36] -> [FAIL][37]
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-kbl-r/igt@kms_busy@basic@modeset.html
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-kbl-r/igt@kms_busy@basic@modeset.html
    - fi-icl-u2:          [PASS][38] -> [FAIL][39]
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-icl-u2/igt@kms_busy@basic@modeset.html
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-icl-u2/igt@kms_busy@basic@modeset.html
    - fi-cml-u2:          [PASS][40] -> [FAIL][41]
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-cml-u2/igt@kms_busy@basic@modeset.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-cml-u2/igt@kms_busy@basic@modeset.html
    - fi-byt-j1900:       [PASS][42] -> [FAIL][43]
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-byt-j1900/igt@kms_busy@basic@modeset.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-byt-j1900/igt@kms_busy@basic@modeset.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_busy@basic@modeset:
    - {fi-tgl-u}:         [PASS][44] -> [FAIL][45]
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-tgl-u/igt@kms_busy@basic@modeset.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-tgl-u/igt@kms_busy@basic@modeset.html
    - {fi-tgl-dsi}:       [PASS][46] -> [FAIL][47]
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-tgl-dsi/igt@kms_busy@basic@modeset.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-tgl-dsi/igt@kms_busy@basic@modeset.html
    - {fi-ehl-1}:         [PASS][48] -> [FAIL][49]
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-ehl-1/igt@kms_busy@basic@modeset.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-ehl-1/igt@kms_busy@basic@modeset.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@kms_busy@basic@modeset:
    - fi-tgl-y:           [PASS][50] -> [FAIL][51] ([CI#94])
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-tgl-y/igt@kms_busy@basic@modeset.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-tgl-y/igt@kms_busy@basic@modeset.html

  * igt@prime_vgem@basic-gtt:
    - fi-tgl-y:           [PASS][52] -> [DMESG-WARN][53] ([CI#94] / [i915#402]) +1 similar issue
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-tgl-y/igt@prime_vgem@basic-gtt.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-tgl-y/igt@prime_vgem@basic-gtt.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@dmabuf:
    - fi-ivb-3770:        [DMESG-WARN][54] -> [PASS][55]
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-ivb-3770/igt@i915_selftest@live@dmabuf.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-ivb-3770/igt@i915_selftest@live@dmabuf.html

  * igt@i915_selftest@live@hangcheck:
    - fi-ivb-3770:        [INCOMPLETE][56] -> [PASS][57]
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-ivb-3770/igt@i915_selftest@live@hangcheck.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-ivb-3770/igt@i915_selftest@live@hangcheck.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-icl-u2:          [FAIL][58] ([i915#217]) -> [PASS][59]
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
    - fi-kbl-7500u:       [FAIL][60] ([fdo#111096] / [i915#323]) -> [PASS][61]
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

  * igt@prime_vgem@basic-fence-flip:
    - fi-tgl-y:           [DMESG-WARN][62] ([CI#94] / [i915#402]) -> [PASS][63] +1 similar issue
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8086/fi-tgl-y/igt@prime_vgem@basic-fence-flip.html
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/fi-tgl-y/igt@prime_vgem@basic-fence-flip.html

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

  [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402


Participating hosts (50 -> 43)
------------------------------

  Additional (1): fi-skl-guc 
  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-kbl-7560u fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8086 -> Patchwork_16864

  CI-20190529: 20190529
  CI_DRM_8086: 3a1e69684036738b540510ffcc31964600bc0b3f @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5498: 1bb7a25a09fe3e653d310e8bdfbdde4a1934b326 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16864: 6cecc5b22da8f6e9f3e1667e5c16dea4c110e858 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6cecc5b22da8 drm: avoid spurious EBUSY due to nonblocking atomic modesets

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16864/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev5)
  2020-02-25 11:50 ` Daniel Vetter
                   ` (7 preceding siblings ...)
  (?)
@ 2020-03-07  2:45 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-03-07  2:45 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev5)
URL   : https://patchwork.freedesktop.org/series/45968/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
bca7a2e764c5 drm: avoid spurious EBUSY due to nonblocking atomic modesets
-:35: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#35: 
References: https://lists.freedesktop.org/archives/dri-devel/2018-July/182281.html

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

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

-:93: 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, 46 lines checked

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

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

* [Intel-gfx] ✗ Fi.CI.DOCS: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev5)
  2020-02-25 11:50 ` Daniel Vetter
                   ` (8 preceding siblings ...)
  (?)
@ 2020-03-07  3:00 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-03-07  3:00 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev5)
URL   : https://patchwork.freedesktop.org/series/45968/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs'

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

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

* [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev5)
  2020-02-25 11:50 ` Daniel Vetter
                   ` (9 preceding siblings ...)
  (?)
@ 2020-03-07  3:15 ` Patchwork
  -1 siblings, 0 replies; 26+ messages in thread
From: Patchwork @ 2020-03-07  3:15 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev5)
URL   : https://patchwork.freedesktop.org/series/45968/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8088 -> Patchwork_16870
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_16870 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_16870, 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_16870/index.html

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

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

### IGT changes ###

#### Possible regressions ####

  * igt@kms_busy@basic@modeset:
    - fi-apl-guc:         [PASS][1] -> [FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-apl-guc/igt@kms_busy@basic@modeset.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-apl-guc/igt@kms_busy@basic@modeset.html
    - fi-icl-dsi:         [PASS][3] -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-icl-dsi/igt@kms_busy@basic@modeset.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-icl-dsi/igt@kms_busy@basic@modeset.html
    - fi-bxt-dsi:         [PASS][5] -> [FAIL][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-bxt-dsi/igt@kms_busy@basic@modeset.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-bxt-dsi/igt@kms_busy@basic@modeset.html
    - fi-cfl-guc:         [PASS][7] -> [FAIL][8]
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-cfl-guc/igt@kms_busy@basic@modeset.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-cfl-guc/igt@kms_busy@basic@modeset.html
    - fi-skl-6770hq:      [PASS][9] -> [FAIL][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-skl-6770hq/igt@kms_busy@basic@modeset.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-skl-6770hq/igt@kms_busy@basic@modeset.html
    - fi-cml-s:           [PASS][11] -> [FAIL][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-cml-s/igt@kms_busy@basic@modeset.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-cml-s/igt@kms_busy@basic@modeset.html
    - fi-kbl-soraka:      [PASS][13] -> [FAIL][14]
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-kbl-soraka/igt@kms_busy@basic@modeset.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-kbl-soraka/igt@kms_busy@basic@modeset.html
    - fi-icl-guc:         [PASS][15] -> [FAIL][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-icl-guc/igt@kms_busy@basic@modeset.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-icl-guc/igt@kms_busy@basic@modeset.html
    - fi-skl-6700k2:      [PASS][17] -> [FAIL][18]
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-skl-6700k2/igt@kms_busy@basic@modeset.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-skl-6700k2/igt@kms_busy@basic@modeset.html
    - fi-glk-dsi:         [PASS][19] -> [FAIL][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-glk-dsi/igt@kms_busy@basic@modeset.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-glk-dsi/igt@kms_busy@basic@modeset.html
    - fi-bsw-kefka:       [PASS][21] -> [FAIL][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-bsw-kefka/igt@kms_busy@basic@modeset.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-bsw-kefka/igt@kms_busy@basic@modeset.html
    - fi-skl-guc:         [PASS][23] -> [FAIL][24]
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-skl-guc/igt@kms_busy@basic@modeset.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-skl-guc/igt@kms_busy@basic@modeset.html
    - fi-kbl-x1275:       [PASS][25] -> [FAIL][26]
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-kbl-x1275/igt@kms_busy@basic@modeset.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-kbl-x1275/igt@kms_busy@basic@modeset.html
    - fi-kbl-7500u:       [PASS][27] -> [FAIL][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-kbl-7500u/igt@kms_busy@basic@modeset.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-kbl-7500u/igt@kms_busy@basic@modeset.html
    - fi-icl-y:           [PASS][29] -> [FAIL][30]
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-icl-y/igt@kms_busy@basic@modeset.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-icl-y/igt@kms_busy@basic@modeset.html
    - fi-cfl-8700k:       [PASS][31] -> [FAIL][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-cfl-8700k/igt@kms_busy@basic@modeset.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-cfl-8700k/igt@kms_busy@basic@modeset.html
    - fi-kbl-r:           [PASS][33] -> [FAIL][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-kbl-r/igt@kms_busy@basic@modeset.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-kbl-r/igt@kms_busy@basic@modeset.html
    - fi-icl-u2:          [PASS][35] -> [FAIL][36]
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-icl-u2/igt@kms_busy@basic@modeset.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-icl-u2/igt@kms_busy@basic@modeset.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_busy@basic@modeset:
    - {fi-tgl-u}:         [PASS][37] -> [FAIL][38]
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-tgl-u/igt@kms_busy@basic@modeset.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-tgl-u/igt@kms_busy@basic@modeset.html
    - {fi-tgl-dsi}:       NOTRUN -> [FAIL][39]
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-tgl-dsi/igt@kms_busy@basic@modeset.html
    - {fi-ehl-1}:         [PASS][40] -> [FAIL][41]
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-ehl-1/igt@kms_busy@basic@modeset.html
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-ehl-1/igt@kms_busy@basic@modeset.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_mmap_gtt@basic:
    - fi-tgl-y:           [PASS][42] -> [DMESG-WARN][43] ([CI#94] / [i915#402]) +1 similar issue
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-tgl-y/igt@gem_mmap_gtt@basic.html
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-tgl-y/igt@gem_mmap_gtt@basic.html

  * igt@i915_selftest@live@gem_contexts:
    - fi-cml-s:           [PASS][44] -> [DMESG-FAIL][45] ([i915#877])
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
    - fi-cfl-guc:         [PASS][46] -> [INCOMPLETE][47] ([fdo#106070] / [i915#424])
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-cfl-guc/igt@i915_selftest@live@gem_contexts.html

  * igt@kms_busy@basic@modeset:
    - fi-tgl-y:           [PASS][48] -> [FAIL][49] ([CI#94])
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-tgl-y/igt@kms_busy@basic@modeset.html
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-tgl-y/igt@kms_busy@basic@modeset.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@execlists:
    - fi-bsw-kefka:       [DMESG-FAIL][50] ([i915#1314]) -> [PASS][51]
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-bsw-kefka/igt@i915_selftest@live@execlists.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-bsw-kefka/igt@i915_selftest@live@execlists.html

  * igt@kms_addfb_basic@bo-too-small-due-to-tiling:
    - fi-tgl-y:           [DMESG-WARN][52] ([CI#94] / [i915#402]) -> [PASS][53] +1 similar issue
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-tgl-y/igt@kms_addfb_basic@bo-too-small-due-to-tiling.html
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-tgl-y/igt@kms_addfb_basic@bo-too-small-due-to-tiling.html

  * igt@kms_chamelium@dp-crc-fast:
    - fi-kbl-7500u:       [FAIL][54] ([fdo#109635] / [i915#217]) -> [PASS][55]
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-kbl-7500u/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       [FAIL][56] ([fdo#111096] / [i915#323]) -> [PASS][57]
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8088/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html

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

  [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
  [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
  [fdo#109635]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
  [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
  [i915#1314]: https://gitlab.freedesktop.org/drm/intel/issues/1314
  [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
  [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323
  [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
  [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
  [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877


Participating hosts (46 -> 36)
------------------------------

  Additional (2): fi-bwr-2160 fi-tgl-dsi 
  Missing    (12): fi-hsw-4770r fi-cml-u2 fi-bsw-n3050 fi-byt-j1900 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-gdg-551 fi-cfl-8109u fi-skl-lmem fi-skl-6600u fi-snb-2600 


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

  * CI: CI-20190529 -> None
  * Linux: CI_DRM_8088 -> Patchwork_16870

  CI-20190529: 20190529
  CI_DRM_8088: 91dc8b179da374160a6bbdbd6987a512a10fbc02 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5498: 1bb7a25a09fe3e653d310e8bdfbdde4a1934b326 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_16870: bca7a2e764c5f6afa4908e1d85d88a2d29538f96 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

bca7a2e764c5 drm: avoid spurious EBUSY due to nonblocking atomic modesets

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16870/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
  2020-02-25 15:34       ` Ville Syrjälä
  (?)
@ 2020-04-08 14:03         ` Ville Syrjälä
  -1 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-04-08 14:03 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Daniel Vetter, Pekka Paalanen

On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > plug this problem by demoting nonblocking commits which might cause
> > > > issues by including CRTCs not in the original request to blocking
> > > > commits.
> > > >
> > > > 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).
> > > >
> > > > 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: stable@vger.kernel.org
> > > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > >  {
> > > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > > -     int ret;
> > > > +     unsigned requested_crtc = 0;
> > > > +     unsigned affected_crtc = 0;
> > > > +     struct drm_crtc *crtc;
> > > > +     struct drm_crtc_state *crtc_state;
> > > > +     bool nonblocking = true;
> > > > +     int ret, i;
> > > > +
> > > > +     /*
> > > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > > +      *
> > > > +      * But when userspace also requests a nonblocking commit then userspace
> > > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > > +      * demoting such commits to blocking mode.
> > > > +      */
> > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > +             requested_crtc |= drm_crtc_mask(crtc);
> > > >
> > > >       ret = drm_atomic_check_only(state);
> > > >       if (ret)
> > > >               return ret;
> > > >
> > > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > > +
> > > > +     if (affected_crtc != requested_crtc) {
> > > > +             /* adding other CRTC is only allowed for modeset commits */
> > > > +             WARN_ON(!state->allow_modeset);
> > >
> > > Not sure that's really true. What if the driver needs to eg.
> > > redistribute FIFO space or something between the pipes? Or do we
> > > expect drivers to now examine state->allow_modeset to figure out
> > > if they're allowed to do certain things?
> > 
> > Maybe we need more fine-grained flags here, but adding other states
> > (and blocking a commit flow) is exactly the uapi headaches this patch
> > tries to solve here. So if our driver currently adds crtc states to
> > reallocate fifo between pipes for an atomic flip then yes we're
> > breaking userspace. Well, everyone figured out by now that you get
> > random EBUSY and dropped frames for no apparent reason at all, and
> > work around it. But happy, they are not.
> 
> I don't think we do this currently for the FIFO, but in theory we
> could.
> 
> The one thing we might do currently is cdclk reprogramming, but that
> can only happen without a full modeset when there's only a single
> active pipe. So we shouldn't hit this right now. But that restriction
> is going to disappear in the future, at which point we may want to
> do this even with multiple active pipes.

Looks like we're hitting something like this on some CI systems.
After a bit of pondering I guess we could fix that by not sending
out any flips events until all crtcs have finished the commit. Not
a full solution though as it can't help if there are multiple threads
trying to commit independently on different CRTC and one thread
happens to need a full modeset on all CRTCs. But seems like it
should solve the the single threaded CI fails we're seeing.

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-04-08 14:03         ` Ville Syrjälä
  0 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-04-08 14:03 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Stone, Intel Graphics Development, DRI Development,
	stable, Pekka Paalanen, Daniel Vetter

On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > plug this problem by demoting nonblocking commits which might cause
> > > > issues by including CRTCs not in the original request to blocking
> > > > commits.
> > > >
> > > > 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).
> > > >
> > > > 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: stable@vger.kernel.org
> > > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > >  {
> > > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > > -     int ret;
> > > > +     unsigned requested_crtc = 0;
> > > > +     unsigned affected_crtc = 0;
> > > > +     struct drm_crtc *crtc;
> > > > +     struct drm_crtc_state *crtc_state;
> > > > +     bool nonblocking = true;
> > > > +     int ret, i;
> > > > +
> > > > +     /*
> > > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > > +      *
> > > > +      * But when userspace also requests a nonblocking commit then userspace
> > > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > > +      * demoting such commits to blocking mode.
> > > > +      */
> > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > +             requested_crtc |= drm_crtc_mask(crtc);
> > > >
> > > >       ret = drm_atomic_check_only(state);
> > > >       if (ret)
> > > >               return ret;
> > > >
> > > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > > +
> > > > +     if (affected_crtc != requested_crtc) {
> > > > +             /* adding other CRTC is only allowed for modeset commits */
> > > > +             WARN_ON(!state->allow_modeset);
> > >
> > > Not sure that's really true. What if the driver needs to eg.
> > > redistribute FIFO space or something between the pipes? Or do we
> > > expect drivers to now examine state->allow_modeset to figure out
> > > if they're allowed to do certain things?
> > 
> > Maybe we need more fine-grained flags here, but adding other states
> > (and blocking a commit flow) is exactly the uapi headaches this patch
> > tries to solve here. So if our driver currently adds crtc states to
> > reallocate fifo between pipes for an atomic flip then yes we're
> > breaking userspace. Well, everyone figured out by now that you get
> > random EBUSY and dropped frames for no apparent reason at all, and
> > work around it. But happy, they are not.
> 
> I don't think we do this currently for the FIFO, but in theory we
> could.
> 
> The one thing we might do currently is cdclk reprogramming, but that
> can only happen without a full modeset when there's only a single
> active pipe. So we shouldn't hit this right now. But that restriction
> is going to disappear in the future, at which point we may want to
> do this even with multiple active pipes.

Looks like we're hitting something like this on some CI systems.
After a bit of pondering I guess we could fix that by not sending
out any flips events until all crtcs have finished the commit. Not
a full solution though as it can't help if there are multiple threads
trying to commit independently on different CRTC and one thread
happens to need a full modeset on all CRTCs. But seems like it
should solve the the single threaded CI fails we're seeing.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-04-08 14:03         ` Ville Syrjälä
  0 siblings, 0 replies; 26+ messages in thread
From: Ville Syrjälä @ 2020-04-08 14:03 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Daniel Stone, Intel Graphics Development, DRI Development,
	stable, Pekka Paalanen, Daniel Vetter

On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > plug this problem by demoting nonblocking commits which might cause
> > > > issues by including CRTCs not in the original request to blocking
> > > > commits.
> > > >
> > > > 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).
> > > >
> > > > 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: stable@vger.kernel.org
> > > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > >  {
> > > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > > -     int ret;
> > > > +     unsigned requested_crtc = 0;
> > > > +     unsigned affected_crtc = 0;
> > > > +     struct drm_crtc *crtc;
> > > > +     struct drm_crtc_state *crtc_state;
> > > > +     bool nonblocking = true;
> > > > +     int ret, i;
> > > > +
> > > > +     /*
> > > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > > +      *
> > > > +      * But when userspace also requests a nonblocking commit then userspace
> > > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > > +      * demoting such commits to blocking mode.
> > > > +      */
> > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > +             requested_crtc |= drm_crtc_mask(crtc);
> > > >
> > > >       ret = drm_atomic_check_only(state);
> > > >       if (ret)
> > > >               return ret;
> > > >
> > > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > > +
> > > > +     if (affected_crtc != requested_crtc) {
> > > > +             /* adding other CRTC is only allowed for modeset commits */
> > > > +             WARN_ON(!state->allow_modeset);
> > >
> > > Not sure that's really true. What if the driver needs to eg.
> > > redistribute FIFO space or something between the pipes? Or do we
> > > expect drivers to now examine state->allow_modeset to figure out
> > > if they're allowed to do certain things?
> > 
> > Maybe we need more fine-grained flags here, but adding other states
> > (and blocking a commit flow) is exactly the uapi headaches this patch
> > tries to solve here. So if our driver currently adds crtc states to
> > reallocate fifo between pipes for an atomic flip then yes we're
> > breaking userspace. Well, everyone figured out by now that you get
> > random EBUSY and dropped frames for no apparent reason at all, and
> > work around it. But happy, they are not.
> 
> I don't think we do this currently for the FIFO, but in theory we
> could.
> 
> The one thing we might do currently is cdclk reprogramming, but that
> can only happen without a full modeset when there's only a single
> active pipe. So we shouldn't hit this right now. But that restriction
> is going to disappear in the future, at which point we may want to
> do this even with multiple active pipes.

Looks like we're hitting something like this on some CI systems.
After a bit of pondering I guess we could fix that by not sending
out any flips events until all crtcs have finished the commit. Not
a full solution though as it can't help if there are multiple threads
trying to commit independently on different CRTC and one thread
happens to need a full modeset on all CRTCs. But seems like it
should solve the the single threaded CI fails we're seeing.

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
  2020-04-08 14:03         ` Ville Syrjälä
  (?)
@ 2020-04-08 15:34           ` Daniel Vetter
  -1 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-04-08 15:34 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Stone, Intel Graphics Development, DRI Development,
	stable, Pekka Paalanen, Daniel Vetter

On Wed, Apr 8, 2020 at 4:03 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > > plug this problem by demoting nonblocking commits which might cause
> > > > > issues by including CRTCs not in the original request to blocking
> > > > > commits.
> > > > >
> > > > > 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).
> > > > >
> > > > > 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: stable@vger.kernel.org
> > > > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > > > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > >  {
> > > > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > > > -     int ret;
> > > > > +     unsigned requested_crtc = 0;
> > > > > +     unsigned affected_crtc = 0;
> > > > > +     struct drm_crtc *crtc;
> > > > > +     struct drm_crtc_state *crtc_state;
> > > > > +     bool nonblocking = true;
> > > > > +     int ret, i;
> > > > > +
> > > > > +     /*
> > > > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > > > +      *
> > > > > +      * But when userspace also requests a nonblocking commit then userspace
> > > > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > > > +      * demoting such commits to blocking mode.
> > > > > +      */
> > > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > +             requested_crtc |= drm_crtc_mask(crtc);
> > > > >
> > > > >       ret = drm_atomic_check_only(state);
> > > > >       if (ret)
> > > > >               return ret;
> > > > >
> > > > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > > > +
> > > > > +     if (affected_crtc != requested_crtc) {
> > > > > +             /* adding other CRTC is only allowed for modeset commits */
> > > > > +             WARN_ON(!state->allow_modeset);
> > > >
> > > > Not sure that's really true. What if the driver needs to eg.
> > > > redistribute FIFO space or something between the pipes? Or do we
> > > > expect drivers to now examine state->allow_modeset to figure out
> > > > if they're allowed to do certain things?
> > >
> > > Maybe we need more fine-grained flags here, but adding other states
> > > (and blocking a commit flow) is exactly the uapi headaches this patch
> > > tries to solve here. So if our driver currently adds crtc states to
> > > reallocate fifo between pipes for an atomic flip then yes we're
> > > breaking userspace. Well, everyone figured out by now that you get
> > > random EBUSY and dropped frames for no apparent reason at all, and
> > > work around it. But happy, they are not.
> >
> > I don't think we do this currently for the FIFO, but in theory we
> > could.
> >
> > The one thing we might do currently is cdclk reprogramming, but that
> > can only happen without a full modeset when there's only a single
> > active pipe. So we shouldn't hit this right now. But that restriction
> > is going to disappear in the future, at which point we may want to
> > do this even with multiple active pipes.
>
> Looks like we're hitting something like this on some CI systems.
> After a bit of pondering I guess we could fix that by not sending
> out any flips events until all crtcs have finished the commit. Not
> a full solution though as it can't help if there are multiple threads
> trying to commit independently on different CRTC and one thread
> happens to need a full modeset on all CRTCs. But seems like it
> should solve the the single threaded CI fails we're seeing.

Well it's more annoying, since I typed this patch last we gained some
igt which actually check that we can push through commits
indepedently, which now fail on latest gen and so CI tells me "you
can't merge this patch".

Also note that this here is just a userspace api issue, ordering
commits more carefully can't fix anything here.

I guess maybe we should just merge this patch meanwhile and tell CI
that the breakage is expected.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-04-08 15:34           ` Daniel Vetter
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-04-08 15:34 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Pekka Paalanen, Daniel Vetter

On Wed, Apr 8, 2020 at 4:03 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > > plug this problem by demoting nonblocking commits which might cause
> > > > > issues by including CRTCs not in the original request to blocking
> > > > > commits.
> > > > >
> > > > > 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).
> > > > >
> > > > > 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: stable@vger.kernel.org
> > > > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > > > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > >  {
> > > > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > > > -     int ret;
> > > > > +     unsigned requested_crtc = 0;
> > > > > +     unsigned affected_crtc = 0;
> > > > > +     struct drm_crtc *crtc;
> > > > > +     struct drm_crtc_state *crtc_state;
> > > > > +     bool nonblocking = true;
> > > > > +     int ret, i;
> > > > > +
> > > > > +     /*
> > > > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > > > +      *
> > > > > +      * But when userspace also requests a nonblocking commit then userspace
> > > > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > > > +      * demoting such commits to blocking mode.
> > > > > +      */
> > > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > +             requested_crtc |= drm_crtc_mask(crtc);
> > > > >
> > > > >       ret = drm_atomic_check_only(state);
> > > > >       if (ret)
> > > > >               return ret;
> > > > >
> > > > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > > > +
> > > > > +     if (affected_crtc != requested_crtc) {
> > > > > +             /* adding other CRTC is only allowed for modeset commits */
> > > > > +             WARN_ON(!state->allow_modeset);
> > > >
> > > > Not sure that's really true. What if the driver needs to eg.
> > > > redistribute FIFO space or something between the pipes? Or do we
> > > > expect drivers to now examine state->allow_modeset to figure out
> > > > if they're allowed to do certain things?
> > >
> > > Maybe we need more fine-grained flags here, but adding other states
> > > (and blocking a commit flow) is exactly the uapi headaches this patch
> > > tries to solve here. So if our driver currently adds crtc states to
> > > reallocate fifo between pipes for an atomic flip then yes we're
> > > breaking userspace. Well, everyone figured out by now that you get
> > > random EBUSY and dropped frames for no apparent reason at all, and
> > > work around it. But happy, they are not.
> >
> > I don't think we do this currently for the FIFO, but in theory we
> > could.
> >
> > The one thing we might do currently is cdclk reprogramming, but that
> > can only happen without a full modeset when there's only a single
> > active pipe. So we shouldn't hit this right now. But that restriction
> > is going to disappear in the future, at which point we may want to
> > do this even with multiple active pipes.
>
> Looks like we're hitting something like this on some CI systems.
> After a bit of pondering I guess we could fix that by not sending
> out any flips events until all crtcs have finished the commit. Not
> a full solution though as it can't help if there are multiple threads
> trying to commit independently on different CRTC and one thread
> happens to need a full modeset on all CRTCs. But seems like it
> should solve the the single threaded CI fails we're seeing.

Well it's more annoying, since I typed this patch last we gained some
igt which actually check that we can push through commits
indepedently, which now fail on latest gen and so CI tells me "you
can't merge this patch".

Also note that this here is just a userspace api issue, ordering
commits more carefully can't fix anything here.

I guess maybe we should just merge this patch meanwhile and tell CI
that the breakage is expected.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

* Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets
@ 2020-04-08 15:34           ` Daniel Vetter
  0 siblings, 0 replies; 26+ messages in thread
From: Daniel Vetter @ 2020-04-08 15:34 UTC (permalink / raw)
  To: Ville Syrjälä
  Cc: Daniel Stone, Intel Graphics Development, stable,
	DRI Development, Pekka Paalanen, Daniel Vetter

On Wed, Apr 8, 2020 at 4:03 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, Feb 25, 2020 at 05:34:00PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä
> > > <ville.syrjala@linux.intel.com> wrote:
> > > >
> > > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, 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. As a stop-gap
> > > > > plug this problem by demoting nonblocking commits which might cause
> > > > > issues by including CRTCs not in the original request to blocking
> > > > > commits.
> > > > >
> > > > > 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).
> > > > >
> > > > > 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: stable@vger.kernel.org
> > > > > Reviewed-by: Daniel Stone <daniels@collabora.com>
> > > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_atomic.c | 34 +++++++++++++++++++++++++++++++---
> > > > >  1 file changed, 31 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > > index 9ccfbf213d72..4c035abf98b8 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > > @@ -1362,15 +1362,43 @@ EXPORT_SYMBOL(drm_atomic_commit);
> > > > >  int drm_atomic_nonblocking_commit(struct drm_atomic_state *state)
> > > > >  {
> > > > >       struct drm_mode_config *config = &state->dev->mode_config;
> > > > > -     int ret;
> > > > > +     unsigned requested_crtc = 0;
> > > > > +     unsigned affected_crtc = 0;
> > > > > +     struct drm_crtc *crtc;
> > > > > +     struct drm_crtc_state *crtc_state;
> > > > > +     bool nonblocking = true;
> > > > > +     int ret, i;
> > > > > +
> > > > > +     /*
> > > > > +      * For commits that allow modesets drivers can add other CRTCs to the
> > > > > +      * atomic commit, e.g. when they need to reallocate global resources.
> > > > > +      *
> > > > > +      * But when userspace also requests a nonblocking commit then userspace
> > > > > +      * cannot know that the commit affects other CRTCs, which can result in
> > > > > +      * spurious EBUSY failures. Until we have better uapi plug this by
> > > > > +      * demoting such commits to blocking mode.
> > > > > +      */
> > > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > +             requested_crtc |= drm_crtc_mask(crtc);
> > > > >
> > > > >       ret = drm_atomic_check_only(state);
> > > > >       if (ret)
> > > > >               return ret;
> > > > >
> > > > > -     DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
> > > > > +     for_each_new_crtc_in_state(state, crtc, crtc_state, i)
> > > > > +             affected_crtc |= drm_crtc_mask(crtc);
> > > > > +
> > > > > +     if (affected_crtc != requested_crtc) {
> > > > > +             /* adding other CRTC is only allowed for modeset commits */
> > > > > +             WARN_ON(!state->allow_modeset);
> > > >
> > > > Not sure that's really true. What if the driver needs to eg.
> > > > redistribute FIFO space or something between the pipes? Or do we
> > > > expect drivers to now examine state->allow_modeset to figure out
> > > > if they're allowed to do certain things?
> > >
> > > Maybe we need more fine-grained flags here, but adding other states
> > > (and blocking a commit flow) is exactly the uapi headaches this patch
> > > tries to solve here. So if our driver currently adds crtc states to
> > > reallocate fifo between pipes for an atomic flip then yes we're
> > > breaking userspace. Well, everyone figured out by now that you get
> > > random EBUSY and dropped frames for no apparent reason at all, and
> > > work around it. But happy, they are not.
> >
> > I don't think we do this currently for the FIFO, but in theory we
> > could.
> >
> > The one thing we might do currently is cdclk reprogramming, but that
> > can only happen without a full modeset when there's only a single
> > active pipe. So we shouldn't hit this right now. But that restriction
> > is going to disappear in the future, at which point we may want to
> > do this even with multiple active pipes.
>
> Looks like we're hitting something like this on some CI systems.
> After a bit of pondering I guess we could fix that by not sending
> out any flips events until all crtcs have finished the commit. Not
> a full solution though as it can't help if there are multiple threads
> trying to commit independently on different CRTC and one thread
> happens to need a full modeset on all CRTCs. But seems like it
> should solve the the single threaded CI fails we're seeing.

Well it's more annoying, since I typed this patch last we gained some
igt which actually check that we can push through commits
indepedently, which now fail on latest gen and so CI tells me "you
can't merge this patch".

Also note that this here is just a userspace api issue, ordering
commits more carefully can't fix anything here.

I guess maybe we should just merge this patch meanwhile and tell CI
that the breakage is expected.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - 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] 26+ messages in thread

end of thread, other threads:[~2020-04-08 15:34 UTC | newest]

Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-25 11:50 [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets Daniel Vetter
2020-02-25 11:50 ` [Intel-gfx] " Daniel Vetter
2020-02-25 11:50 ` Daniel Vetter
2020-02-25 13:46 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev3) Patchwork
2020-02-25 14:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-02-25 14:48 ` [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets Ville Syrjälä
2020-02-25 14:48   ` Ville Syrjälä
2020-02-25 14:48   ` Ville Syrjälä
2020-02-25 15:09   ` Daniel Vetter
2020-02-25 15:09     ` Daniel Vetter
2020-02-25 15:09     ` Daniel Vetter
2020-02-25 15:34     ` Ville Syrjälä
2020-02-25 15:34       ` Ville Syrjälä
2020-02-25 15:34       ` Ville Syrjälä
2020-04-08 14:03       ` Ville Syrjälä
2020-04-08 14:03         ` Ville Syrjälä
2020-04-08 14:03         ` Ville Syrjälä
2020-04-08 15:34         ` Daniel Vetter
2020-04-08 15:34           ` Daniel Vetter
2020-04-08 15:34           ` Daniel Vetter
2020-03-06 22:45 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev4) Patchwork
2020-03-06 23:00 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2020-03-06 23:11 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-03-07  2:45 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: avoid spurious EBUSY due to nonblocking atomic modesets (rev5) Patchwork
2020-03-07  3:00 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2020-03-07  3:15 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.