From: "Nuno Sá" <noname.nuno@gmail.com>
To: David Lechner <dlechner@baylibre.com>
Cc: nuno.sa@analog.com, linux-iio@vger.kernel.org,
Jonathan Cameron <jic23@kernel.org>,
Andy Shevchenko <andy@kernel.org>
Subject: Re: [PATCH] iio: buffer-dmaengine: Add support for cyclic DMA transfers
Date: Mon, 15 Jun 2026 09:21:02 +0100 [thread overview]
Message-ID: <ai-0CIqteaSJJkau@nsa> (raw)
In-Reply-To: <e05dddef-2ffc-4ab6-8ce7-f676b7801eff@baylibre.com>
On Sat, Jun 13, 2026 at 11:33:36AM -0500, David Lechner wrote:
> On 6/11/26 10:28 AM, Nuno Sá via B4 Relay wrote:
> > From: Nuno Sá <nuno.sa@analog.com>
> >
> > Allow buffer blocks flagged as cyclic to be submitted as repeating DMA
> > transfers. For cyclic blocks, use DMA_PREP_REPEAT so the engine keeps
> > replaying the descriptor.
>
> Is this for both directions (e.g ADCs and DACs) or only one?
We just have usecases of TX buffers. IIRC, there should be some
validation (some layers above in the call chain) not allowing cyclic RX.
>
> >
> > Skip installing the completion callback for cyclic blocks. Since the
> > transfer is continuously replayed, the callback would fire on every
> > period, throwing off the block refcount.
> >
> > Because nothing prevents a new cyclic transfer from replacing an
> > already active cyclic one, always set DMA_PREP_LOAD_EOT so the engine
> > correctly terminates the active transfer before loading the new
> > descriptor.
>
> Is there more to come after this to actually make use of it? Or is there
> a way to use this with DMABUF from userspace already?
Yes. One can do TX cyclic DMA transfer today. Some waveforms examples:
https://github.com/analogdevicesinc/iio-oscilloscope/tree/main/waveforms
For normal non cyclic transfers, libiio also handles DMABUF just fine.
Best way to use it is with USB where we support zero copy between IIO
and the USB stack.
>
> >
> > Signed-off-by: Nuno Sá <nuno.sa@analog.com>
> > ---
> > There's one subtle choice in here. Given that the termination callback
> > is not set. We will never give the block refcount. That means cyclic
> > blocks are only completely freed when we disable the buffer and
> > iio_dmaengine_buffer_abort() get's called. So no leak, we just defer it
> > as it makes it more simple to handle. I also think this a fair
> > expectation from a cyclic transfer. We set it up and let it run until we
> > disable the buffer.
>
> Makes sense.
>
> >
> > Alternatively, we can give in the refcount as soon as we give the block
> > to the DMA layer with dma_async_issue_pending(). But we also need to
> > make sure that the block is not added to the dmaengine_buffer->active list.
> > As said, I feel that the current approach is just simpler.
> > ---
> > drivers/iio/buffer/industrialio-buffer-dmaengine.c | 19 ++++++++++++++++---
> > 1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > index 98acce909854..4a78cd3e7c7d 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > @@ -80,6 +80,8 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > dma_dir = DMA_MEM_TO_DEV;
> >
> > if (block->sg_table) {
> > + unsigned long flags;
> > +
> > sgl = block->sg_table->sgl;
> > nents = sg_nents_for_len(sgl, block->bytes_used);
> > if (nents < 0)
> > @@ -99,9 +101,18 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > sgl = sg_next(sgl);
> > }
> >
> > + if (block->cyclic)
> > + flags = DMA_PREP_REPEAT;
> > + else
> > + flags = DMA_PREP_INTERRUPT;
> > +
> > + /*
> > + * There's nothing preventing a cyclic transfer to replace an active
> > + * cyclic one. So always set the EOT flag.
>
> What about the non-cyclic case?
Non cyclic will also have DMA_PREP_LOAD_EOT which should stop an ongoing
cyclic transfer. If there's an active, non cyclic, it's business as
usual. The transfer get's queued and will fire after the current one
ends. IOW, DMA_PREP_LOAD_EOT is only meaningful for active cyclic
transfers (it's ignored for non-cyclic)
- Nuno Sá
>
> > + */
> > desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
> > vecs, nents, dma_dir,
> > - DMA_PREP_INTERRUPT);
> > + flags | DMA_PREP_LOAD_EOT);
> > kfree(vecs);
> > } else {
> > max_size = min(block->size, dmaengine_buffer->max_size);
> > @@ -122,8 +133,10 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > if (!desc)
> > return -ENOMEM;
> >
> > - desc->callback_result = iio_dmaengine_buffer_block_done;
> > - desc->callback_param = block;
> > + if (!block->cyclic) {
> > + desc->callback_result = iio_dmaengine_buffer_block_done;
> > + desc->callback_param = block;
> > + }
> >
> > cookie = dmaengine_submit(desc);
> > if (dma_submit_error(cookie))
> >
> > ---
> > base-commit: ae696dfa47c30016cd429b9db5e70b259b8f509e
> > change-id: 20260609-iio-dma-cyclic-buffer-support-f18034f8f34c
> > --
> >
> > Thanks!
> > - Nuno Sá
> >
> >
>
prev parent reply other threads:[~2026-06-15 8:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-11 15:28 [PATCH] iio: buffer-dmaengine: Add support for cyclic DMA transfers Nuno Sá via B4 Relay
2026-06-13 16:33 ` David Lechner
2026-06-15 8:21 ` Nuno Sá [this message]
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=ai-0CIqteaSJJkau@nsa \
--to=noname.nuno@gmail.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=nuno.sa@analog.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox