Re: [PATCH 1/3] dmaengine: add dmaengine_async_is_tx_complete() for channel status queries

[Frank Li <Frank.li@oss.nxp.com>]

On Mon, Oct 19, 2026 at 08:06:30AM -0700, Daniel Byrne wrote:
> [You don't often get email from daniel1.byrne@intel.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Add dmaengine_async_is_tx_complete() as the client API for polling the
> completion of one transaction. Like dma_async_is_tx_complete(), which
> it deprecates, it routes the query to the channel's device_tx_status()
> callback; the change is that it drops the @last and @used outputs,
> which only make sense for providers that complete in cookie order.
> A provider that tracks per-descriptor state can answer exactly from
> that state, and a high-rate in-kernel polling user, the io_uring DSA
> copy offload to be posted separately, depends on such answers.

Does it should wrap dmaengine_tx_status()?  from naming conversion

dmaengine_async_is_tx_complete() should return bool type.

>
> The kernel-doc says how far such an answer goes. It is exact for a
> transaction submitted without DMA_PREP_INTERRUPT, on the first query
> that reports it finished. An interrupt-armed transaction reports its
> result through callback_result, and a cookie whose descriptor has been
> retired reads DMA_COMPLETE. The client guide's advice to pause or stop
> the channel before a query points at that text.

I don't that it is true. Supposed user can always poll state regardless if
set DMA_PREP_INTERRUPT.

>
> dma_async_is_complete() was only used through dma_cookie_status(), so
> delete it from the client header and open-code the cookie-window
> comparison there.

> Move dma_set_tx_state(), which only providers call,
> from the client header into drivers/dma/dmaengine.h; every in-tree

Use sperate patch for such movement.

Frank