[PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[Nuno Sá via B4 Relay]

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.

This is useful for output buffers where the same data should be driven
continuously without userspace having to requeue it. Examples include
continuous RF transmit paths replaying a calibration, test or beacon
pattern.

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.

Limit the DMA buffer queue to one cyclic DMABUF at a time. There is
currently no known use case for queueing multiple cyclic blocks, and
cyclic blocks stay referenced until the buffer is disabled.

Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
Changes in v2:
* Improved commit message for usecase;
* Safety cap cyclic transfers to one  (see v1 for context).
* Link to v1: https://lore.kernel.org/linux-iio/20260611-iio-dma-cyclic-buffer-support-v1-1-bcf00e8d802c@analog.com/
---
 drivers/iio/buffer/industrialio-buffer-dmaengine.c | 41 ++++++++++++++++++++--
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
index 98acce909854..639bac135539 100644
--- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
+++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
@@ -56,6 +56,23 @@ static void iio_dmaengine_buffer_block_done(void *data,
 	iio_dma_buffer_block_done(block);
 }
 
+/*
+ * Cyclic transfers run until abort. Cap active cyclic blocks to one until there
+ * is a use case for more.
+ */
+static bool iio_dmaengine_buffer_has_active_cyclic(struct dmaengine_buffer *dmaengine_buffer)
+{
+	struct iio_dma_buffer_block *block;
+
+	guard(spinlock_irqsave)(&dmaengine_buffer->queue.list_lock);
+	list_for_each_entry(block, &dmaengine_buffer->active, head) {
+		if (block->cyclic)
+			return true;
+	}
+
+	return false;
+}
+
 static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
 					     struct iio_dma_buffer_block *block)
 {
@@ -79,7 +96,14 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
 	else
 		dma_dir = DMA_MEM_TO_DEV;
 
+	if (block->cyclic && iio_dmaengine_buffer_has_active_cyclic(dmaengine_buffer)) {
+		dev_err(queue->dev, "cyclic DMA transfer already active\n");
+		return -EBUSY;
+	}
+
 	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 +123,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;
+
+		/*
+		 * A new transfer may need to end an already active cyclic transfer
+		 * before it can run, so always set the EOT flag.
+		 */
 		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 +155,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: aa58ecc73466d0cb8c418de98e2225490bf600e3
change-id: 20260714-iio-dma-cyclic-02ad77c2cc40
--

Thanks!
- Nuno Sá

Re: [PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[Andy Shevchenko]

On Wed, Jul 15, 2026 at 01:24:53PM +0200, Nuno Sá via B4 Relay wrote:

> 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.
> 
> This is useful for output buffers where the same data should be driven
> continuously without userspace having to requeue it. Examples include
> continuous RF transmit paths replaying a calibration, test or beacon
> pattern.
> 
> 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.
> 
> Limit the DMA buffer queue to one cyclic DMABUF at a time. There is
> currently no known use case for queueing multiple cyclic blocks, and
> cyclic blocks stay referenced until the buffer is disabled.

...

>  static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
>  					     struct iio_dma_buffer_block *block)

> +		if (block->cyclic)
> +			flags = DMA_PREP_REPEAT;
> +		else
> +			flags = DMA_PREP_INTERRUPT;
> +
> +		/*
> +		 * A new transfer may need to end an already active cyclic transfer
> +		 * before it can run, so always set the EOT flag.
> +		 */
>  		desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
>  							 vecs, nents, dma_dir,
> -							 DMA_PREP_INTERRUPT);
> +							 flags | DMA_PREP_LOAD_EOT);

Logically I would expect this to be a separate line with the above comment.

		/*
		 * ...comment...
		 */
		flags |= DMA_PREP_LOAD_EOT;
		...
							flags);

>  		kfree(vecs);

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[Nuno Sá]

On Wed, Jul 15, 2026 at 05:23:13PM +0300, Andy Shevchenko wrote:
> On Wed, Jul 15, 2026 at 01:24:53PM +0200, Nuno Sá via B4 Relay wrote:
> 
> > 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.
> > 
> > This is useful for output buffers where the same data should be driven
> > continuously without userspace having to requeue it. Examples include
> > continuous RF transmit paths replaying a calibration, test or beacon
> > pattern.
> > 
> > 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.
> > 
> > Limit the DMA buffer queue to one cyclic DMABUF at a time. There is
> > currently no known use case for queueing multiple cyclic blocks, and
> > cyclic blocks stay referenced until the buffer is disabled.
> 
> ...
> 
> >  static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> >  					     struct iio_dma_buffer_block *block)
> 
> > +		if (block->cyclic)
> > +			flags = DMA_PREP_REPEAT;
> > +		else
> > +			flags = DMA_PREP_INTERRUPT;
> > +
> > +		/*
> > +		 * A new transfer may need to end an already active cyclic transfer
> > +		 * before it can run, so always set the EOT flag.
> > +		 */
> >  		desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
> >  							 vecs, nents, dma_dir,
> > -							 DMA_PREP_INTERRUPT);
> > +							 flags | DMA_PREP_LOAD_EOT);
> 
> Logically I would expect this to be a separate line with the above comment.

