Re: [PATCH 0/8] dmaengine: Add new API to combine onfiguration and descriptor preparation

On Tue, Dec 16, 2025 at 10:47:57PM +0530, Vinod Koul wrote:
> On 16-12-25, 10:55, Frank Li wrote:
> > On Tue, Dec 16, 2025 at 09:13:07PM +0530, Vinod Koul wrote:
> > > On 16-12-25, 10:10, Frank Li wrote:
> > > > On Tue, Dec 16, 2025 at 06:15:19PM +0530, Vinod Koul wrote:
> > > > > On 08-12-25, 12:09, Frank Li wrote:
> > > > >
> > > > > Spell check on subject please :-)
> > > > >
> > > > > > 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.
> > > > > >
> > > > > > 	if (dmaengine_slave_config(chan, &sconf)) {
> > > > > > 		dev_err(dev, "DMA slave config fail\n");
> > > > > > 		return -EIO;
> > > > > > 	}
> > > > > >
> > > > > > 	tx = dmaengine_prep_slave_single(chan, dma_local, len, dir, flags);
> > > > > >
> > > > > > After new API added
> > > > > >
> > > > > > 	tx = dmaengine_prep_slave_single(chan, dma_local, len, dir, flags, &sconf);
> > > > >
> > > > > Nak, we cant change the API like this.
> > > >
> > > > Sorry, it is typo here. in patch
> > > > 	dmaengine_prep_slave_single_config(chan, dma_local, len, dir, flags, &sconf);
> > > >
> > > > > I agree that you can add a new way to call dmaengine_slave_config() and
> > > > > dmaengine_prep_slave_single() together.
> > > > > maybe dmaengine_prep_config_perip_single() (yes we can go away with slave, but
> > > > > cant drop it, as absence means something else entire).
> > > >
> > > > how about dmaengine_prep_peripheral_single() and dmaengine_prep_peripheral_sg()
> > > > to align recent added "dmaengine_prep_peripheral_dma_vec()"
> > >
> > > It doesnt imply config has been done, how does it differ from usual
> > > prep_ calls. I see confusions can be caused!
> >
> > dmaengine_prep_peripheral_single(.., &sconf) and
> > dmaengine_prep_peripheral_sg(..., &sconf).
> >
> > The above two funcitions have pass down &sconf.
> >
> > The usual prep_ call have not sconf argument, which need depend on previous
> > config.
> >
> > further, If passdown NULL for config, it means use previuos config.
>
> I know it is bit longer but somehow I would feel better for the API to
> imply config as well please

I can use you suggested dmaengine_prep_config_perip_single().

But how about use dmaengine_prep_config_single(), which little bit shorter
and use "config" to imply it is for periperal? (similar to cyclic case?)

Frank

>
> >
> > >
> > > > I think "peripheral" also is reduntant. dmaengine_prep_single() and
> > > > dmaengine_prep_sg() should be enough because
> > >
> > > Then you are missing the basic premises of dmaengine that we have memcpy
> > > ops and peripheral dma ops (aka slave) Absence of peripheral always
> > > implies that it is memcpy
> >
> > Okay, it is not big deal. is dmaengine_prep_dma_cyclic() exception? which
> > have not "peripheral" or "slave", but it is not for memcpy.
>
> Cyclic by definition implies a cyclic dma over a peripheral
>
> --
> ~Vinod