From: Rob Clark <robdclark@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org,
"Rob Clark" <robdclark@chromium.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Gustavo Padovan" <gustavo@padovan.org>,
"Christian König" <christian.koenig@amd.com>,
linux-media@vger.kernel.org (open list:SYNC FILE FRAMEWORK),
linaro-mm-sig@lists.linaro.org (moderated list:DMA BUFFER
SHARING FRAMEWORK), linux-kernel@vger.kernel.org (open list)
Subject: [PATCH 01/13] dma-buf/dma-fence: Add dma_fence_init_noref()
Date: Sun, 12 Mar 2023 13:41:29 -0700 [thread overview]
Message-ID: <20230312204150.1353517-2-robdclark@gmail.com> (raw)
In-Reply-To: <20230312204150.1353517-1-robdclark@gmail.com>
From: Rob Clark <robdclark@chromium.org>
Add a way to initialize a fence without touching the refcount. This is
useful, for example, if the fence is embedded in a drm_sched_job. In
this case the refcount will be initialized before the job is queued.
But the seqno of the hw_fence is not known until job_run().
Signed-off-by: Rob Clark <robdclark@chromium.org>
---
drivers/dma-buf/dma-fence.c | 43 ++++++++++++++++++++++++++++---------
include/linux/dma-fence.h | 2 ++
2 files changed, 35 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 0de0482cd36e..3c55f946084c 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -929,28 +929,27 @@ void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq)
EXPORT_SYMBOL(dma_fence_describe);
/**
- * dma_fence_init - Initialize a custom fence.
+ * dma_fence_init_noref - Initialize a custom fence without initializing refcount.
* @fence: the fence to initialize
* @ops: the dma_fence_ops for operations on this fence
* @lock: the irqsafe spinlock to use for locking this fence
* @context: the execution context this fence is run on
* @seqno: a linear increasing sequence number for this context
*
- * Initializes an allocated fence, the caller doesn't have to keep its
- * refcount after committing with this fence, but it will need to hold a
- * refcount again if &dma_fence_ops.enable_signaling gets called.
- *
- * context and seqno are used for easy comparison between fences, allowing
- * to check which fence is later by simply using dma_fence_later().
+ * Like &dma_fence_init but does not initialize the refcount. Suitable
+ * for cases where the fence is embedded in another struct which has it's
+ * refcount initialized before the fence is initialized. Such as embedding
+ * in a &drm_sched_job, where the job is created before knowing the seqno
+ * of the hw_fence.
*/
void
-dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
- spinlock_t *lock, u64 context, u64 seqno)
+dma_fence_init_noref(struct dma_fence *fence, const struct dma_fence_ops *ops,
+ spinlock_t *lock, u64 context, u64 seqno)
{
BUG_ON(!lock);
BUG_ON(!ops || !ops->get_driver_name || !ops->get_timeline_name);
+ BUG_ON(!kref_read(&fence->refcount));
- kref_init(&fence->refcount);
fence->ops = ops;
INIT_LIST_HEAD(&fence->cb_list);
fence->lock = lock;
@@ -961,4 +960,28 @@ dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
trace_dma_fence_init(fence);
}
+EXPORT_SYMBOL(dma_fence_init_noref);
+
+/**
+ * dma_fence_init - Initialize a custom fence.
+ * @fence: the fence to initialize
+ * @ops: the dma_fence_ops for operations on this fence
+ * @lock: the irqsafe spinlock to use for locking this fence
+ * @context: the execution context this fence is run on
+ * @seqno: a linear increasing sequence number for this context
+ *
+ * Initializes an allocated fence, the caller doesn't have to keep its
+ * refcount after committing with this fence, but it will need to hold a
+ * refcount again if &dma_fence_ops.enable_signaling gets called.
+ *
+ * context and seqno are used for easy comparison between fences, allowing
+ * to check which fence is later by simply using dma_fence_later().
+ */
+void
+dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
+ spinlock_t *lock, u64 context, u64 seqno)
+{
+ kref_init(&fence->refcount);
+ dma_fence_init_noref(fence, ops, lock, context, seqno);
+}
EXPORT_SYMBOL(dma_fence_init);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 775cdc0b4f24..89d90a2b5f09 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -259,6 +259,8 @@ struct dma_fence_ops {
char *str, int size);
};
+void dma_fence_init_noref(struct dma_fence *fence, const struct dma_fence_ops *ops,
+ spinlock_t *lock, u64 context, u64 seqno);
void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
spinlock_t *lock, u64 context, u64 seqno);
--
2.39.2
next prev parent reply other threads:[~2023-03-12 20:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-12 20:41 [PATCH 00/13] drm/msm+PM+icc: Make job_run() reclaim-safe Rob Clark
2023-03-12 20:41 ` Rob Clark [this message]
2023-03-12 20:41 ` [PATCH 02/13] drm/msm: Embed the hw_fence in msm_gem_submit Rob Clark
2023-03-12 20:41 ` [PATCH 03/13] drm/msm/gpu: Move fw loading out of hw_init() path Rob Clark
2023-03-12 20:41 ` [PATCH 04/13] drm/msm/gpu: Move BO allocation out of hw_init Rob Clark
2023-03-12 20:41 ` [PATCH 05/13] drm/msm/a6xx: Move ioremap out of hw_init path Rob Clark
2023-03-12 20:41 ` [PATCH 06/13] PM / devfreq: Drop unneed locking to appease lockdep Rob Clark
2023-03-12 20:41 ` [PATCH 07/13] PM / devfreq: Teach lockdep about locking order Rob Clark
2023-03-12 20:41 ` [PATCH 08/13] PM / QoS: Fix constraints alloc vs reclaim locking Rob Clark
2023-03-13 12:29 ` Rafael J. Wysocki
2023-03-12 20:41 ` [PATCH 09/13] PM / QoS: Decouple request alloc from dev_pm_qos_mtx Rob Clark
2023-03-12 20:41 ` [PATCH 10/13] PM / QoS: Teach lockdep about dev_pm_qos_mtx locking order Rob Clark
2023-03-13 12:31 ` Rafael J. Wysocki
2023-03-13 14:46 ` Rob Clark
2023-03-12 20:41 ` [PATCH 11/13] soc: qcom: smd-rpm: Use GFP_ATOMIC in write path Rob Clark
2023-03-12 20:41 ` [PATCH 12/13] interconnect: Fix locking for runpm vs reclaim Rob Clark
2023-03-12 20:41 ` [PATCH 13/13] interconnect: Teach lockdep about icc_bw_lock order Rob Clark
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=20230312204150.1353517-2-robdclark@gmail.com \
--to=robdclark@gmail.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=robdclark@chromium.org \
--cc=sumit.semwal@linaro.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