From: Daniel Vetter <daniel@ffwll.ch>
To: Matthew Auld <matthew.auld@intel.com>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH 1/2] dma-fence: export dma_fence_might_wait
Date: Tue, 6 Jul 2021 11:14:01 +0200 [thread overview]
Message-ID: <YOQe2fdqTzqyyV9L@phenom.ffwll.local> (raw)
In-Reply-To: <20210706090559.1589544-1-matthew.auld@intel.com>
On Tue, Jul 06, 2021 at 10:05:58AM +0100, Matthew Auld wrote:
> It might be useful for drivers to annotate a path where hitting the
> actual wait path might be difficult or unlikely through normal testing.
>
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/dma-buf/dma-fence.c | 19 ++++++++++++++++---
> include/linux/dma-fence.h | 2 ++
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index ce0f5eff575d..f2cd036b5243 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -335,6 +335,21 @@ void __dma_fence_might_wait(void)
> }
> #endif
>
> +/**
> + * dma_fence_might_wait - entering a section which might wait on DMA fence
> + * critical section.
> + *
> + * This is also potentially useful for drivers to call directly, when annotating
> + * a path where hitting the actual wait path might be difficult or unlikely
> + * through normal testing.
Maybe also add a
"See also dma_fence_begin_signalling() and dma_fence_end_signalling."
here and a similar note the these two functions pointing at
dma_fence_might_wait()? I do like to link things together when there's a
group of functions.
With that: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> + */
> +void dma_fence_might_wait(void)
> +{
> + might_sleep();
> + __dma_fence_might_wait();
> +}
> +EXPORT_SYMBOL(dma_fence_might_wait);
> +
>
> /**
> * dma_fence_signal_timestamp_locked - signal completion of a fence
> @@ -495,9 +510,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout)
> if (WARN_ON(timeout < 0))
> return -EINVAL;
>
> - might_sleep();
> -
> - __dma_fence_might_wait();
> + dma_fence_might_wait();
>
> trace_dma_fence_wait_start(fence);
> if (fence->ops->wait)
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 6ffb4b2c6371..37bf4beed93f 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -370,6 +370,8 @@ static inline void dma_fence_end_signalling(bool cookie) {}
> static inline void __dma_fence_might_wait(void) {}
> #endif
>
> +void dma_fence_might_wait(void);
> +
> int dma_fence_signal(struct dma_fence *fence);
> int dma_fence_signal_locked(struct dma_fence *fence);
> int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp);
> --
> 2.26.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Matthew Auld <matthew.auld@intel.com>
Cc: "Daniel Vetter" <daniel.vetter@ffwll.ch>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH 1/2] dma-fence: export dma_fence_might_wait
Date: Tue, 6 Jul 2021 11:14:01 +0200 [thread overview]
Message-ID: <YOQe2fdqTzqyyV9L@phenom.ffwll.local> (raw)
In-Reply-To: <20210706090559.1589544-1-matthew.auld@intel.com>
On Tue, Jul 06, 2021 at 10:05:58AM +0100, Matthew Auld wrote:
> It might be useful for drivers to annotate a path where hitting the
> actual wait path might be difficult or unlikely through normal testing.
>
> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/dma-buf/dma-fence.c | 19 ++++++++++++++++---
> include/linux/dma-fence.h | 2 ++
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index ce0f5eff575d..f2cd036b5243 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -335,6 +335,21 @@ void __dma_fence_might_wait(void)
> }
> #endif
>
> +/**
> + * dma_fence_might_wait - entering a section which might wait on DMA fence
> + * critical section.
> + *
> + * This is also potentially useful for drivers to call directly, when annotating
> + * a path where hitting the actual wait path might be difficult or unlikely
> + * through normal testing.
Maybe also add a
"See also dma_fence_begin_signalling() and dma_fence_end_signalling."
here and a similar note the these two functions pointing at
dma_fence_might_wait()? I do like to link things together when there's a
group of functions.
With that: Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> + */
> +void dma_fence_might_wait(void)
> +{
> + might_sleep();
> + __dma_fence_might_wait();
> +}
> +EXPORT_SYMBOL(dma_fence_might_wait);
> +
>
> /**
> * dma_fence_signal_timestamp_locked - signal completion of a fence
> @@ -495,9 +510,7 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool intr, signed long timeout)
> if (WARN_ON(timeout < 0))
> return -EINVAL;
>
> - might_sleep();
> -
> - __dma_fence_might_wait();
> + dma_fence_might_wait();
>
> trace_dma_fence_wait_start(fence);
> if (fence->ops->wait)
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 6ffb4b2c6371..37bf4beed93f 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -370,6 +370,8 @@ static inline void dma_fence_end_signalling(bool cookie) {}
> static inline void __dma_fence_might_wait(void) {}
> #endif
>
> +void dma_fence_might_wait(void);
> +
> int dma_fence_signal(struct dma_fence *fence);
> int dma_fence_signal_locked(struct dma_fence *fence);
> int dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp);
> --
> 2.26.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2021-07-06 9:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-06 9:05 [Intel-gfx] [PATCH 1/2] dma-fence: export dma_fence_might_wait Matthew Auld
2021-07-06 9:05 ` Matthew Auld
2021-07-06 9:05 ` [Intel-gfx] [PATCH 2/2] drm/i915: prefer dma_fence_might_wait in wait_migration Matthew Auld
2021-07-06 9:05 ` Matthew Auld
2021-07-06 9:14 ` [Intel-gfx] " Daniel Vetter
2021-07-06 9:14 ` Daniel Vetter
2021-07-06 9:14 ` Daniel Vetter [this message]
2021-07-06 9:14 ` [PATCH 1/2] dma-fence: export dma_fence_might_wait Daniel Vetter
2021-07-06 9:15 ` [Intel-gfx] " Daniel Vetter
2021-07-06 9:15 ` Daniel Vetter
2021-07-06 9:34 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] " Patchwork
2021-07-06 10:03 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-07-06 14:11 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] dma-fence: export dma_fence_might_wait (rev2) Patchwork
2021-07-06 14:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-07-06 15:56 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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=YOQe2fdqTzqyyV9L@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=thomas.hellstrom@linux.intel.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 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.