From: Andi Shyti <andi.shyti@linux.intel.com>
To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
stable@vger.kernel.org
Cc: Maciej Patelczyk <maciej.patelczyk@intel.com>,
Andi Shyti <andi.shyti@kernel.org>,
Matthew Auld <matthew.auld@intel.com>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: [Intel-gfx] [PATCH v5 3/5] drm/i915: Create the locked version of the request add
Date: Wed, 12 Apr 2023 13:33:06 +0200 [thread overview]
Message-ID: <20230412113308.812468-4-andi.shyti@linux.intel.com> (raw)
In-Reply-To: <20230412113308.812468-1-andi.shyti@linux.intel.com>
i915_request_add() assumes that the timeline is locked whtn the
function is called. Before exiting it releases the lock. But in
the next commit we have one case where releasing the timeline
mutex is not necessary and we don't want that.
Make a new i915_request_add_locked() version of the function
where the lock is not released.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/i915/i915_request.c | 14 +++++++++++---
drivers/gpu/drm/i915/i915_request.h | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 58662360ac34e..21032b3b9d330 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1852,13 +1852,13 @@ void __i915_request_queue(struct i915_request *rq,
local_bh_enable(); /* kick tasklets */
}
-void i915_request_add(struct i915_request *rq)
+void i915_request_add_locked(struct i915_request *rq)
{
struct intel_timeline * const tl = i915_request_timeline(rq);
struct i915_sched_attr attr = {};
struct i915_gem_context *ctx;
- lockdep_assert_held(&tl->mutex);
+ intel_context_assert_timeline_is_locked(tl);
lockdep_unpin_lock(&tl->mutex, rq->cookie);
trace_i915_request_add(rq);
@@ -1873,7 +1873,15 @@ void i915_request_add(struct i915_request *rq)
__i915_request_queue(rq, &attr);
- mutex_unlock(&tl->mutex);
+}
+
+void i915_request_add(struct i915_request *rq)
+{
+ struct intel_timeline * const tl = i915_request_timeline(rq);
+
+ i915_request_add_locked(rq);
+
+ intel_context_timeline_unlock(tl);
}
static unsigned long local_clock_ns(unsigned int *cpu)
diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h
index bb48bd4605c03..29e3a37c300a7 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -425,6 +425,7 @@ int i915_request_await_deps(struct i915_request *rq, const struct i915_deps *dep
int i915_request_await_execution(struct i915_request *rq,
struct dma_fence *fence);
+void i915_request_add_locked(struct i915_request *rq);
void i915_request_add(struct i915_request *rq);
bool __i915_request_submit(struct i915_request *request);
--
2.39.2
next prev parent reply other threads:[~2023-04-12 11:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 11:33 [Intel-gfx] [PATCH v5 0/5] Fix error propagation amongst request Andi Shyti
2023-04-12 11:33 ` [Intel-gfx] [PATCH v5 1/5] drm/i915/gt: Add intel_context_timeline_is_locked helper Andi Shyti
2023-04-12 12:12 ` Andrzej Hajda
2023-04-12 11:33 ` [Intel-gfx] [PATCH v5 2/5] drm/i915: Create the locked version of the request create Andi Shyti
2023-04-12 13:04 ` Andrzej Hajda
2023-04-13 8:53 ` Andi Shyti
2023-04-12 11:33 ` Andi Shyti [this message]
2023-04-12 13:06 ` [Intel-gfx] [PATCH v5 3/5] drm/i915: Create the locked version of the request add Andrzej Hajda
2023-04-13 8:57 ` Andi Shyti
2023-04-12 11:33 ` [Intel-gfx] [PATCH v5 4/5] drm/i915: Throttle for ringspace prior to taking the timeline mutex Andi Shyti
2023-04-12 11:33 ` [Intel-gfx] [PATCH v5 5/5] drm/i915/gt: Make sure that errors are propagated through request chains Andi Shyti
2023-04-13 11:56 ` Tvrtko Ursulin
2023-04-13 12:43 ` Tvrtko Ursulin
2023-05-04 9:45 ` Andi Shyti
2023-05-04 9:37 ` Andi Shyti
2023-04-12 17:28 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fix error propagation amongst request (rev3) Patchwork
2023-04-12 17:28 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-04-12 17:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-13 3:47 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
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=20230412113308.812468-4-andi.shyti@linux.intel.com \
--to=andi.shyti@linux.intel.com \
--cc=andi.shyti@kernel.org \
--cc=andrzej.hajda@intel.com \
--cc=chris.p.wilson@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maciej.patelczyk@intel.com \
--cc=matthew.auld@intel.com \
--cc=nirmoy.das@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=stable@vger.kernel.org \
/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