[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aUGA7tmDYm1MhRXn@lizhi-Precision-Tower-5810>
Date: Tue, 16 Dec 2025 10:55:26 -0500
From: Frank Li <Frank.li@....com>
To: Vinod Koul <vkoul@...nel.org>
Cc: Manivannan Sadhasivam <mani@...nel.org>,
Krzysztof WilczyĆski <kwilczynski@...nel.org>,
Kishon Vijay Abraham I <kishon@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>, Christoph Hellwig <hch@....de>,
Sagi Grimberg <sagi@...mberg.me>,
Chaitanya Kulkarni <kch@...dia.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
Koichiro Den <den@...inux.co.jp>, Niklas Cassel <cassel@...nel.org>,
dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pci@...r.kernel.org, linux-nvme@...ts.infradead.org,
mhi@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
linux-crypto@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
imx@...ts.linux.dev
Subject: Re: [PATCH 0/8] dmaengine: Add new API to combine onfiguration and
descriptor preparation
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 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.
Frank
>
> > - dmaengine_prep_dma_cyclic() is actually work with prepiperial FIFO
> > - some prepierial FIFO work like memory, by use shared memory method, like
> > PCIe map windows.
> > - argument: config and dir already passdown information to indicate if it
> > is device preiperial. So needn't indicate at function name.
> > - maybe later extend to support mem to mem by config becuase adjust burst
> > size for difference alignment or difference bus fabric port to optimaze
> > performance.
> >
> > Frank
> >
> > >
> > > I would like to retain the dmaengine_prep_slave_single() as an API for
> > > users to call and invoke. There are users who configure channel once as
> > > well
> > >
> > > >
> > > > Additional, prevous two calls requires additional locking to ensure both
> > > > steps complete atomically.
> > > >
> > > > mutex_lock()
> > > > dmaengine_slave_config()
> > > > dmaengine_prep_slave_single()
> > > > mutex_unlock()
> > > >
> > > > after new API added, mutex lock can be moved. See patch
> > > > nvmet: pci-epf: Use dmaengine_prep_slave_single_config() API
> > > >
> > > > Signed-off-by: Frank Li <Frank.Li@....com>
> > > > ---
> > > > Frank Li (8):
> > > > dmaengine: Add API to combine configuration and preparation (sg and single)
> > > > PCI: endpoint: pci-epf-test: use new DMA API to simple code
> > > > dmaengine: dw-edma: Use new .device_prep_slave_sg_config() callback
> > > > dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
> > > > nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
> > > > nvmet: pci-epf: Use dmaengine_prep_slave_single_config() API
> > > > PCI: epf-mhi:Using new API dmaengine_prep_slave_single_config() to simple code.
> > > > crypto: atmel: Use dmaengine_prep_slave_single_config() API
> > > >
> > > > drivers/crypto/atmel-aes.c | 10 ++---
> > > > drivers/dma/dw-edma/dw-edma-core.c | 38 +++++++++++-----
> > > > drivers/nvme/target/pci-epf.c | 21 +++------
> > > > drivers/pci/endpoint/functions/pci-epf-mhi.c | 52 +++++++---------------
> > > > drivers/pci/endpoint/functions/pci-epf-test.c | 8 +---
> > > > include/linux/dmaengine.h | 64 ++++++++++++++++++++++++---
> > > > 6 files changed, 111 insertions(+), 82 deletions(-)
> > > > ---
> > > > base-commit: bc04acf4aeca588496124a6cf54bfce3db327039
> > > > change-id: 20251204-dma_prep_config-654170d245a2
> > > >
> > > > Best regards,
> > > > --
> > > > Frank Li <Frank.Li@....com>
> > >
> > > --
> > > ~Vinod
>
> --
> ~Vinod
Powered by blists - more mailing lists