Hmm I can agree to some extent. I guess it makes sense, yes. OTOH, it´s close
enough to be clear what's happening. Anyways, can spin v3 if you feel
strong about it (will anyways wait for Jonathan to take a look to make
sure this the only pending concern).

- Nuno Sá
> 
> 		/*
> 		 * ...comment...
> 		 */
> 		flags |= DMA_PREP_LOAD_EOT;
> 		...
> 							flags);
> 
> >  		kfree(vecs);
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 

Re: [PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[Andy Shevchenko]

On Wed, Jul 15, 2026 at 05:13:32PM +0200, Nuno Sá wrote:
> On Wed, Jul 15, 2026 at 05:23:13PM +0300, Andy Shevchenko wrote:
> > On Wed, Jul 15, 2026 at 01:24:53PM +0200, Nuno Sá via B4 Relay wrote:

...

> > >  static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > >  					     struct iio_dma_buffer_block *block)
> > 
> > > +		if (block->cyclic)
> > > +			flags = DMA_PREP_REPEAT;
> > > +		else
> > > +			flags = DMA_PREP_INTERRUPT;
> > > +
> > > +		/*
> > > +		 * A new transfer may need to end an already active cyclic transfer
> > > +		 * before it can run, so always set the EOT flag.
> > > +		 */
> > >  		desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
> > >  							 vecs, nents, dma_dir,
> > > -							 DMA_PREP_INTERRUPT);
> > > +							 flags | DMA_PREP_LOAD_EOT);
> > 
> > Logically I would expect this to be a separate line with the above comment.
> 
> Hmm I can agree to some extent. I guess it makes sense, yes. OTOH, it´s close
> enough to be clear what's happening.

Close, but not enough in my opinion. This currently is spread over pure flags
manipulation and API calls.

> Anyways, can spin v3 if you feel
> strong about it (will anyways wait for Jonathan to take a look to make
> sure this the only pending concern).

Not so strong, but lean towards my version. Let's wait for his review and
decide if it will be tweaked whilst applying or next version.

> > 		/*
> > 		 * ...comment...
> > 		 */
> > 		flags |= DMA_PREP_LOAD_EOT;
> > 		...
> > 							flags);
> > 
> > >  		kfree(vecs);

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[Jonathan Cameron]

On Wed, 15 Jul 2026 19:09:42 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Wed, Jul 15, 2026 at 05:13:32PM +0200, Nuno Sá wrote:
> > On Wed, Jul 15, 2026 at 05:23:13PM +0300, Andy Shevchenko wrote:  
> > > On Wed, Jul 15, 2026 at 01:24:53PM +0200, Nuno Sá via B4 Relay wrote:  
> 
> ...
> 
> > > >  static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > > >  					     struct iio_dma_buffer_block *block)  
> > >   
> > > > +		if (block->cyclic)
> > > > +			flags = DMA_PREP_REPEAT;
> > > > +		else
> > > > +			flags = DMA_PREP_INTERRUPT;
> > > > +
> > > > +		/*
> > > > +		 * A new transfer may need to end an already active cyclic transfer
> > > > +		 * before it can run, so always set the EOT flag.
> > > > +		 */
> > > >  		desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
> > > >  							 vecs, nents, dma_dir,
> > > > -							 DMA_PREP_INTERRUPT);
> > > > +							 flags | DMA_PREP_LOAD_EOT);  
> > > 
> > > Logically I would expect this to be a separate line with the above comment.  
> > 
> > Hmm I can agree to some extent. I guess it makes sense, yes. OTOH, it´s close
> > enough to be clear what's happening.  
> 
> Close, but not enough in my opinion. This currently is spread over pure flags
> manipulation and API calls.
> 
> > Anyways, can spin v3 if you feel
> > strong about it (will anyways wait for Jonathan to take a look to make
> > sure this the only pending concern).  
> 
> Not so strong, but lean towards my version. Let's wait for his review and
> decide if it will be tweaked whilst applying or next version.
> 
Applied with this tweak.  Hopefully I didn't mess it up!

diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
index 639bac135539..ecc02a427b92 100644
--- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
+++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
@@ -132,9 +132,10 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
                 * A new transfer may need to end an already active cyclic transfer
                 * before it can run, so always set the EOT flag.
                 */
+               flags |= DMA_PREP_LOAD_EOT;
                desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
                                                         vecs, nents, dma_dir,
-                                                        flags | DMA_PREP_LOAD_EOT);
+                                                        flags);
                kfree(vecs);
        } else {
                max_size = min(block->size, dmaengine_buffer->max_size);

> > > 		/*
> > > 		 * ...comment...
> > > 		 */
> > > 		flags |= DMA_PREP_LOAD_EOT;
> > > 		...
> > > 							flags);
> > >   
> > > >  		kfree(vecs);  
> 

Re: [PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[Jonathan Cameron]

On Sun, 19 Jul 2026 03:00:57 +0100
Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> wrote:

> On Wed, 15 Jul 2026 19:09:42 +0300
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
> > On Wed, Jul 15, 2026 at 05:13:32PM +0200, Nuno Sá wrote:  
> > > On Wed, Jul 15, 2026 at 05:23:13PM +0300, Andy Shevchenko wrote:    
> > > > On Wed, Jul 15, 2026 at 01:24:53PM +0200, Nuno Sá via B4 Relay wrote:    
> > 
> > ...
> >   
> > > > >  static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > > > >  					     struct iio_dma_buffer_block *block)    
> > > >     
> > > > > +		if (block->cyclic)
> > > > > +			flags = DMA_PREP_REPEAT;
> > > > > +		else
> > > > > +			flags = DMA_PREP_INTERRUPT;
> > > > > +
> > > > > +		/*
> > > > > +		 * A new transfer may need to end an already active cyclic transfer
> > > > > +		 * before it can run, so always set the EOT flag.
> > > > > +		 */
> > > > >  		desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
> > > > >  							 vecs, nents, dma_dir,
> > > > > -							 DMA_PREP_INTERRUPT);
> > > > > +							 flags | DMA_PREP_LOAD_EOT);    
> > > > 
> > > > Logically I would expect this to be a separate line with the above comment.    
> > > 
> > > Hmm I can agree to some extent. I guess it makes sense, yes. OTOH, it´s close
> > > enough to be clear what's happening.    
> > 
> > Close, but not enough in my opinion. This currently is spread over pure flags
> > manipulation and API calls.
> >   
> > > Anyways, can spin v3 if you feel
> > > strong about it (will anyways wait for Jonathan to take a look to make
> > > sure this the only pending concern).    
> > 
> > Not so strong, but lean towards my version. Let's wait for his review and
> > decide if it will be tweaked whilst applying or next version.
> >   
> Applied with this tweak.  Hopefully I didn't mess it up!

I'll leave it on tree for now but I forgot to check sashiko and
it asks about plausible sounding races. Please take a look and
let me know if they are real and an update is needed:
https://sashiko.dev/#/patchset/20260715-iio-dma-cyclic-v2-1-268a3a28ff84%40analog.com

> 
> diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> index 639bac135539..ecc02a427b92 100644
> --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> @@ -132,9 +132,10 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
>                  * A new transfer may need to end an already active cyclic transfer
>                  * before it can run, so always set the EOT flag.
>                  */
> +               flags |= DMA_PREP_LOAD_EOT;
>                 desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
>                                                          vecs, nents, dma_dir,
> -                                                        flags | DMA_PREP_LOAD_EOT);
> +                                                        flags);
>                 kfree(vecs);
>         } else {
>                 max_size = min(block->size, dmaengine_buffer->max_size);
> 
> > > > 		/*
> > > > 		 * ...comment...
> > > > 		 */
> > > > 		flags |= DMA_PREP_LOAD_EOT;
> > > > 		...
> > > > 							flags);
> > > >     
> > > > >  		kfree(vecs);    
> >   
> 
> 

Re: [PATCH v2] iio: buffer-dmaengine: Add support for cyclic DMA transfers

[Nuno Sá]

