From: Ben Walker <benjamin.walker@intel.com>
To: vkoul@kernel.org
Cc: dmaengine@vger.kernel.org, dave.jiang@intel.com,
Ben Walker <benjamin.walker@intel.com>
Subject: [RESEND 07/10] dmaengine: Add provider documentation on cookie assignment
Date: Tue, 1 Feb 2022 13:38:10 -0700 [thread overview]
Message-ID: <20220201203813.3951461-8-benjamin.walker@intel.com> (raw)
In-Reply-To: <20220201203813.3951461-1-benjamin.walker@intel.com>
Clarify the rules on assigning cookies to DMA transactions.
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
---
.../driver-api/dmaengine/provider.rst | 45 +++++++++++++++----
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst
index e9e9de18d6b02..7c8ace703c96f 100644
--- a/Documentation/driver-api/dmaengine/provider.rst
+++ b/Documentation/driver-api/dmaengine/provider.rst
@@ -421,7 +421,9 @@ supported.
- tx_submit: A pointer to a function you have to implement,
that is supposed to push the current transaction descriptor to a
- pending queue, waiting for issue_pending to be called.
+ pending queue, waiting for issue_pending to be called. Each
+ descriptor is given a cookie to identify it. See the section
+ "Cookie Management" below.
- In this structure the function pointer callback_result can be
initialized in order for the submitter to be notified that a
@@ -526,6 +528,40 @@ supported.
- May sleep.
+Cookie Management
+------------------
+
+When a transaction is queued for submission via tx_submit(), the provider
+must assign that transaction a cookie (dma_cookie_t) to uniquely identify it.
+The provider is allowed to perform this assignment however it wants, but for
+convenience the following utility functions are available to create
+monotonically increasing cookies
+
+ .. code-block:: c
+
+ void dma_cookie_init(struct dma_chan *chan);
+
+ Called once at channel creation
+
+ .. code-block:: c
+
+ dma_cookie_t dma_cookie_assign(struct dma_async_tx_descriptor *tx);
+
+ Assign a cookie to the given descriptor
+
+ .. code-block:: c
+
+ void dma_cookie_complete(struct dma_async_tx_descriptor *tx);
+
+ Mark the descriptor as complete and invalidate the cookie
+
+ .. code-block:: c
+
+ enum dma_status dma_cookie_status(struct dma_chan *chan,
+ dma_cookie_t cookie, struct dma_tx_state *state);
+
+ Report the status of the cookie and filling in state, if not NULL.
+
Misc notes
==========
@@ -541,13 +577,6 @@ where to put them)
- Makes sure that dependent operations are run before marking it
as complete.
-dma_cookie_t
-
-- it's a DMA transaction ID.
-
-- The value can be chosen by the provider, or use the helper APIs
- such as dma_cookie_assign() and dma_cookie_complete().
-
DMA_CTRL_ACK
- If clear, the descriptor cannot be reused by provider until the
--
2.33.1
next prev parent reply other threads:[~2022-02-01 20:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-01 20:38 [RESEND 00/10] Support polling for out of order completions Ben Walker
2022-02-01 20:38 ` [RESEND 01/10] dmaengine: Remove dma_async_is_complete from client API Ben Walker
2022-02-01 20:38 ` [RESEND 02/10] dmaengine: Move dma_set_tx_state to the provider API header Ben Walker
2022-02-01 20:38 ` [RESEND 03/10] dmaengine: Remove the last, used parameters in dma_async_is_tx_complete Ben Walker
2022-05-03 14:13 ` Vinod Koul
2022-05-03 17:56 ` Walker, Benjamin
2022-02-01 20:38 ` [RESEND 04/10] dmaengine: Remove last, used from dma_tx_state Ben Walker
2022-02-01 20:38 ` [RESEND 05/10] dmaengine: Providers should prefer dma_set_residue over dma_set_tx_state Ben Walker
2022-02-01 20:38 ` [RESEND 06/10] dmaengine: Remove dma_set_tx_state Ben Walker
2022-02-01 20:38 ` Ben Walker [this message]
2022-02-01 20:38 ` [RESEND 08/10] dmaengine: idxd: idxd_desc.id is now a u16 Ben Walker
2022-02-01 20:38 ` [RESEND 09/10] dmaengine: idxd: Support device_tx_status Ben Walker
2022-02-01 20:38 ` [RESEND 10/10] dmaengine: Revert "cookie bypass for out of order completion" Ben Walker
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=20220201203813.3951461-8-benjamin.walker@intel.com \
--to=benjamin.walker@intel.com \
--cc=dave.jiang@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=vkoul@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.