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

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

[Frank Li]

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);

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@nxp.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@nxp.com>

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

[Frank Li]

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 and callback device_prep_slave_sg_config that combines
configuration and preparation into a single operation. If the configuration
argument is passed as NULL, fall back to the existing implementation.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 include/linux/dmaengine.h | 64 +++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 57 insertions(+), 7 deletions(-)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 99efe2b9b4ea9844ca6161208362ef18ef111d96..6c563549133a28e26f1bdc367372b1e4a748afcf 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -835,6 +835,8 @@ struct dma_filter {
  *	where the address and size of each segment is located in one entry of
  *	the dma_vec array.
  * @device_prep_slave_sg: prepares a slave dma operation
+ *	(Depericated, use @device_prep_slave_sg_config)
+ * @device_prep_slave_sg_config: prepares a slave dma operation
  * @device_prep_dma_cyclic: prepare a cyclic dma operation suitable for audio.
  *	The function takes a buffer of size buf_len. The callback function will
  *	be called after period_len bytes have been transferred.
@@ -934,6 +936,11 @@ struct dma_device {
 		struct dma_chan *chan, struct scatterlist *sgl,
 		unsigned int sg_len, enum dma_transfer_direction direction,
 		unsigned long flags, void *context);
+	struct dma_async_tx_descriptor *(*device_prep_slave_sg_config)(
+		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);
 	struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
 		struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
 		size_t period_len, enum dma_transfer_direction direction,
@@ -974,22 +981,44 @@ static inline bool is_slave_direction(enum dma_transfer_direction direction)
 	       (direction == DMA_DEV_TO_DEV);
 }
 
-static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
-	struct dma_chan *chan, dma_addr_t buf, size_t len,
-	enum dma_transfer_direction dir, unsigned long flags)
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_slave_single_config(struct dma_chan *chan, dma_addr_t buf,
+				   size_t len, enum dma_transfer_direction dir,
+				   unsigned long flags,
+				   struct dma_slave_config *config)
 {
 	struct scatterlist sg;
 	sg_init_table(&sg, 1);
 	sg_dma_address(&sg) = buf;
 	sg_dma_len(&sg) = len;
 
-	if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
+	if (!chan || !chan->device)
+		return NULL;
+
+	if (chan->device->device_prep_slave_sg_config)
+		return chan->device->device_prep_slave_sg_config(chan, &sg, 1,
+					dir, flags, config, NULL);
+
+	if (config)
+		if (dmaengine_slave_config(chan, config))
+			return NULL;
+
+	if (!chan->device->device_prep_slave_sg)
 		return NULL;
 
 	return chan->device->device_prep_slave_sg(chan, &sg, 1,
 						  dir, flags, NULL);
 }
 
