[PATCH v3] dmaengine: dw-axi-dmac: report paused state and residue in tx_status

[PATCH v3] dmaengine: dw-axi-dmac: report paused state and residue in tx_status

[Rui Wang]

The driver implements device_pause/device_resume, but device_tx_status
keeps reporting DMA_IN_PROGRESS for a paused channel, so clients cannot
tell a paused channel apart from a running one. Report DMA_PAUSED when
the channel is paused and the cookie is still in flight, including for
callers that pass a NULL dma_tx_state, and clear the stale is_paused
flag in dma_chan_terminate_all(), which disables the channel and thus
implicitly cancels the paused state.

Also, the residue of an in-flight transfer is currently derived from
the number of completed LLI blocks, so it only advances in block-size
steps and stays stale for the duration of a large block. Read the
current hardware pointer (CH_SAR for MEM_TO_DEV and MEM_TO_MEM, CH_DAR
for DEV_TO_MEM) and walk the descriptor's LLIs to compute how many
bytes have actually been transferred. The 64-bit pointer is sampled
with a tearing-safe double read, as the transfer may be running
concurrently. When the transfer has just completed but the descriptor
has not been reaped yet, the pointer sits at the end of the last block
and the residue naturally reads as 0; conversely, a channel whose
enable bit is still set never reports full completion, so a stale
pointer left by a previous transfer reusing the same buffer cannot be
mistaken for a finished one. Queued descriptors keep reporting their
full length and cyclic descriptors keep the block-granular accounting.

Tested on an FPGA platform.

Signed-off-by: Rui Wang <wr574332525@163.com>
---
Changes in v3:
- Report DMA_PAUSED also to callers passing a NULL dma_tx_state.
- Never report full completion while the channel enable bit is still
  set, so a stale pointer (e.g. a new transfer reusing the buffer of a
  just-finished one) is not mistaken for completion.
- Link to v2: https://lore.kernel.org/dmaengine/20260923034653.1413-1-wr574332525@163.com/
Changes in v2:
- Sample the 64-bit SAR/DAR with a tearing-safe double read instead of
  lo_hi_readq(), avoiding a torn pointer when the low half wraps.
- Read the hardware pointer for the in-flight descriptor even after the
  hardware has just completed it (channel enable self-cleared, IRQ not
  yet handled), so the residue reads 0 instead of jumping back to the
  full length.
- Link to v1: https://lore.kernel.org/dmaengine/20260923030201.859-1-wr574332525@163.com/
---
 .../dma/dw-axi-dmac/dw-axi-dmac-platform.c    | 104 ++++++++++++++++--
 1 file changed, 96 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
index eebed2474..5653a5712 100644
--- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
+++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
@@ -352,33 +352,120 @@ static void vchan_desc_put(struct virt_dma_desc *vdesc)
 	axi_desc_put(vd_to_axi_desc(vdesc));
 }
 
