[PATCH] dmaengine: xilinx_dma: Use readl_poll_timeout() instead of atomic variant
Tomi Valkeinen
tomi.valkeinen at ideasonboard.com
Mon Aug 3 07:39:40 PDT 2026
Hi,
On 03/08/2026 16:20, Tomi Valkeinen wrote:
> All callers of xilinx_dma_poll_timeout() pass a zero delay and a 1
> second timeout (XILINX_DMA_LOOP_COUNT). With a zero delay,
> readl_poll_timeout_atomic() does not measure wall clock time, and the
> actual timeout can be much more than 1 second.
>
> This is very visible when a channel reset never completes, e.g. with a
> VDMA whose stream-side clock isn't running. Probe appears to hang, and
> only minutes later fails with:
>
> xilinx-vdma a0050000.dma: reset timeout, cr 4, sr 0
> xilinx-vdma a0050000.dma: Reset channel failed
>
> Switch to readl_poll_timeout(), which checks the deadline against
> ktime_get().
>
> Calling xilinx_dma_poll_timeout() from atomic context is still safe even
> after this change, as readl_poll_timeout() with zero delay never sleeps.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index 404235c17353..6e8c786147f7 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -530,7 +530,7 @@ struct xilinx_dma_device {
> #define to_dma_tx_descriptor(tx) \
> container_of(tx, struct xilinx_dma_tx_descriptor, async_tx)
> #define xilinx_dma_poll_timeout(chan, reg, val, cond, delay_us, timeout_us) \
> - readl_poll_timeout_atomic(chan->xdev->regs + chan->ctrl_offset + reg, \
> + readl_poll_timeout(chan->xdev->regs + chan->ctrl_offset + reg, \
> val, cond, delay_us, timeout_us)
As commented by Sashiko, readl_poll_timeout API doc says "Must not be
called from atomic context if sleep_us or timeout_us are used".
Maybe a better fix is to continue using readl_poll_timeout_atomic, but
use a small (non-zero) delay_us, and decrease the timeout_us. Using a
one second timeout when calling from atomic context doesn't sound very
good in any case.
Tomi
More information about the linux-arm-kernel
mailing list