+static inline struct dma_async_tx_descriptor *
+dmaengine_prep_slave_single(struct dma_chan *chan, dma_addr_t buf, size_t len,
+			    enum dma_transfer_direction dir,
+			    unsigned long flags)
+{
+	return dmaengine_prep_slave_single_config(chan, buf, len, dir,
+						  flags, NULL);
+}
+
 /**
  * dmaengine_prep_peripheral_dma_vec() - Prepare a DMA scatter-gather descriptor
  * @chan: The channel to be used for this descriptor
@@ -1009,17 +1038,38 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
 							    dir, flags);
 }
 
-static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
+static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg_config(
 	struct dma_chan *chan, struct scatterlist *sgl,	unsigned int sg_len,
-	enum dma_transfer_direction dir, unsigned long flags)
+	enum dma_transfer_direction dir, unsigned long flags,
+	struct dma_slave_config *config)
 {
-	if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
+	if (!chan || !chan->device)
+		return NULL;
+
+	if (chan->device->device_prep_slave_sg_config)
+		return chan->device->device_prep_slave_sg_config(chan, sgl,
+								 sg_len, dir,
+								 flags, config,
+								 NULL);
+	if (config)
+		if (dmaengine_slave_config(chan, config))
+			return NULL;
+
+	if (!chan->device->device_prep_slave_sg)
 		return NULL;
 
 	return chan->device->device_prep_slave_sg(chan, sgl, sg_len,
 						  dir, flags, NULL);
 }
 
+static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
+	struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
+	enum dma_transfer_direction dir, unsigned long flags)
+{
+	return dmaengine_prep_slave_sg_config(chan, sgl, sg_len, dir,
+					      flags, NULL);
+}
+
 #ifdef CONFIG_RAPIDIO_DMA_ENGINE
 struct rio_dma_ext;
 static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg(

-- 
2.34.1

[PATCH 2/8] PCI: endpoint: pci-epf-test: use new DMA API to simple code

[Frank Li]

Using new API dmaengine_prep_slave_single_config() to simple code.

No functional change.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index debd235253c5ba54eb8f06d13261c407ee3768ec..eef569db0784d37bd6468b87fd951a5a0799ae69 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -162,12 +162,8 @@ static int pci_epf_test_data_transfer(struct pci_epf_test *epf_test,
 		else
 			sconf.src_addr = dma_remote;
 
-		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);
+		tx = dmaengine_prep_slave_single_config(chan, dma_local, len,
+							dir, flags, &sconf);
 	} else {
 		tx = dmaengine_prep_dma_memcpy(chan, dma_dst, dma_src, len,
 					       flags);

-- 
2.34.1

[PATCH 3/8] dmaengine: dw-edma: Use new .device_prep_slave_sg_config() callback

[Frank Li]

Use the new .device_prep_slave_sg_config() callback to combine
configuration and descriptor preparation.

No functional changes.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 drivers/dma/dw-edma/dw-edma-core.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index 8e5f7defa6b678eefe0f312ebc59f654677c744f..58f98542f8329a3bfdc5455768e8394ae601ab5f 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -532,10 +532,13 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
 }
 
 static struct dma_async_tx_descriptor *
-dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
-			     unsigned int len,
-			     enum dma_transfer_direction direction,
-			     unsigned long flags, void *context)
+dw_edma_device_prep_slave_sg_config(struct dma_chan *dchan,
+				    struct scatterlist *sgl,
+				    unsigned int len,
+				    enum dma_transfer_direction direction,
+				    unsigned long flags,
+				    struct dma_slave_config *config,
+				    void *context)
 {
 	struct dw_edma_transfer xfer;
 
@@ -546,6 +549,9 @@ dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
 	xfer.flags = flags;
 	xfer.type = EDMA_XFER_SCATTER_GATHER;
 
+	if (config)
+		dw_edma_device_config(dchan, config);
+
 	return dw_edma_device_transfer(&xfer);
 }
 
@@ -815,7 +821,7 @@ static int dw_edma_channel_setup(struct dw_edma *dw, u32 wr_alloc, u32 rd_alloc)
 	dma->device_terminate_all = dw_edma_device_terminate_all;
 	dma->device_issue_pending = dw_edma_device_issue_pending;
 	dma->device_tx_status = dw_edma_device_tx_status;
-	dma->device_prep_slave_sg = dw_edma_device_prep_slave_sg;
+	dma->device_prep_slave_sg_config = dw_edma_device_prep_slave_sg_config;
 	dma->device_prep_dma_cyclic = dw_edma_device_prep_dma_cyclic;
 	dma->device_prep_interleaved_dma = dw_edma_device_prep_interleaved_dma;
 

-- 
2.34.1

[PATCH 4/8] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()

[Frank Li]

Pass dma_slave_config to dw_edma_device_transfer() to support atomic
configuration and descriptor preparation when a non-NULL config is
provided to device_prep_slave_sg_config().

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 drivers/dma/dw-edma/dw-edma-core.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index 58f98542f8329a3bfdc5455768e8394ae601ab5f..744c60ec964102287bd32b9e55d0f3024d1d39d9 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -230,6 +230,15 @@ static int dw_edma_device_config(struct dma_chan *dchan,
 	return 0;
 }
 
+static struct dma_slave_config *
+dw_edma_device_get_config(struct dma_chan *dchan,
+			  struct dma_slave_config *config)
+{
+	struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
+
+	return config ? config : &chan->config;
+}
+
 static int dw_edma_device_pause(struct dma_chan *dchan)
 {
 	struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
@@ -348,7 +357,8 @@ dw_edma_device_tx_status(struct dma_chan *dchan, dma_cookie_t cookie,
 }
 
 static struct dma_async_tx_descriptor *
-dw_edma_device_transfer(struct dw_edma_transfer *xfer)
+dw_edma_device_transfer(struct dw_edma_transfer *xfer,
+			struct dma_slave_config *config)
 {
 	struct dw_edma_chan *chan = dchan2dw_edma_chan(xfer->dchan);
 	enum dma_transfer_direction dir = xfer->direction;
@@ -427,8 +437,8 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
 		src_addr = xfer->xfer.il->src_start;
 		dst_addr = xfer->xfer.il->dst_start;
 	} else {
-		src_addr = chan->config.src_addr;
-		dst_addr = chan->config.dst_addr;
+		src_addr = config->src_addr;
+		dst_addr = config->dst_addr;
 	}
 
 	if (dir == DMA_DEV_TO_MEM)
@@ -552,7 +562,7 @@ dw_edma_device_prep_slave_sg_config(struct dma_chan *dchan,
 	if (config)
 		dw_edma_device_config(dchan, config);
 
-	return dw_edma_device_transfer(&xfer);
+	return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, config));
 }
 
 static struct dma_async_tx_descriptor *
@@ -571,7 +581,7 @@ dw_edma_device_prep_dma_cyclic(struct dma_chan *dchan, dma_addr_t paddr,
 	xfer.flags = flags;
 	xfer.type = EDMA_XFER_CYCLIC;
 
-	return dw_edma_device_transfer(&xfer);
+	return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
 }
 
 static struct dma_async_tx_descriptor *
@@ -587,7 +597,7 @@ dw_edma_device_prep_interleaved_dma(struct dma_chan *dchan,
 	xfer.flags = flags;
 	xfer.type = EDMA_XFER_INTERLEAVED;
 
-	return dw_edma_device_transfer(&xfer);
+	return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
 }
 
 static void dw_hdma_set_callback_result(struct virt_dma_desc *vd,

-- 
2.34.1

[PATCH 5/8] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer

[Frank Li]

dmaengine_terminate_sync() cancels all pending requests. Calling it for
every DMA transfer is unnecessary and counterproductive. This function is
generally intended for cleanup paths such as module removal, device close,
or unbind operations.

Remove the redundant calls.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
This one also fix stress test failure after remove mutex and use new API
dmaengine_prep_slave_sg_config().
---
 drivers/nvme/target/pci-epf.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 2e78397a7373a7d8ba67150f301f392123db88d1..85225a4f75b5bd7abb6897d064123766af021542 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -420,8 +420,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
 		ret = -EIO;
 	}
 
-	dmaengine_terminate_sync(chan);
-
 unmap:
 	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
 

-- 
2.34.1

[PATCH 6/8] nvmet: pci-epf: Use dmaengine_prep_slave_single_config() API

[Frank Li]

Use the new dmaengine_prep_slave_single_config() API to combine the
configuration and descriptor preparation into a single call.

Since dmaengine_prep_slave_single_config() performs the configuration
and preparation atomically, the mutex can be removed.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 drivers/nvme/target/pci-epf.c | 19 +++++--------------
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
index 85225a4f75b5bd7abb6897d064123766af021542..223716b00715be2a81935e6920666c723fe98fe7 100644
--- a/drivers/nvme/target/pci-epf.c
+++ b/drivers/nvme/target/pci-epf.c
@@ -386,22 +386,16 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
 		return -EINVAL;
 	}
 
-	mutex_lock(lock);
-
 	dma_dev = dmaengine_get_dma_device(chan);
 	dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
 	ret = dma_mapping_error(dma_dev, dma_addr);
 	if (ret)
-		goto unlock;
-
-	ret = dmaengine_slave_config(chan, &sconf);
-	if (ret) {
-		dev_err(dev, "Failed to configure DMA channel\n");
-		goto unmap;
-	}
+		return ret;
 
-	desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
-					   sconf.direction, DMA_CTRL_ACK);
+	desc = dmaengine_prep_slave_single_config(chan, dma_addr, seg->length,
+						  sconf.direction,
+						  DMA_CTRL_ACK,
+						  &sconf);
 	if (!desc) {
 		dev_err(dev, "Failed to prepare DMA\n");
 		ret = -EIO;
@@ -423,9 +417,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
 unmap:
 	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
 
-unlock:
-	mutex_unlock(lock);
-
 	return ret;
 }
 

-- 
2.34.1

[PATCH 7/8] PCI: epf-mhi:Using new API dmaengine_prep_slave_single_config() to simple code.

[Frank Li]

No functional change.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Keep mutex lock because sync with other function.
---
 drivers/pci/endpoint/functions/pci-epf-mhi.c | 52 +++++++++-------------------
 1 file changed, 16 insertions(+), 36 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-mhi.c b/drivers/pci/endpoint/functions/pci-epf-mhi.c
index 6643a88c7a0ce38161bc6253c09d29f1c36ba394..11999a7a156dee057f04f0f9277f6ac5a7f1d7ee 100644
--- a/drivers/pci/endpoint/functions/pci-epf-mhi.c
+++ b/drivers/pci/endpoint/functions/pci-epf-mhi.c
@@ -328,12 +328,6 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
 	config.direction = DMA_DEV_TO_MEM;
 	config.src_addr = buf_info->host_addr;
 
-	ret = dmaengine_slave_config(chan, &config);
-	if (ret) {
-		dev_err(dev, "Failed to configure DMA channel\n");
-		goto err_unlock;
-	}
-
 	dst_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
 				  DMA_FROM_DEVICE);
 	ret = dma_mapping_error(dma_dev, dst_addr);
@@ -342,9 +336,10 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
 		goto err_unlock;
 	}
 
-	desc = dmaengine_prep_slave_single(chan, dst_addr, buf_info->size,
-					   DMA_DEV_TO_MEM,
-					   DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+	desc = dmaengine_prep_slave_single_config(chan, dst_addr, buf_info->size,
+						  DMA_DEV_TO_MEM,
+						  DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+						  &config);
 	if (!desc) {
 		dev_err(dev, "Failed to prepare DMA\n");
 		ret = -EIO;
@@ -399,12 +394,6 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
 	config.direction = DMA_MEM_TO_DEV;
 	config.dst_addr = buf_info->host_addr;
 
-	ret = dmaengine_slave_config(chan, &config);
-	if (ret) {
-		dev_err(dev, "Failed to configure DMA channel\n");
-		goto err_unlock;
-	}
-
 	src_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
 				  DMA_TO_DEVICE);
 	ret = dma_mapping_error(dma_dev, src_addr);
@@ -413,9 +402,10 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
 		goto err_unlock;
 	}
 
-	desc = dmaengine_prep_slave_single(chan, src_addr, buf_info->size,
-					   DMA_MEM_TO_DEV,
-					   DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+	desc = dmaengine_prep_slave_single_config(chan, src_addr, buf_info->size,
+						  DMA_MEM_TO_DEV,
+						  DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+						  &config);
 	if (!desc) {
 		dev_err(dev, "Failed to prepare DMA\n");
 		ret = -EIO;
@@ -502,12 +492,6 @@ static int pci_epf_mhi_edma_read_async(struct mhi_ep_cntrl *mhi_cntrl,
 	config.direction = DMA_DEV_TO_MEM;
 	config.src_addr = buf_info->host_addr;
 
-	ret = dmaengine_slave_config(chan, &config);
-	if (ret) {
-		dev_err(dev, "Failed to configure DMA channel\n");
-		goto err_unlock;
-	}
-
 	dst_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
 				  DMA_FROM_DEVICE);
 	ret = dma_mapping_error(dma_dev, dst_addr);
@@ -516,9 +500,10 @@ static int pci_epf_mhi_edma_read_async(struct mhi_ep_cntrl *mhi_cntrl,
 		goto err_unlock;
 	}
 
-	desc = dmaengine_prep_slave_single(chan, dst_addr, buf_info->size,
-					   DMA_DEV_TO_MEM,
-					   DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+	desc = dmaengine_prep_slave_single_config(chan, dst_addr, buf_info->size,
+						  DMA_DEV_TO_MEM,
+						  DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+						  &config);
 	if (!desc) {
 		dev_err(dev, "Failed to prepare DMA\n");
 		ret = -EIO;
@@ -581,12 +566,6 @@ static int pci_epf_mhi_edma_write_async(struct mhi_ep_cntrl *mhi_cntrl,
 	config.direction = DMA_MEM_TO_DEV;
 	config.dst_addr = buf_info->host_addr;
 
-	ret = dmaengine_slave_config(chan, &config);
-	if (ret) {
-		dev_err(dev, "Failed to configure DMA channel\n");
-		goto err_unlock;
-	}
-
 	src_addr = dma_map_single(dma_dev, buf_info->dev_addr, buf_info->size,
 				  DMA_TO_DEVICE);
 	ret = dma_mapping_error(dma_dev, src_addr);
@@ -595,9 +574,10 @@ static int pci_epf_mhi_edma_write_async(struct mhi_ep_cntrl *mhi_cntrl,
 		goto err_unlock;
 	}
 
-	desc = dmaengine_prep_slave_single(chan, src_addr, buf_info->size,
-					   DMA_MEM_TO_DEV,
-					   DMA_CTRL_ACK | DMA_PREP_INTERRUPT);
+	desc = dmaengine_prep_slave_single_config(chan, src_addr, buf_info->size,
+						  DMA_MEM_TO_DEV,
+						  DMA_CTRL_ACK | DMA_PREP_INTERRUPT,
+						  &config);
 	if (!desc) {
 		dev_err(dev, "Failed to prepare DMA\n");
 		ret = -EIO;

-- 
2.34.1

[PATCH 8/8] crypto: atmel: Use dmaengine_prep_slave_single_config() API

[Frank Li]

Using new API dmaengine_prep_slave_single_config() to simple code.

No functional change.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
 drivers/crypto/atmel-aes.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-aes.c
index 3a2684208dda9ee45d71b4bc2958be293a4fb6fe..14d46186865a1a6d8a11486b8f3aca92341fb1f9 100644
--- a/drivers/crypto/atmel-aes.c
+++ b/drivers/crypto/atmel-aes.c
@@ -820,12 +820,10 @@ static int atmel_aes_dma_transfer_start(struct atmel_aes_dev *dd,
 		return -EINVAL;
 	}
 
-	err = dmaengine_slave_config(dma->chan, &config);
-	if (err)
-		return err;
-
-	desc = dmaengine_prep_slave_sg(dma->chan, dma->sg, dma->sg_len, dir,
-				       DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+	desc = dmaengine_prep_slave_sg_config(dma->chan, dma->sg, dma->sg_len,
+					      dir,
+					      DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
+					      &config);
 	if (!desc)
 		return -ENOMEM;
 

-- 
2.34.1

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

[Christoph Hellwig]

On Mon, Dec 08, 2025 at 12:09:40PM -0500, 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 and callback device_prep_slave_sg_config that combines
> configuration and preparation into a single operation. If the configuration
> argument is passed as NULL, fall back to the existing implementation.

Maybe this would be a good time to start retiring the "slave" naming
and come up with shorter names as a win-win situation?

Re: [PATCH 6/8] nvmet: pci-epf: Use dmaengine_prep_slave_single_config() API

[Christoph Hellwig]

> +	desc = dmaengine_prep_slave_single_config(chan, dma_addr, seg->length,
> +						  sconf.direction,
> +						  DMA_CTRL_ACK,
> +						  &sconf);


If you stick to tab-indents this becomes a lot more readable:

	desc = dmaengine_prep_slave_single_config(chan, dma_addr, seg->length,
			sconf.direction, DMA_CTRL_ACK, &sconf);

Re: [PATCH 5/8] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer

[Damien Le Moal]

On 12/9/25 2:09 AM, Frank Li wrote:
> dmaengine_terminate_sync() cancels all pending requests. Calling it for
> every DMA transfer is unnecessary and counterproductive. This function is
> generally intended for cleanup paths such as module removal, device close,
> or unbind operations.
> 
> Remove the redundant calls.
> 
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> This one also fix stress test failure after remove mutex and use new API
> dmaengine_prep_slave_sg_config().
> ---
>  drivers/nvme/target/pci-epf.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index 2e78397a7373a7d8ba67150f301f392123db88d1..85225a4f75b5bd7abb6897d064123766af021542 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -420,8 +420,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  		ret = -EIO;
>  	}
>  
> -	dmaengine_terminate_sync(chan);

If the above dma_sync_wait failed, we better call this here as we have no idea
why we got the failure, no ?
For success case, we indeed may want to remove it.

> -
>  unmap:
>  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
>  
> 


-- 
Damien Le Moal
Western Digital Research

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

[Niklas Cassel]

On Mon, Dec 08, 2025 at 12:09:39PM -0500, Frank Li wrote:
> 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

For the series (tested using drivers/nvme/target/pci-epf.c):
Tested-by: Niklas Cassel <cassel@kernel.org>

Mainline:
  Rnd read,    4KB,  QD=1, 1 job :  IOPS=5721, BW=22.3MiB/s (23.4MB/s)
  Rnd read,    4KB, QD=32, 1 job :  IOPS=51.8k, BW=202MiB/s (212MB/s)
  Rnd read,    4KB, QD=32, 4 jobs:  IOPS=109k, BW=426MiB/s (447MB/s)
  Rnd read,  128KB,  QD=1, 1 job :  IOPS=2678, BW=335MiB/s (351MB/s)
  Rnd read,  128KB, QD=32, 1 job :  IOPS=19.1k, BW=2388MiB/s (2504MB/s)
  Rnd read,  128KB, QD=32, 4 jobs:  IOPS=18.1k, BW=2258MiB/s (2368MB/s)
  Rnd read,  512KB,  QD=1, 1 job :  IOPS=1388, BW=694MiB/s (728MB/s)
  Rnd read,  512KB, QD=32, 1 job :  IOPS=4554, BW=2277MiB/s (2388MB/s)
  Rnd read,  512KB, QD=32, 4 jobs:  IOPS=4516, BW=2258MiB/s (2368MB/s)
  Rnd write,   4KB,  QD=1, 1 job :  IOPS=4679, BW=18.3MiB/s (19.2MB/s)
  Rnd write,   4KB, QD=32, 1 job :  IOPS=35.1k, BW=137MiB/s (144MB/s)
  Rnd write,   4KB, QD=32, 4 jobs:  IOPS=33.7k, BW=132MiB/s (138MB/s)
  Rnd write, 128KB,  QD=1, 1 job :  IOPS=2490, BW=311MiB/s (326MB/s)
  Rnd write, 128KB, QD=32, 1 job :  IOPS=4964, BW=621MiB/s (651MB/s)
  Rnd write, 128KB, QD=32, 4 jobs:  IOPS=4966, BW=621MiB/s (651MB/s)
  Seq read,  128KB,  QD=1, 1 job :  IOPS=2586, BW=323MiB/s (339MB/s)
  Seq read,  128KB, QD=32, 1 job :  IOPS=17.5k, BW=2190MiB/s (2296MB/s)
  Seq read,  512KB,  QD=1, 1 job :  IOPS=1614, BW=807MiB/s (847MB/s)
  Seq read,  512KB, QD=32, 1 job :  IOPS=4540, BW=2270MiB/s (2381MB/s)
  Seq read,    1MB, QD=32, 1 job :  IOPS=2283, BW=2284MiB/s (2395MB/s)
  Seq write, 128KB,  QD=1, 1 job :  IOPS=2313, BW=289MiB/s (303MB/s)
  Seq write, 128KB, QD=32, 1 job :  IOPS=4948, BW=619MiB/s (649MB/s)
  Seq write, 512KB,  QD=1, 1 job :  IOPS=901, BW=451MiB/s (473MB/s)
  Seq write, 512KB, QD=32, 1 job :  IOPS=1289, BW=645MiB/s (676MB/s)
  Seq write,   1MB, QD=32, 1 job :  IOPS=632, BW=633MiB/s (663MB/s)
  Rnd rdwr, 4K..1MB, QD=8, 4 jobs:  IOPS=1756, BW=880MiB/s (923MB/s)
 IOPS=1767, BW=886MiB/s (929MB/s)


Mainline + this series applied:
  Rnd read,    4KB,  QD=1, 1 job :  IOPS=3681, BW=14.4MiB/s (15.1MB/s)
  Rnd read,    4KB, QD=32, 1 job :  IOPS=54.8k, BW=214MiB/s (224MB/s)
  Rnd read,    4KB, QD=32, 4 jobs:  IOPS=123k, BW=479MiB/s (502MB/s)
  Rnd read,  128KB,  QD=1, 1 job :  IOPS=2132, BW=267MiB/s (280MB/s)
  Rnd read,  128KB, QD=32, 1 job :  IOPS=19.0k, BW=2369MiB/s (2485MB/s)
  Rnd read,  128KB, QD=32, 4 jobs:  IOPS=18.7k, BW=2341MiB/s (2454MB/s)
  Rnd read,  512KB,  QD=1, 1 job :  IOPS=1135, BW=568MiB/s (595MB/s)
  Rnd read,  512KB, QD=32, 1 job :  IOPS=4546, BW=2273MiB/s (2384MB/s)
  Rnd read,  512KB, QD=32, 4 jobs:  IOPS=4708, BW=2354MiB/s (2469MB/s)
  Rnd write,   4KB,  QD=1, 1 job :  IOPS=3369, BW=13.2MiB/s (13.8MB/s)
  Rnd write,   4KB, QD=32, 1 job :  IOPS=31.7k, BW=124MiB/s (130MB/s)
  Rnd write,   4KB, QD=32, 4 jobs:  IOPS=31.1k, BW=122MiB/s (127MB/s)
  Rnd write, 128KB,  QD=1, 1 job :  IOPS=1820, BW=228MiB/s (239MB/s)
  Rnd write, 128KB, QD=32, 1 job :  IOPS=5703, BW=713MiB/s (748MB/s)
  Rnd write, 128KB, QD=32, 4 jobs:  IOPS=5813, BW=727MiB/s (762MB/s)
  Seq read,  128KB,  QD=1, 1 job :  IOPS=1958, BW=245MiB/s (257MB/s)
  Seq read,  128KB, QD=32, 1 job :  IOPS=18.8k, BW=2345MiB/s (2459MB/s)
  Seq read,  512KB,  QD=1, 1 job :  IOPS=1319, BW=660MiB/s (692MB/s)
  Seq read,  512KB, QD=32, 1 job :  IOPS=4542, BW=2271MiB/s (2382MB/s)
  Seq read,    1MB, QD=32, 1 job :  IOPS=2325, BW=2325MiB/s (2438MB/s)
  Seq write, 128KB,  QD=1, 1 job :  IOPS=2174, BW=272MiB/s (285MB/s)
  Seq write, 128KB, QD=32, 1 job :  IOPS=5697, BW=712MiB/s (747MB/s)
  Seq write, 512KB,  QD=1, 1 job :  IOPS=1035, BW=518MiB/s (543MB/s)
  Seq write, 512KB, QD=32, 1 job :  IOPS=1462, BW=731MiB/s (767MB/s)
  Seq write,   1MB, QD=32, 1 job :  IOPS=720, BW=721MiB/s (756MB/s)
  Rnd rdwr, 4K..1MB, QD=8, 4 jobs:  IOPS=2029, BW=1018MiB/s (1067MB/s)
 IOPS=2037, BW=1023MiB/s (1072MB/s)


Small performance boost, but I think the nicest thing with this series is
to be able to remove the ugly mutex in pci-epf.c.


Kind regards,
Niklas

Re: [PATCH 5/8] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer

[Frank Li]

On Tue, Dec 09, 2025 at 03:52:15PM +0900, Damien Le Moal wrote:
> On 12/9/25 2:09 AM, Frank Li wrote:
> > dmaengine_terminate_sync() cancels all pending requests. Calling it for
> > every DMA transfer is unnecessary and counterproductive. This function is
> > generally intended for cleanup paths such as module removal, device close,
> > or unbind operations.
> >
> > Remove the redundant calls.
> >
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > ---
> > This one also fix stress test failure after remove mutex and use new API
> > dmaengine_prep_slave_sg_config().
> > ---
> >  drivers/nvme/target/pci-epf.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> > index 2e78397a7373a7d8ba67150f301f392123db88d1..85225a4f75b5bd7abb6897d064123766af021542 100644
> > --- a/drivers/nvme/target/pci-epf.c
> > +++ b/drivers/nvme/target/pci-epf.c
> > @@ -420,8 +420,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
> >  		ret = -EIO;
> >  	}
> >
> > -	dmaengine_terminate_sync(chan);
>
> If the above dma_sync_wait failed, we better call this here as we have no idea
> why we got the failure, no ?

Yes, it should be call at only failure case.

Frank
> For success case, we indeed may want to remove it.
>
> > -
> >  unmap:
> >  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
> >
> >
>
>
> --
> Damien Le Moal
> Western Digital Research

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

[Frank Li]

On Tue, Dec 09, 2025 at 07:38:09AM +0100, Christoph Hellwig wrote:
> On Mon, Dec 08, 2025 at 12:09:40PM -0500, 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 and callback device_prep_slave_sg_config that combines
> > configuration and preparation into a single operation. If the configuration
> > argument is passed as NULL, fall back to the existing implementation.
>
> Maybe this would be a good time to start retiring the "slave" naming
> and come up with shorter names as a win-win situation?

Yes, 'prep_sg_config' or 'prep_sg' should be enough.

Frank
>

Re: [PATCH 6/8] nvmet: pci-epf: Use dmaengine_prep_slave_single_config() API

[kernel test robot]

Hi Frank,

kernel test robot noticed the following build warnings:

[auto build test WARNING on bc04acf4aeca588496124a6cf54bfce3db327039]

url:    https://github.com/intel-lab-lkp/linux/commits/Frank-Li/dmaengine-Add-API-to-combine-configuration-and-preparation-sg-and-single/20251209-011820
base:   bc04acf4aeca588496124a6cf54bfce3db327039
patch link:    https://lore.kernel.org/r/20251208-dma_prep_config-v1-6-53490c5e1e2a%40nxp.com
patch subject: [PATCH 6/8] nvmet: pci-epf: Use dmaengine_prep_slave_single_config() API
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20251211/202512110249.kCiMC4sb-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251211/202512110249.kCiMC4sb-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512110249.kCiMC4sb-lkp@intel.com/

All warnings (new ones prefixed by >>):

   drivers/nvme/target/pci-epf.c: In function 'nvmet_pci_epf_dma_transfer':
>> drivers/nvme/target/pci-epf.c:369:23: warning: variable 'lock' set but not used [-Wunused-but-set-variable]
     369 |         struct mutex *lock;
         |                       ^~~~


vim +/lock +369 drivers/nvme/target/pci-epf.c

0faa0fe6f90ea5 Damien Le Moal 2025-01-04  357  
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  358  static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  359  		struct nvmet_pci_epf_segment *seg, enum dma_data_direction dir)
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  360  {
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  361  	struct pci_epf *epf = nvme_epf->epf;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  362  	struct dma_async_tx_descriptor *desc;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  363  	struct dma_slave_config sconf = {};
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  364  	struct device *dev = &epf->dev;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  365  	struct device *dma_dev;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  366  	struct dma_chan *chan;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  367  	dma_cookie_t cookie;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  368  	dma_addr_t dma_addr;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04 @369  	struct mutex *lock;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  370  	int ret;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  371  
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  372  	switch (dir) {
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  373  	case DMA_FROM_DEVICE:
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  374  		lock = &nvme_epf->dma_rx_lock;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  375  		chan = nvme_epf->dma_rx_chan;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  376  		sconf.direction = DMA_DEV_TO_MEM;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  377  		sconf.src_addr = seg->pci_addr;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  378  		break;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  379  	case DMA_TO_DEVICE:
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  380  		lock = &nvme_epf->dma_tx_lock;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  381  		chan = nvme_epf->dma_tx_chan;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  382  		sconf.direction = DMA_MEM_TO_DEV;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  383  		sconf.dst_addr = seg->pci_addr;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  384  		break;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  385  	default:
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  386  		return -EINVAL;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  387  	}
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  388  
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  389  	dma_dev = dmaengine_get_dma_device(chan);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  390  	dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  391  	ret = dma_mapping_error(dma_dev, dma_addr);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  392  	if (ret)
f9f42a84df49d9 Frank Li       2025-12-08  393  		return ret;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  394  
f9f42a84df49d9 Frank Li       2025-12-08  395  	desc = dmaengine_prep_slave_single_config(chan, dma_addr, seg->length,
f9f42a84df49d9 Frank Li       2025-12-08  396  						  sconf.direction,
f9f42a84df49d9 Frank Li       2025-12-08  397  						  DMA_CTRL_ACK,
f9f42a84df49d9 Frank Li       2025-12-08  398  						  &sconf);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  399  	if (!desc) {
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  400  		dev_err(dev, "Failed to prepare DMA\n");
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  401  		ret = -EIO;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  402  		goto unmap;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  403  	}
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  404  
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  405  	cookie = dmaengine_submit(desc);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  406  	ret = dma_submit_error(cookie);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  407  	if (ret) {
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  408  		dev_err(dev, "Failed to do DMA submit (err=%d)\n", ret);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  409  		goto unmap;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  410  	}
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  411  
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  412  	if (dma_sync_wait(chan, cookie) != DMA_COMPLETE) {
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  413  		dev_err(dev, "DMA transfer failed\n");
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  414  		ret = -EIO;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  415  	}
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  416  
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  417  unmap:
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  418  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  419  
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  420  	return ret;
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  421  }
0faa0fe6f90ea5 Damien Le Moal 2025-01-04  422  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 2/8] PCI: endpoint: pci-epf-test: use new DMA API to simple code

[Bjorn Helgaas]

On Mon, Dec 08, 2025 at 12:09:41PM -0500, Frank Li wrote:
> Using new API dmaengine_prep_slave_single_config() to simple code.

Capitalize and include actual interface:

  PCI: endpoint: pci-epf-test: Use dmaengine_prep_slave_single_config() to simplify code

  Use dmaengine_prep_slave_single_config() to simplify code

Re: [PATCH 7/8] PCI: epf-mhi:Using new API dmaengine_prep_slave_single_config() to simple code.

[Bjorn Helgaas]

On Mon, Dec 08, 2025 at 12:09:46PM -0500, Frank Li wrote:

Add space, include actual interface, add commit log:

  PCI: epf-mhi: Use dmaengine_prep_slave_single_config() to simplify code

  Use dmaengine_prep_slave_single_config() to simplify
  pci_epf_mhi_edma_read(), pci_epf_mhi_edma_write(), etc.

Re: [PATCH 6/8] nvmet: pci-epf: Use dmaengine_prep_slave_single_config() API

[Bjorn Helgaas]

On Mon, Dec 08, 2025 at 12:09:45PM -0500, Frank Li wrote:
> Use the new dmaengine_prep_slave_single_config() API to combine the
> configuration and descriptor preparation into a single call.
> 
> Since dmaengine_prep_slave_single_config() performs the configuration
> and preparation atomically, the mutex can be removed.

> @@ -386,22 +386,16 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  		return -EINVAL;
>  	}
>  
> -	mutex_lock(lock);
> -
>  	dma_dev = dmaengine_get_dma_device(chan);
>  	dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
>  	ret = dma_mapping_error(dma_dev, dma_addr);
>  	if (ret)
> -		goto unlock;
> -
> -	ret = dmaengine_slave_config(chan, &sconf);
> -	if (ret) {
> -		dev_err(dev, "Failed to configure DMA channel\n");
> -		goto unmap;
> -	}
> +		return ret;
>  
> -	desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
> -					   sconf.direction, DMA_CTRL_ACK);
> +	desc = dmaengine_prep_slave_single_config(chan, dma_addr, seg->length,
> +						  sconf.direction,
> +						  DMA_CTRL_ACK,
> +						  &sconf);
>  	if (!desc) {
>  		dev_err(dev, "Failed to prepare DMA\n");
>  		ret = -EIO;
> @@ -423,9 +417,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  unmap:
>  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
>  
> -unlock:
> -	mutex_unlock(lock);
> -

I don't know the dmaengine code, but it's not obvious to me what makes
dmaengine_prep_slave_single_config() itself atomic, since it doesn't
contain any locking.

Bjorn

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

[Bjorn Helgaas]

On Mon, Dec 08, 2025 at 12:09:40PM -0500, 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 and callback device_prep_slave_sg_config that combines
> configuration and preparation into a single operation. If the configuration
> argument is passed as NULL, fall back to the existing implementation.

Add "()" after function name.

> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>  include/linux/dmaengine.h | 64 +++++++++++++++++++++++++++++++++++++++++------
>  1 file changed, 57 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 99efe2b9b4ea9844ca6161208362ef18ef111d96..6c563549133a28e26f1bdc367372b1e4a748afcf 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -835,6 +835,8 @@ struct dma_filter {
>   *	where the address and size of each segment is located in one entry of
>   *	the dma_vec array.
>   * @device_prep_slave_sg: prepares a slave dma operation
> + *	(Depericated, use @device_prep_slave_sg_config)
> + * @device_prep_slave_sg_config: prepares a slave dma operation

s/Depericated/Deprecated/
s/slave dma/slave DMA/ to match other "DMA" uses

Re: [PATCH 8/8] crypto: atmel: Use dmaengine_prep_slave_single_config() API

[kernel test robot]

Hi Frank,

kernel test robot noticed the following build warnings:

[auto build test WARNING on bc04acf4aeca588496124a6cf54bfce3db327039]

url:    https://github.com/intel-lab-lkp/linux/commits/Frank-Li/dmaengine-Add-API-to-combine-configuration-and-preparation-sg-and-single/20251209-011820
base:   bc04acf4aeca588496124a6cf54bfce3db327039
patch link:    https://lore.kernel.org/r/20251208-dma_prep_config-v1-8-53490c5e1e2a%40nxp.com
patch subject: [PATCH 8/8] crypto: atmel: Use dmaengine_prep_slave_single_config() API
config: i386-allmodconfig (https://download.01.org/0day-ci/archive/20251211/202512110702.EhO0gmFG-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251211/202512110702.EhO0gmFG-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202512110702.EhO0gmFG-lkp@intel.com/

All warnings (new ones prefixed by >>):

   drivers/crypto/atmel-aes.c: In function 'atmel_aes_dma_transfer_start':
>> drivers/crypto/atmel-aes.c:798:13: warning: unused variable 'err' [-Wunused-variable]
     798 |         int err;
         |             ^~~


vim +/err +798 drivers/crypto/atmel-aes.c

cadc4ab8f6f737 Nicolas Royer   2013-02-20  788  
bbe628ed897d72 Cyrille Pitchen 2015-12-17  789  static int atmel_aes_dma_transfer_start(struct atmel_aes_dev *dd,
bbe628ed897d72 Cyrille Pitchen 2015-12-17  790  					enum dma_slave_buswidth addr_width,
bbe628ed897d72 Cyrille Pitchen 2015-12-17  791  					enum dma_transfer_direction dir,
bbe628ed897d72 Cyrille Pitchen 2015-12-17  792  					u32 maxburst)
bbe628ed897d72 Cyrille Pitchen 2015-12-17  793  {
bbe628ed897d72 Cyrille Pitchen 2015-12-17  794  	struct dma_async_tx_descriptor *desc;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  795  	struct dma_slave_config config;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  796  	dma_async_tx_callback callback;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  797  	struct atmel_aes_dma *dma;
bbe628ed897d72 Cyrille Pitchen 2015-12-17 @798  	int err;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  799  
bbe628ed897d72 Cyrille Pitchen 2015-12-17  800  	memset(&config, 0, sizeof(config));
bbe628ed897d72 Cyrille Pitchen 2015-12-17  801  	config.src_addr_width = addr_width;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  802  	config.dst_addr_width = addr_width;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  803  	config.src_maxburst = maxburst;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  804  	config.dst_maxburst = maxburst;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  805  
bbe628ed897d72 Cyrille Pitchen 2015-12-17  806  	switch (dir) {
bbe628ed897d72 Cyrille Pitchen 2015-12-17  807  	case DMA_MEM_TO_DEV:
bbe628ed897d72 Cyrille Pitchen 2015-12-17  808  		dma = &dd->src;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  809  		callback = NULL;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  810  		config.dst_addr = dd->phys_base + AES_IDATAR(0);
bbe628ed897d72 Cyrille Pitchen 2015-12-17  811  		break;
cadc4ab8f6f737 Nicolas Royer   2013-02-20  812  
bbe628ed897d72 Cyrille Pitchen 2015-12-17  813  	case DMA_DEV_TO_MEM:
bbe628ed897d72 Cyrille Pitchen 2015-12-17  814  		dma = &dd->dst;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  815  		callback = atmel_aes_dma_callback;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  816  		config.src_addr = dd->phys_base + AES_ODATAR(0);
bbe628ed897d72 Cyrille Pitchen 2015-12-17  817  		break;
cadc4ab8f6f737 Nicolas Royer   2013-02-20  818  
bbe628ed897d72 Cyrille Pitchen 2015-12-17  819  	default:
cadc4ab8f6f737 Nicolas Royer   2013-02-20  820  		return -EINVAL;
cadc4ab8f6f737 Nicolas Royer   2013-02-20  821  	}
cadc4ab8f6f737 Nicolas Royer   2013-02-20  822  
c8695132080931 Frank Li        2025-12-08  823  	desc = dmaengine_prep_slave_sg_config(dma->chan, dma->sg, dma->sg_len,
c8695132080931 Frank Li        2025-12-08  824  					      dir,
c8695132080931 Frank Li        2025-12-08  825  					      DMA_PREP_INTERRUPT | DMA_CTRL_ACK,
c8695132080931 Frank Li        2025-12-08  826  					      &config);
bbe628ed897d72 Cyrille Pitchen 2015-12-17  827  	if (!desc)
bbe628ed897d72 Cyrille Pitchen 2015-12-17  828  		return -ENOMEM;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  829  
bbe628ed897d72 Cyrille Pitchen 2015-12-17  830  	desc->callback = callback;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  831  	desc->callback_param = dd;
bbe628ed897d72 Cyrille Pitchen 2015-12-17  832  	dmaengine_submit(desc);
bbe628ed897d72 Cyrille Pitchen 2015-12-17  833  	dma_async_issue_pending(dma->chan);
bbe628ed897d72 Cyrille Pitchen 2015-12-17  834  
bbe628ed897d72 Cyrille Pitchen 2015-12-17  835  	return 0;
cadc4ab8f6f737 Nicolas Royer   2013-02-20  836  }
cadc4ab8f6f737 Nicolas Royer   2013-02-20  837  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Vinod Koul]

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.
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).

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@nxp.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@nxp.com>

-- 
~Vinod

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

[Frank Li]

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()"

I think "peripheral" also is reduntant. dmaengine_prep_single() and
dmaengine_prep_sg() should be enough because
- 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@nxp.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@nxp.com>
>
> --
> ~Vinod

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

[Vinod Koul]

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!

> 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

> - 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@nxp.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@nxp.com>
> >
> > --
> > ~Vinod

-- 
~Vinod

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

[Frank Li]

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@nxp.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@nxp.com>
> > >
> > > --
> > > ~Vinod
>
> --
> ~Vinod

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

[Vinod Koul]

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 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

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

[Frank Li]

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

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

[Vinod Koul]

On 16-12-25, 12:28, Frank Li wrote:
> On Tue, Dec 16, 2025 at 10:47:57PM +0530, Vinod Koul wrote:
> > On 16-12-25, 10:55, Frank Li wrote:
> > > 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?)

Yes that is a good idea. config does imply peripheral cases. Please make
sure API documentation marks that clearly

BR
-- 
~Vinod