+/*
+ * Read a 64-bit channel address register while the transfer may be
+ * running. A plain lo_hi_readq() tears if the low half wraps (carrying
+ * into the high half) between the two 32-bit reads, so sample the high
+ * half twice and re-sample the low half if it moved; a second 4 GiB
+ * wrap cannot happen within these few instructions.
+ */
+static u64 axi_chan_readq(struct axi_dma_chan *chan, u32 reg)
+{
+	u32 hi, lo, hi2;
+
+	hi = readl(chan->chan_regs + reg + 4);
+	lo = readl(chan->chan_regs + reg);
+	hi2 = readl(chan->chan_regs + reg + 4);
+	if (unlikely(hi != hi2)) {
+		/* Low half wrapped in between, take consistent samples */
+		lo = readl(chan->chan_regs + reg);
+		hi = hi2;
+	}
+
+	return (u64)hi << 32 | lo;
+}
+
+/*
+ * Return the number of bytes already transferred by the descriptor
+ * currently on the hardware (running, paused or just completed), based
+ * on the current read or write position: CH_SAR for MEM_TO_DEV and
+ * MEM_TO_MEM, CH_DAR for DEV_TO_MEM. Must be called with vc.lock held.
+ */
+static u32 axi_chan_get_xferred(struct axi_dma_chan *chan,
+				struct axi_dma_desc *desc)
+{
+	struct axi_dma_hw_desc *hw_desc;
+	bool dst = chan->direction == DMA_DEV_TO_MEM;
+	u64 pos, start;
+	u32 xferred = 0;
+	int i;
+
+	pos = axi_chan_readq(chan, dst ? CH_DAR : CH_SAR);
+
+	for (i = 0; i < desc->nr_hw_descs; i++) {
+		hw_desc = &desc->hw_desc[i];
+		start = le64_to_cpu(dst ? hw_desc->lli->dar : hw_desc->lli->sar);
+
+		/* Current position is inside this block: partial progress */
+		if (pos >= start && pos <= start + hw_desc->len)
+			return xferred + (u32)(pos - start);
+
+		xferred += hw_desc->len;
+	}
+
+	/* Position doesn't match any block, be conservative */
+	return 0;
+}
+
 static enum dma_status
 dma_chan_tx_status(struct dma_chan *dchan, dma_cookie_t cookie,
 		   struct dma_tx_state *txstate)
 {
 	struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
 	struct virt_dma_desc *vdesc;
+	struct axi_dma_desc *desc;
 	enum dma_status status;
 	u32 completed_length;
 	unsigned long flags;
-	u32 completed_blocks;
 	size_t bytes = 0;
 	u32 length;
-	u32 len;
 
 	status = dma_cookie_status(dchan, cookie, txstate);
-	if (status == DMA_COMPLETE || !txstate)
+	if (status == DMA_COMPLETE)
 		return status;
 
 	spin_lock_irqsave(&chan->vc.lock, flags);
 
+	if (chan->is_paused && status == DMA_IN_PROGRESS)
+		status = DMA_PAUSED;
+
+	if (!txstate) {
+		spin_unlock_irqrestore(&chan->vc.lock, flags);
+		return status;
+	}
+
 	vdesc = vchan_find_desc(&chan->vc, cookie);
 	if (vdesc) {
-		length = vd_to_axi_desc(vdesc)->length;
-		completed_blocks = vd_to_axi_desc(vdesc)->completed_blocks;
-		len = vd_to_axi_desc(vdesc)->hw_desc[0].len;
-		completed_length = completed_blocks * len;
-		bytes = length - completed_length;
+		desc = vd_to_axi_desc(vdesc);
+		length = desc->length;
+
+		if (chan->cyclic) {
+			completed_length = desc->completed_blocks *
+					   desc->hw_desc[0].len;
+		} else if (vdesc == vchan_next_desc(&chan->vc)) {
+			/*
+			 * The descriptor is on the hardware: read the progress
+			 * from its pointer. If the transfer has just finished
+			 * but the interrupt has not reaped the descriptor yet,
+			 * the pointer sits at the end and the residue reads 0.
+			 *
+			 * The hardware clears the channel enable bit when the
+			 * transfer completes, so a still-enabled channel cannot
+			 * be done: right after the start its pointer may still
+			 * hold the value of a previous transfer, which aliases
+			 * the end of the new one when the buffer is reused.
+			 * Never report full completion while the channel runs.
+			 */
+			completed_length = axi_chan_get_xferred(chan, desc);
+			if (completed_length == length &&
+			    axi_chan_is_hw_enable(chan))
+				completed_length = length - 1;
+		} else {
+			/* Still queued, nothing transferred yet */
+			completed_length = 0;
+		}
+
+		bytes = length - min_t(u32, completed_length, length);
 	}
 
 	spin_unlock_irqrestore(&chan->vc.lock, flags);
@@ -1206,6 +1293,7 @@ static int dma_chan_terminate_all(struct dma_chan *dchan)
 	vchan_get_all_descriptors(&chan->vc, &head);
 
 	chan->cyclic = false;
+	chan->is_paused = false;
 	spin_unlock_irqrestore(&chan->vc.lock, flags);
 
 	vchan_dma_desc_free_list(&chan->vc, &head);
-- 
2.43.0

Re: [PATCH v3] dmaengine: dw-axi-dmac: report paused state and residue in tx_status

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dmaengine: dw-axi-dmac: false 0 residue for queued descriptors due to stale HW pointers
--

commit 1fb45501ae16a4b2f841216b130cbe2ef95cb7a3
Author: Rui Wang <wr574332525@163.com>

dmaengine: dw-axi-dmac: report paused state and residue in tx_status

The driver implements device_pause/device_resume, but device_tx_status
keeps reporting DMA_IN_PROGRESS for a paused channel, so clients cannot
tell a paused channel apart from a running one. This patch addresses
this by properly reporting DMA_PAUSED and updating the residue calculation
to read the hardware pointers directly instead of relying on completed
blocks.

> diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> index eebed2474210d..5653a57126d66 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> @@ -352,33 +352,120 @@ static void vchan_desc_put(struct virt_dma_desc *vdesc)

[ ... ]

>  	vdesc = vchan_find_desc(&chan->vc, cookie);
>  	if (vdesc) {
> -		length = vd_to_axi_desc(vdesc)->length;
> -		completed_blocks = vd_to_axi_desc(vdesc)->completed_blocks;
> -		len = vd_to_axi_desc(vdesc)->hw_desc[0].len;
> -		completed_length = completed_blocks * len;
> -		bytes = length - completed_length;
> +		desc = vd_to_axi_desc(vdesc);
> +		length = desc->length;
> +
> +		if (chan->cyclic) {
> +			completed_length = desc->completed_blocks *
> +					   desc->hw_desc[0].len;
> +		} else if (vdesc == vchan_next_desc(&chan->vc)) {
> +			/*
> +			 * The descriptor is on the hardware: read the progress
> +			 * from its pointer. If the transfer has just finished
> +			 * but the interrupt has not reaped the descriptor yet,
> +			 * the pointer sits at the end and the residue reads 0.
> +			 *
> +			 * The hardware clears the channel enable bit when the
> +			 * transfer completes, so a still-enabled channel cannot
> +			 * be done: right after the start its pointer may still
> +			 * hold the value of a previous transfer, which aliases
> +			 * the end of the new one when the buffer is reused.
> +			 * Never report full completion while the channel runs.
> +			 */
> +			completed_length = axi_chan_get_xferred(chan, desc);
> +			if (completed_length == length &&
> +			    axi_chan_is_hw_enable(chan))
> +				completed_length = length - 1;
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this code handle the case where the descriptor is at the head of
desc_issued but hasn't actually been started on the hardware?

If a transfer completes and a new transfer is queued reusing the same memory
buffer, the new transfer will be at the head of desc_issued. Because the
hardware is idle, axi_chan_is_hw_enable(chan) will be false.

When dma_chan_tx_status() is called, vchan_next_desc() matches this new
unstarted transfer. The hardware pointers CH_SAR and CH_DAR still hold the
stale end-addresses from the previous transfer, which match the new
transfer's boundaries.

This causes axi_chan_get_xferred() to return length, and because the
hardware is idle, the mitigation here is bypassed. Could this result in an
unstarted transfer falsely reporting a residue of 0, indicating full
completion?

> +		} else {
> +			/* Still queued, nothing transferred yet */
> +			completed_length = 0;
> +		}
> +
> +		bytes = length - min_t(u32, completed_length, length);
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923044104.3234-1-wr574332525@163.com?part=1