Re: [PATCH v2 1/8] dmaengine: Add API to combine configuration and preparation (sg and single)

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

On Mon, Mar 09, 2026 at 12:04:59PM +0100, Vinod Koul wrote:
> On 18-12-25, 10:56, Frank Li wrote:
> > Previously, configuration and preparation required two separate calls. This
> > works well when configuration is done only once during initialization.
> >
> > However, in cases where the burst length or source/destination address must
> > be adjusted for each transfer, calling two functions is verbose and
> > requires additional locking to ensure both steps complete atomically.
> >
> > Add a new API dmaengine_prep_config_single() and dmaengine_prep_config_sg()
> > and callback device_prep_config_sg() that combines configuration and
> > preparation into a single operation. If the configuration argument is
> > passed as NULL, fall back to the existing implementation.
> >
> > Add a new API dmaengine_prep_config_single_safe() and
> > dmaengine_prep_config_sg_safe() for re-entrancy, which require driver
> > implement callback device_prep_config_sg().
>
> Okay to add API
>
> > +	struct dma_async_tx_descriptor *(*device_prep_config_sg)(
> > +		struct dma_chan *chan, struct scatterlist *sgl,
> > +		unsigned int sg_len, enum dma_transfer_direction direction,
> > +		unsigned long flags, struct dma_slave_config *config,
> > +		void *context);
>
> Do we want to have drivers implement one more callback. It does not make
> sense to me. Why not handle this in framework and have it call the
> respective lower level APIs.

To avoid use addtional lock! suppose each API is re-entriable.

thread 1:  call dmaengine_prep_config_sg_safe()
thread 2:  call dmaengine_prep_config_sg_safe()

If DMA engine driver implement device_prep_config_sg, thread 1 and thread 2
can run parallel.

If driver have not implement this callback, it have to use mutex make sure
config and prep atomic.

https://lore.kernel.org/dmaengine/20260109-edma_dymatic-v1-0-9a98c9c98536@nxp.com/
show finial opitimziation result, which depend on this. If can't call
prep() function parallel, which will kill performace.

>
> Drivers should implement simple apis and collectively the functionality
> can come from the framework.
>
> Would you consider revising as such. Bonus all existing drivers can
> start using this API, no change required for drivers in that case'

Not that simple, some devices just call config at probe, especial fix
FIFO address and burst length.

Call config and prep only need for the case, which need adjust src/dst
address, burst length or other parameter for each transfer.

Frank

>
>
> --
> ~Vinod