Re: [PATCH] dmaengine: xilinx_dma: Use readl_poll_timeout() instead of atomic variant
Tomi Valkeinen <[email protected]> Mon, 3 Aug 2026 17:39:40 +0300
| Newsgroups | org.kernel.vger.dmaengine,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > --- > 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