Hi James,
Thanks for dropping the unused rx_pause_wakeup lines in omap_8250_shutdown()
in v10. Following up here on your question from the v9 7/8 thread:
On Tue, Nov 03, 2026 at 11:05:42AM -0700, James Hilliard wrote:
> For pause-capable hardware, a recovery timeout does not have to prove
> that the failure is permanent. The concern is what happens after that
> timeout: the current recovery path discards the pending transfer and
> leaves RX on PIO until reopen.
>
> Is there a recovery approach that avoids an indefinite RX stall
> without turning a potentially temporary pause failure into loss of DMA
> for the rest of the open session?
Yes — the only reason the current recovery path disables RX DMA for the
rest of the open session is that serial8250_rx_dma_recover() sets
dma->rx_err = true and serial8250_rx_dma_flush_work() leaves it set
after dmaengine_terminate_sync(dma->rxchan) succeeds, which causes
serial8250_rx_dma() to return -EIO until reopen.
Notice that struct uart_8250_dma already distinguishes a normal
post-pause async termination from an unpaused transfer that needs
synchronous termination:
- When serial8250_rx_dma_try_flush() succeeds, it calls
dmaengine_terminate_async(dma->rxchan), sets dma->rx_terminating =
true, and clears dma->rx_running = 0.
- When serial8250_rx_dma_try_flush() fails, dma->rx_running remains 1.
So we can decouple bounded pause-timeout recovery from sticky PIO
fallback without adding any new struct fields:
1. In serial8250_rx_dma_flush_work(), if retry is still true when the
1-second retry budget expires (or immediately if ret == -ENOSYS ||
ret == -EOPNOTSUPP):
- If ret == -ENOSYS || ret == -EOPNOTSUPP (e.g. Tegra186 where
hw_support_pause is false), call serial8250_rx_dma_recover(p) so
dma->rx_err = true permanently falls back to PIO for the session.
- Otherwise (a pause timeout such as -EAGAIN, -EBUSY, or
-ETIMEDOUT), set dma->rx_terminating = true while keeping
dma->rx_running = 1, dma->rx_pause_pending = true, and
dma->rx_err = false, and set retry = false.
2. Derive recover from persistent state under port->lock:
recover = dma->rx_err || (dma->rx_running && dma->rx_terminating);
fall_back_pio = dma->rx_err;
And in serial8250_rx_dma_recovering() (8250.h):
return up->dma &&
(up->dma->rx_pause_pending ||
((up->dma->rx_err || up->dma->rx_running) &&
up->dma->rx_terminating));
3. In if (recover), run ret = dmaengine_terminate_sync(dma->rxchan):
- While dmaengine_terminate_sync() runs outside port->lock,
serial8250_rx_dma_recovering() is true (keeping RX interrupts
masked in UART_IER and skip_rx = true) and dma->rx_terminating is
true (blocking dma_rx_complete() and serial8250_rx_dma()).
- If dmaengine_terminate_sync(dma->rxchan) fails (ret != 0), latch
dma->rx_err = true under port->lock and return early so RX stays
masked and the buffer stays owned by DMA.
- If dmaengine_terminate_sync(dma->rxchan) succeeds (ret == 0), the
existing post-sync cleanup block clears rx_pause_pending,
rx_terminating, and rx_running and restores UART_IER with
dma->rx_err == false.
Because 8250 RX DMA is armed on-demand when rx_running == 0 and
!rx_err, any trigger-tail bytes remaining in the UART RX FIFO below the
RDI trigger level are drained via PIO on UART_IIR_RX_TIMEOUT, and the
next UART_IIR_RDI interrupt submits a fresh RX DMA descriptor — so RX
DMA remains active for the rest of the open session.
(Regarding the dw-axi-dmac driver mentioned on v10 7/8:
drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c has separate provider
bugs where dw_axi_dma_interrupt() clears CH_INTSTATUS across all
channels including DWAXIDMAC_IRQ_SUSPENDED, dma_chan_pause() leaves
DMAC_CHSUSPREG and chan->is_paused = true set when returning -EAGAIN,
and dma_chan_terminate_all() only clears DMAC_CHEN without clearing
DMAC_CHSUSPREG or chan->is_paused. Those belong in a dw-axi-dmac
driver fix, whereas the non-sticky pause-timeout recovery above ensures
8250_dma.c never stalls RX indefinitely on a pause timeout while
keeping RX DMA enabled for subsequent transfers.)
Thanks,
Raul
