Re: [PATCH v2 0/5] dmaengine: dma-axi-dmac: Add cyclic transfer support and graceful termination

["Nuno Sá" <noname.nuno@gmail.com>]

On Mon, 2026-03-09 at 08:46 +0100, Vinod Koul wrote:
> 
> On Tue, 03 Mar 2026 10:24:59 +0000, Nuno Sá wrote:
> > This series adds support for cyclic transfers in the .device_prep_peripheral_dma_vec()
> > callback and implements graceful termination of cyclic transfers using the
> > DMA_PREP_LOAD_EOT flag. Using DMA_PREP_REPEAT and DMA_PREP_LOAD_EOT is
> > based on the discussion in [1].
> > 
> > Currently, the only way to stop a cyclic transfer is through brute force using
> > .device_terminate_all(), which terminates all pending transfers. This series
> > introduces a mechanism to gracefully terminate individual cyclic transfers when
> > a new transfer flagged with DMA_PREP_LOAD_EOT is queued.
> > 
> > [...]
> 
> Applied, thanks!
> 
> [1/5] dmaengine: Document cyclic transfer for dmaengine_prep_peripheral_dma_vec()
>       commit: 5f88899ec7531e1680b1003f32584d7da5922902
> [2/5] dmaengine: dma-axi-dmac: Add cyclic transfers in .device_prep_peripheral_dma_vec()
>       commit: ac85913ab71e0de9827b7f8f7fccb9f20943c02f
> [3/5] dmaengine: dma-axi-dmac: Add helper for getting next desc
>       commit: c60990ba1fb2a6c1ff2789e610aa130f3047a2ff
> [4/5] dmaengine: dma-axi-dmac: Gracefully terminate SW cyclic transfers
>       commit: ca3bf200dea50fada92ec371e9e294b18a589676
> [5/5] dmaengine: dma-axi-dmac: Gracefully terminate HW cyclic transfers
>       commit: f1d201e7e4e7646e55ce4946f0adec4b035ffb4b
> 
> Best regards,

Hi Vinod,

Thanks for applying the patches. Since I have you here and if you have 5 min I would like to
ask you for some clarifications. It seems there's a bit of a confusion regarding src_addr_widths
and dst_addr_widths. For instance the docs say the following:

" bit mask of src addr widths the channel supports.
Width is specified in bytes, e.g. for a channel supporting
a width of 4 the mask should have BIT(4) set."

And I suspect that BIT(4) is leading into some confusion. Like, if I have a width of 4, then my
mask should look like 0x04 and not 0x20, right? Like the code in [1] looks suspicious to me... And
it seems that pattern is followed in a lot of other places. If I look at [2], then it looks more
with what I would expect.

Like, if the correct way is 1), then it means that 64bytes is not really possible right now given
that BIT(64) is UB and that looks a bit limitating and odd to me. That and given that the AXI_DMAC
might also suffer from a, possible bug, made me want to clarify this.

Thanks!
- Nuno Sá

[1]: https://elixir.bootlin.com/linux/v7.0-rc2/source/drivers/dma/tegra210-adma.c#L1166
[2]: https://elixir.bootlin.com/linux/v7.0-rc2/source/drivers/dma/sh/rcar-dmac.c#L1841