Re: [PATCH v2 4/5] PCI: epf-mhi: Add batched DMA read support

On Mon, Aug 03, 2026 at 04:01:46PM +0530, Sumit Kumar wrote:
> Add support for batched DMA transfers in the PCI EPF MHI driver to
> improve performance when reading multiple buffers from the host.
> 
> Implement two variants of the read_batch() callback:
> pci_epf_mhi_edma_read_batch() is a DMA-optimized implementation that uses
> dmaengine_prep_dma_sg() to transfer multiple buffers in a single DMA
> transaction, while pci_epf_mhi_iatu_read_batch() serves as a CPU-copy
> fallback for platforms without DMA support by sequentially processing each
> buffer via IATU mapping. Wire up read_batch() to the eDMA variant only
> when the RX DMA channel advertises the DMA_SG capability, falling back to
> the IATU variant otherwise.
> 
> On a successful batch, notify completion for every buffer via its
> caller-supplied buf_info->cb, mirroring the read_sync/read_async
> completion semantics so the MHI stack can free each buffer and raise its
> transfer completion event. Make read_batch() a mandatory callback in
> mhi_ep_register_controller(), alongside read_sync/write_sync/read_async/
> write_async.
> 
> This enables the MHI endpoint stack to cache ring data efficiently,
> particularly for wraparound scenarios where ring data spans two
> non-contiguous memory regions.
> 
> Signed-off-by: Sumit Kumar <[email protected]>
> ---
>  drivers/bus/mhi/ep/main.c                    |   3 +-
>  drivers/pci/endpoint/functions/pci-epf-mhi.c | 159 +++++++++++++++++++++++++++
>  include/linux/mhi_ep.h                       |   7 ++
>  3 files changed, 168 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
> index 21bc2c50170ff7f0181c0d0d4eefd51db30f34c8..c45240fc481dc3260a61b546c223b6be8e105587 100644
> --- a/drivers/bus/mhi/ep/main.c
> +++ b/drivers/bus/mhi/ep/main.c
> @@ -1459,7 +1459,8 @@ int mhi_ep_register_controller(struct mhi_ep_cntrl *mhi_cntrl,
>  		return -EINVAL;
>  
>  	if (!mhi_cntrl->read_sync || !mhi_cntrl->write_sync ||
> -	    !mhi_cntrl->read_async || !mhi_cntrl->write_async)
> +	    !mhi_cntrl->read_async || !mhi_cntrl->write_async ||
> +	    !mhi_cntrl->read_batch)

No, this looks like a broken client-provider contract. You don't necessarily
need a new callback. Just rework read_sync/async callbacks to accept
'num_buffers' argument and let the EPF deal with however it wants to transfer
the buffers.

If the num_buffers is 1, it can use the existing path and if it is > 1, it can
use the new dmaengine API. Or to simplify further, you can use the new API for
all buffer lengths. Only caveat is that you need to check whether the dmaengine
supports relevant capabilities like DMA_SG.

- Mani

-- 
மணிவண்ணன் சதாசிவம்