From: Vinod Koul <vkoul@kernel.org>
To: Paul Cercueil <paul@crapouillou.net>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
"Christian König" <christian.koenig@amd.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Nuno Sa" <nuno.sa@analog.com>,
"Michael Hennerich" <michael.hennerich@analog.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
dmaengine@vger.kernel.org, linux-iio@vger.kernel.org,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH v9 1/6] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec()
Date: Thu, 28 Mar 2024 11:53:16 +0530 [thread overview]
Message-ID: <ZgUM1LFEWs3lwoAU@matsya> (raw)
In-Reply-To: <20240310124836.31863-2-paul@crapouillou.net>
On 10-03-24, 13:48, Paul Cercueil wrote:
> This function can be used to initiate a scatter-gather DMA transfer,
> where the address and size of each segment is located in one entry of
> the dma_vec array.
>
> The major difference with dmaengine_prep_slave_sg() is that it supports
> specifying the lengths of each DMA transfer; as trying to override the
> length of the transfer with dmaengine_prep_slave_sg() is a very tedious
> process. The introduction of a new API function is also justified by the
> fact that scatterlists are on their way out.
>
> Note that dmaengine_prep_interleaved_dma() is not helpful either in that
> case, as it assumes that the address of each segment will be higher than
> the one of the previous segment, which we just cannot guarantee in case
> of a scatter-gather transfer.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Signed-off-by: Nuno Sa <nuno.sa@analog.com>
>
> ---
> v3: New patch
>
> v5: Replace with function dmaengine_prep_slave_dma_vec(), and struct
> 'dma_vec'.
> Note that at some point we will need to support cyclic transfers
> using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
> parameter to the function?
>
> v7:
> - Renamed *device_prep_slave_dma_vec() -> device_prep_peripheral_dma_vec();
> - Added a new flag parameter to the function as agreed between Paul
> and Vinod. I renamed the first parameter to prep_flags as it's supposed to
> be used (I think) with enum dma_ctrl_flags. I'm not really sure how that API
> can grow but I was thinking in just having a bool cyclic parameter (as the
> first intention of the flags is to support cyclic transfers) but ended up
> "respecting" the previously agreed approach.
> ---
> include/linux/dmaengine.h | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 752dbde4cec1..856df8cd9a4e 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -160,6 +160,16 @@ struct dma_interleaved_template {
> struct data_chunk sgl[];
> };
>
> +/**
> + * struct dma_vec - DMA vector
> + * @addr: Bus address of the start of the vector
> + * @len: Length in bytes of the DMA vector
> + */
> +struct dma_vec {
> + dma_addr_t addr;
> + size_t len;
> +};
> +
> /**
> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> * control completion, and communicate status.
> @@ -910,6 +920,10 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan, unsigned long flags);
>
> + struct dma_async_tx_descriptor *(*device_prep_peripheral_dma_vec)(
> + struct dma_chan *chan, const struct dma_vec *vecs,
> + size_t nents, enum dma_transfer_direction direction,
> + unsigned long prep_flags, unsigned long flags);
> struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> @@ -973,6 +987,19 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
> + struct dma_chan *chan, const struct dma_vec *vecs, size_t nents,
> + enum dma_transfer_direction dir, unsigned long prep_flags,
> + unsigned long flags)
> +{
> + if (!chan || !chan->device || !chan->device->device_prep_peripheral_dma_vec)
> + return NULL;
> +
> + return chan->device->device_prep_peripheral_dma_vec(chan, vecs, nents,
> + dir, prep_flags,
> + flags);
> +}
API looks good to me, thanks
Few nits though:
- Can we add kernel-doc for this new API please
- Also update the documentation adding this new api
- Lastly, we seem to have two flags, I know you have added a comment but
I dont seem to recall the discussion (looked at old threads for clue
as well), can you please remind me why we need both? And in your case,
what is the intended usage of these flags, i would prefer single
clean one...
--
~Vinod
next prev parent reply other threads:[~2024-03-28 6:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-10 12:48 [PATCH v9 0/6] iio: new DMABUF based API Paul Cercueil
2024-03-10 12:48 ` [PATCH v9 1/6] dmaengine: Add API function dmaengine_prep_peripheral_dma_vec() Paul Cercueil
2024-03-28 6:23 ` Vinod Koul [this message]
2024-04-02 11:31 ` Paul Cercueil
2024-04-07 8:19 ` Vinod Koul
2024-03-10 12:48 ` [PATCH v9 2/6] dmaengine: dma-axi-dmac: Implement device_prep_peripheral_dma_vec Paul Cercueil
2024-03-10 12:48 ` [PATCH v9 3/6] iio: core: Add new DMABUF interface infrastructure Paul Cercueil
2024-03-27 17:21 ` Andrew Davis
2024-03-27 18:48 ` Paul Cercueil
2024-03-10 12:48 ` [PATCH v9 4/6] iio: buffer-dma: Enable support for DMABUFs Paul Cercueil
2024-03-10 12:48 ` [PATCH v9 5/6] iio: buffer-dmaengine: Support new DMABUF based userspace API Paul Cercueil
2024-03-10 12:48 ` [PATCH v9 6/6] Documentation: iio: Document high-speed DMABUF based API Paul Cercueil
2024-03-24 11:10 ` [PATCH v9 0/6] iio: new " Jonathan Cameron
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=ZgUM1LFEWs3lwoAU@matsya \
--to=vkoul@kernel.org \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dmaengine@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jic23@kernel.org \
--cc=lars@metafoo.de \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=nuno.sa@analog.com \
--cc=paul@crapouillou.net \
--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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).