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

[Frank Li]

On Tue, Mar 17, 2026 at 04:07:41PM +0530, Vinod Koul wrote:
> On 09-03-26, 10:42, Frank Li wrote:
> > 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@xxxxxxx/
> > show finial opitimziation result, which depend on this. If can't call
> > prep() function parallel, which will kill performace.
>
> Which seems to be 10% in your case.
>
> > > 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.
>
> Correct. In the cases where config is done once they can invoke with
> NULL config. I would like the middle layer to handle complexities and
> drivers should be simpler

This patches already implement these.

If you don't like add new callback, how about change existing callback
by add config * and update all drivers.

Frank

>
> >
> > Frank
> >
> > >
> > >
> > > --
> > > ~Vinod
>
> --
> ~Vinod