public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Ville Syrjala <ville.syrjala@linux.intel.com>
To: dri-devel@lists.freedesktop.org
Cc: "Pekka Paalanen" <pekka.paalanen@collabora.com>,
	"Jonas Ådahl" <jadahl@gmail.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org,
	"Simon Ser" <contact@emersion.fr>
Subject: [Intel-gfx] [PATCH 4/4] drm/i915: Make blocking commits lockless
Date: Fri, 16 Sep 2022 19:33:31 +0300	[thread overview]
Message-ID: <20220916163331.6849-5-ville.syrjala@linux.intel.com> (raw)
In-Reply-To: <20220916163331.6849-1-ville.syrjala@linux.intel.com>

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

Make blocking commits execute locklessly (just as nonblocking
commits do) by scheduling them onto the workqueues as well.
There will be a later flush_work() done by whoever called
the commit hook to make sure the blocking behaviour of the
ioctl/etc. is preserved.

I also wondered about just dropping the locks straight from the
driver, but I guess whoever called us might still depend on
having the locks so that seems like a terrible idea. Also calling
commit_tail() directly when not holding the locks would then
allow eg. two ioctls to execute full modesets in parallel,
which we don't want as we haven't fully evaluated all modeset
codepaths for concurrency issues. Currently we achieve serial
excution with a combination of an ordered workqueue (for
nonblocking commits) and reliance on the singular connection_mutex
(for blocking commits), and a flush_workqueue() to sync between
the two.

So by always scheduling everything onto the workqueues we
don't have to worry about racing between the lockless direct
commit_tail() calls, and we don't need some kind of new atomic
hook that would do said call for us after dropping the locks.
Also less codepaths in general seems like a beneficial thing.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/display/intel_display.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index cd617046e0ee..18a5f14e7f41 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7771,15 +7771,10 @@ static int intel_atomic_commit(struct drm_device *dev,
 	INIT_WORK(&state->base.commit_work, intel_atomic_commit_work);
 
 	i915_sw_fence_commit(&state->commit_ready);
-	if (nonblock && state->modeset) {
+	if (state->modeset)
 		queue_work(dev_priv->display.wq.modeset, &state->base.commit_work);
-	} else if (nonblock) {
+	else
 		queue_work(dev_priv->display.wq.flip, &state->base.commit_work);
-	} else {
-		if (state->modeset)
-			flush_workqueue(dev_priv->display.wq.modeset);
-		intel_atomic_commit_tail(state);
-	}
 
 	return 0;
 }
-- 
2.35.1


  parent reply	other threads:[~2022-09-16 16:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16 16:33 [Intel-gfx] [PATCH 0/4] drm/atomic: Lockless blocking commits Ville Syrjala
2022-09-16 16:33 ` [Intel-gfx] [PATCH 1/4] drm/atomic: Treat a nonblocking commit following a blocking commit as blocking commit Ville Syrjala
2022-09-16 16:33 ` [Intel-gfx] [PATCH 2/4] drm/i915: Don't reuse commit_work for the cleanup Ville Syrjala
2022-09-16 16:33 ` [Intel-gfx] [PATCH 3/4] drm/atomic: Allow lockless blocking commits Ville Syrjala
2022-09-16 16:33 ` Ville Syrjala [this message]
2022-09-16 18:09 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/atomic: Lockless " Patchwork
2022-09-16 18:28 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-09-16 22:57 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-09-20  7:34 ` [Intel-gfx] [PATCH 0/4] " Pekka Paalanen
2022-09-26 15:32   ` Ville Syrjälä

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220916163331.6849-5-ville.syrjala@linux.intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=contact@emersion.fr \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jadahl@gmail.com \
    --cc=pekka.paalanen@collabora.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox