From: Andrzej Hajda <andrzej.hajda@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, stable@vger.kernel.org
Cc: Andi Shyti <andi.shyti@kernel.org>,
Maciej Patelczyk <maciej.patelczyk@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [Intel-gfx] [PATCH v5 3/5] drm/i915: Create the locked version of the request add
Date: Wed, 12 Apr 2023 15:06:42 +0200 [thread overview]
Message-ID: <d00d6c70-67a7-0bed-eeb2-96260da4beec@intel.com> (raw)
In-Reply-To: <20230412113308.812468-4-andi.shyti@linux.intel.com>
On 12.04.2023 13:33, Andi Shyti wrote:
> i915_request_add() assumes that the timeline is locked whtn the
*when
> 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
Have you looked for other potential users of these new helpers?
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Regards
Andrzej
> ---
> 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);
WARNING: multiple messages have this Message-ID (diff)
From: Andrzej Hajda <andrzej.hajda@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
stable@vger.kernel.org
Cc: Matthew Auld <matthew.auld@intel.com>,
Maciej Patelczyk <maciej.patelczyk@intel.com>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
Nirmoy Das <nirmoy.das@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Andi Shyti <andi.shyti@kernel.org>
Subject: Re: [PATCH v5 3/5] drm/i915: Create the locked version of the request add
Date: Wed, 12 Apr 2023 15:06:42 +0200 [thread overview]
Message-ID: <d00d6c70-67a7-0bed-eeb2-96260da4beec@intel.com> (raw)
In-Reply-To: <20230412113308.812468-4-andi.shyti@linux.intel.com>
On 12.04.2023 13:33, Andi Shyti wrote:
> i915_request_add() assumes that the timeline is locked whtn the
*when
> 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
Have you looked for other potential users of these new helpers?
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Regards
Andrzej
> ---
> 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);
WARNING: multiple messages have this Message-ID (diff)
From: Andrzej Hajda <andrzej.hajda@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, stable@vger.kernel.org
Cc: Andi Shyti <andi.shyti@kernel.org>,
Maciej Patelczyk <maciej.patelczyk@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Chris Wilson <chris.p.wilson@linux.intel.com>,
Nirmoy Das <nirmoy.das@intel.com>
Subject: Re: [PATCH v5 3/5] drm/i915: Create the locked version of the request add
Date: Wed, 12 Apr 2023 15:06:42 +0200 [thread overview]
Message-ID: <d00d6c70-67a7-0bed-eeb2-96260da4beec@intel.com> (raw)
In-Reply-To: <20230412113308.812468-4-andi.shyti@linux.intel.com>
On 12.04.2023 13:33, Andi Shyti wrote:
> i915_request_add() assumes that the timeline is locked whtn the
*when
> 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
Have you looked for other potential users of these new helpers?
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Regards
Andrzej
> ---
> 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);
next prev parent reply other threads:[~2023-04-12 13:06 UTC|newest]
Thread overview: 47+ 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 ` Andi Shyti
2023-04-12 11:33 ` 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 11:33 ` Andi Shyti
2023-04-12 11:33 ` Andi Shyti
2023-04-12 12:12 ` [Intel-gfx] " Andrzej Hajda
2023-04-12 12:12 ` Andrzej Hajda
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 11:33 ` Andi Shyti
2023-04-12 11:33 ` Andi Shyti
2023-04-12 13:04 ` [Intel-gfx] " Andrzej Hajda
2023-04-12 13:04 ` Andrzej Hajda
2023-04-12 13:04 ` Andrzej Hajda
2023-04-13 8:53 ` [Intel-gfx] " Andi Shyti
2023-04-13 8:53 ` Andi Shyti
2023-04-13 8:53 ` Andi Shyti
2023-04-12 11:33 ` [Intel-gfx] [PATCH v5 3/5] drm/i915: Create the locked version of the request add Andi Shyti
2023-04-12 11:33 ` Andi Shyti
2023-04-12 11:33 ` Andi Shyti
2023-04-12 13:06 ` Andrzej Hajda [this message]
2023-04-12 13:06 ` Andrzej Hajda
2023-04-12 13:06 ` Andrzej Hajda
2023-04-13 8:57 ` [Intel-gfx] " Andi Shyti
2023-04-13 8:57 ` Andi Shyti
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 ` Andi Shyti
2023-04-12 11:33 ` 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-12 11:33 ` Andi Shyti
2023-04-12 11:33 ` Andi Shyti
2023-04-13 11:56 ` [Intel-gfx] " Tvrtko Ursulin
2023-04-13 11:56 ` Tvrtko Ursulin
2023-04-13 12:43 ` Tvrtko Ursulin
2023-04-13 12:43 ` Tvrtko Ursulin
2023-05-04 9:45 ` Andi Shyti
2023-05-04 9:45 ` Andi Shyti
2023-05-04 9:45 ` Andi Shyti
2023-05-04 9:37 ` Andi Shyti
2023-05-04 9:37 ` 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=d00d6c70-67a7-0bed-eeb2-96260da4beec@intel.com \
--to=andrzej.hajda@intel.com \
--cc=andi.shyti@kernel.org \
--cc=andi.shyti@linux.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 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.