On Sun, Jul 19, 2026 at 03:03:46AM +0100, Jonathan Cameron wrote:
> On Sun, 19 Jul 2026 03:00:57 +0100
> Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> wrote:
> 
> > On Wed, 15 Jul 2026 19:09:42 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> > 
> > > On Wed, Jul 15, 2026 at 05:13:32PM +0200, Nuno Sá wrote:  
> > > > On Wed, Jul 15, 2026 at 05:23:13PM +0300, Andy Shevchenko wrote:    
> > > > > On Wed, Jul 15, 2026 at 01:24:53PM +0200, Nuno Sá via B4 Relay wrote:    
> > > 
> > > ...
> > >   
> > > > > >  static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> > > > > >  					     struct iio_dma_buffer_block *block)    
> > > > >     
> > > > > > +		if (block->cyclic)
> > > > > > +			flags = DMA_PREP_REPEAT;
> > > > > > +		else
> > > > > > +			flags = DMA_PREP_INTERRUPT;
> > > > > > +
> > > > > > +		/*
> > > > > > +		 * A new transfer may need to end an already active cyclic transfer
> > > > > > +		 * before it can run, so always set the EOT flag.
> > > > > > +		 */
> > > > > >  		desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
> > > > > >  							 vecs, nents, dma_dir,
> > > > > > -							 DMA_PREP_INTERRUPT);
> > > > > > +							 flags | DMA_PREP_LOAD_EOT);    
> > > > > 
> > > > > Logically I would expect this to be a separate line with the above comment.    
> > > > 
> > > > Hmm I can agree to some extent. I guess it makes sense, yes. OTOH, it´s close
> > > > enough to be clear what's happening.    
> > > 
> > > Close, but not enough in my opinion. This currently is spread over pure flags
> > > manipulation and API calls.
> > >   
> > > > Anyways, can spin v3 if you feel
> > > > strong about it (will anyways wait for Jonathan to take a look to make
> > > > sure this the only pending concern).    
> > > 
> > > Not so strong, but lean towards my version. Let's wait for his review and
> > > decide if it will be tweaked whilst applying or next version.
> > >   
> > Applied with this tweak.  Hopefully I didn't mess it up!
> 
> I'll leave it on tree for now but I forgot to check sashiko and
> it asks about plausible sounding races. Please take a look and
> let me know if they are real and an update is needed:
> https://sashiko.dev/#/patchset/20260715-iio-dma-cyclic-v2-1-268a3a28ff84%40analog.com

"
Does this check allow a non-cyclic transfer to be submitted while a cyclic
transfer is already active?
Since block->cyclic is false for a non-cyclic transfer, this safety check
is bypassed."

The above is the whole point of DMA_PREP_LOAD_EOT (so we can gracefully
"terminate" a cyclic transfer)

I now see that our current cap will never allow for a new cyclic to be
submitted (unless we disable + enable the buffer)  but I would keep things simple
for now (it was also the whole point of having a cyclic cap in the first
place).

"If a non-cyclic file I/O transfer is submitted instead, it lacks the
DMA_PREP_LOAD_EOT flag, which could cause it to hang forever while the DMA
engine continuously repeats the preceding cyclic transfer."

Not sure where AI got the above from. The DMA_PREP_LOAD_EOT is always
set (even for the file IO based approach).

So unless I'm missing nothing, I think we are fine.

- Nuno Sá

> 
> > 
> > diff --git a/drivers/iio/buffer/industrialio-buffer-dmaengine.c b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > index 639bac135539..ecc02a427b92 100644
> > --- a/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > +++ b/drivers/iio/buffer/industrialio-buffer-dmaengine.c
> > @@ -132,9 +132,10 @@ static int iio_dmaengine_buffer_submit_block(struct iio_dma_buffer_queue *queue,
> >                  * A new transfer may need to end an already active cyclic transfer
> >                  * before it can run, so always set the EOT flag.
> >                  */
> > +               flags |= DMA_PREP_LOAD_EOT;
> >                 desc = dmaengine_prep_peripheral_dma_vec(dmaengine_buffer->chan,
> >                                                          vecs, nents, dma_dir,
> > -                                                        flags | DMA_PREP_LOAD_EOT);
> > +                                                        flags);
> >                 kfree(vecs);
> >         } else {
> >                 max_size = min(block->size, dmaengine_buffer->max_size);
> > 
> > > > > 		/*
> > > > > 		 * ...comment...
> > > > > 		 */
> > > > > 		flags |= DMA_PREP_LOAD_EOT;
> > > > > 		...
> > > > > 							flags);
> > > > >     
> > > > > >  		kfree(vecs);    
> > >   
> > 
> > 
>