[PATCH RESEND v10 0/2] Add AMD MDB Endpoint and non-LL mode Support

[PATCH RESEND v10 0/2] Add AMD MDB Endpoint and non-LL mode Support

[Devendra K Verma]

This series of patch support the following:

 - AMD MDB Endpoint Support, as part of this patch following are
   added:
   o AMD supported device ID and vendor ID (Xilinx)
   o AMD MDB specific driver data
   o AMD specific VSEC capabilities to retrieve the base of
     phys address of MDB side DDR
   o Logic to assign the offsets to LL and data blocks if
     more number of channels are enabled than configured
     in the given pci_data struct.

 - Addition of non-LL mode
   o The IP supported non-LL mode functions
   o Flexibility to choose non-LL mode via dma_slave_config
     param peripheral_config, by the client for all the vendors
     using HDMA IP.
   o Allow IP utilization if LL mode is not available

Devendra K Verma (2):
  dmaengine: dw-edma: Add AMD MDB Endpoint Support
  dmaengine: dw-edma: Add non-LL mode

 drivers/dma/dw-edma/dw-edma-core.c    |  35 +++-
 drivers/dma/dw-edma/dw-edma-core.h    |   1 +
 drivers/dma/dw-edma/dw-edma-pcie.c    | 220 +++++++++++++++++++++++---
 drivers/dma/dw-edma/dw-hdma-v0-core.c |  65 +++++++-
 drivers/dma/dw-edma/dw-hdma-v0-regs.h |   1 +
 include/linux/dma/edma.h              |   1 +
 6 files changed, 301 insertions(+), 22 deletions(-)

-- 
2.43.0

[PATCH RESEND v10 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support

[Devendra K Verma]

AMD MDB PCIe endpoint support. For AMD specific support
added the following
  - AMD supported PCIe Device IDs and Vendor ID (Xilinx).
  - AMD MDB specific driver data
  - AMD MDB specific VSEC capability to retrieve the device DDR
    base address.

Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
---
Changes in v10:
For Xilinx VSEC function kept only HDMA map format as
Xilinx only supports HDMA.

Changes in v9:
Moved Xilinx specific VSEC capability functions under
the vendor ID condition.

Changes in v8:
Changed the contant names to includer product vendor.
Moved the vendor specific code to vendor specific functions.

Changes in v7:
Introduced vendor specific functions to retrieve the
vsec data.

Changes in v6:
Included "sizes.h" header and used the appropriate
definitions instead of constants.

Changes in v5:
Added the definitions for Xilinx specific VSEC header id,
revision, and register offsets.
Corrected the error type when no physical offset found for
device side memory.
Corrected the order of variables.

Changes in v4:
Configured 8 read and 8 write channels for Xilinx vendor
Added checks to validate vendor ID for vendor
specific vsec id.
Added Xilinx specific vendor id for vsec specific to Xilinx
Added the LL and data region offsets, size as input params to
function dw_edma_set_chan_region_offset().
Moved the LL and data region offsets assignment to function
for Xilinx specific case.
Corrected comments.

Changes in v3:
Corrected a typo when assigning AMD (Xilinx) vsec id macro
and condition check.

Changes in v2:
Reverted the devmem_phys_off type to u64.
Renamed the function appropriately to suit the
functionality for setting the LL & data region offsets.

Changes in v1:
Removed the pci device id from pci_ids.h file.
Added the vendor id macro as per the suggested method.
Changed the type of the newly added devmem_phys_off variable.
Added to logic to assign offsets for LL and data region blocks
in case more number of channels are enabled than given in
amd_mdb_data struct.
---
 drivers/dma/dw-edma/dw-edma-pcie.c | 190 ++++++++++++++++++++++++++---
 1 file changed, 176 insertions(+), 14 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index 3371e0a76d3c..3aefc48f8e0a 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -14,14 +14,35 @@
 #include <linux/pci-epf.h>
 #include <linux/msi.h>
 #include <linux/bitfield.h>
+#include <linux/sizes.h>
 
 #include "dw-edma-core.h"
 
-#define DW_PCIE_VSEC_DMA_ID			0x6
-#define DW_PCIE_VSEC_DMA_BAR			GENMASK(10, 8)
-#define DW_PCIE_VSEC_DMA_MAP			GENMASK(2, 0)
-#define DW_PCIE_VSEC_DMA_WR_CH			GENMASK(9, 0)
-#define DW_PCIE_VSEC_DMA_RD_CH			GENMASK(25, 16)
+/* Synopsys */
+#define DW_PCIE_SYNOPSYS_VSEC_DMA_ID		0x6
+#define DW_PCIE_SYNOPSYS_VSEC_DMA_BAR		GENMASK(10, 8)
+#define DW_PCIE_SYNOPSYS_VSEC_DMA_MAP		GENMASK(2, 0)
+#define DW_PCIE_SYNOPSYS_VSEC_DMA_WR_CH		GENMASK(9, 0)
+#define DW_PCIE_SYNOPSYS_VSEC_DMA_RD_CH		GENMASK(25, 16)
+
+/* AMD MDB (Xilinx) specific defines */
+#define PCI_DEVICE_ID_XILINX_B054		0xb054
+
+#define DW_PCIE_XILINX_MDB_VSEC_DMA_ID		0x6
+#define DW_PCIE_XILINX_MDB_VSEC_ID		0x20
+#define DW_PCIE_XILINX_MDB_VSEC_DMA_BAR		GENMASK(10, 8)
+#define DW_PCIE_XILINX_MDB_VSEC_DMA_MAP		GENMASK(2, 0)
+#define DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH	GENMASK(9, 0)
+#define DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH	GENMASK(25, 16)
+
+#define DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH	0xc
+#define DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW	0x8
+#define DW_PCIE_XILINX_MDB_INVALID_ADDR		(~0ULL)
+
+#define DW_PCIE_XILINX_MDB_LL_OFF_GAP		0x200000
+#define DW_PCIE_XILINX_MDB_LL_SIZE		0x800
+#define DW_PCIE_XILINX_MDB_DT_OFF_GAP		0x100000
+#define DW_PCIE_XILINX_MDB_DT_SIZE		0x800
 
 #define DW_BLOCK(a, b, c) \
 	{ \
@@ -50,6 +71,7 @@ struct dw_edma_pcie_data {
 	u8				irqs;
 	u16				wr_ch_cnt;
 	u16				rd_ch_cnt;
+	u64				devmem_phys_off;
 };
 
 static const struct dw_edma_pcie_data snps_edda_data = {
@@ -90,6 +112,64 @@ static const struct dw_edma_pcie_data snps_edda_data = {
 	.rd_ch_cnt			= 2,
 };
 
+static const struct dw_edma_pcie_data xilinx_mdb_data = {
+	/* MDB registers location */
+	.rg.bar				= BAR_0,
+	.rg.off				= SZ_4K,	/*  4 Kbytes */
+	.rg.sz				= SZ_8K,	/*  8 Kbytes */
+
+	/* Other */
+	.mf				= EDMA_MF_HDMA_NATIVE,
+	.irqs				= 1,
+	.wr_ch_cnt			= 8,
+	.rd_ch_cnt			= 8,
+};
+
+static void dw_edma_set_chan_region_offset(struct dw_edma_pcie_data *pdata,
+					   enum pci_barno bar, off_t start_off,
+					   off_t ll_off_gap, size_t ll_size,
+					   off_t dt_off_gap, size_t dt_size)
+{
+	u16 wr_ch = pdata->wr_ch_cnt;
+	u16 rd_ch = pdata->rd_ch_cnt;
+	off_t off;
+	u16 i;
+
+	off = start_off;
+
+	/* Write channel LL region */
+	for (i = 0; i < wr_ch; i++) {
+		pdata->ll_wr[i].bar = bar;
+		pdata->ll_wr[i].off = off;
+		pdata->ll_wr[i].sz = ll_size;
+		off += ll_off_gap;
+	}
+
+	/* Read channel LL region */
+	for (i = 0; i < rd_ch; i++) {
+		pdata->ll_rd[i].bar = bar;
+		pdata->ll_rd[i].off = off;
+		pdata->ll_rd[i].sz = ll_size;
+		off += ll_off_gap;
+	}
+
+	/* Write channel data region */
+	for (i = 0; i < wr_ch; i++) {
+		pdata->dt_wr[i].bar = bar;
+		pdata->dt_wr[i].off = off;
+		pdata->dt_wr[i].sz = dt_size;
+		off += dt_off_gap;
+	}
+
+	/* Read channel data region */
+	for (i = 0; i < rd_ch; i++) {
+		pdata->dt_rd[i].bar = bar;
+		pdata->dt_rd[i].off = off;
+		pdata->dt_rd[i].sz = dt_size;
+		off += dt_off_gap;
+	}
+}
+
 static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
 {
 	return pci_irq_vector(to_pci_dev(dev), nr);
@@ -114,15 +194,15 @@ static const struct dw_edma_plat_ops dw_edma_pcie_plat_ops = {
 	.pci_address = dw_edma_pcie_address,
 };
 
-static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
-					   struct dw_edma_pcie_data *pdata)
+static void dw_edma_pcie_get_synopsys_dma_data(struct pci_dev *pdev,
+					       struct dw_edma_pcie_data *pdata)
 {
 	u32 val, map;
 	u16 vsec;
 	u64 off;
 
 	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_SYNOPSYS,
-					DW_PCIE_VSEC_DMA_ID);
+					DW_PCIE_SYNOPSYS_VSEC_DMA_ID);
 	if (!vsec)
 		return;
 
@@ -131,9 +211,9 @@ static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
 	    PCI_VNDR_HEADER_LEN(val) != 0x18)
 		return;
 
-	pci_dbg(pdev, "Detected PCIe Vendor-Specific Extended Capability DMA\n");
+	pci_dbg(pdev, "Detected Synopsys PCIe Vendor-Specific Extended Capability DMA\n");
 	pci_read_config_dword(pdev, vsec + 0x8, &val);
-	map = FIELD_GET(DW_PCIE_VSEC_DMA_MAP, val);
+	map = FIELD_GET(DW_PCIE_SYNOPSYS_VSEC_DMA_MAP, val);
 	if (map != EDMA_MF_EDMA_LEGACY &&
 	    map != EDMA_MF_EDMA_UNROLL &&
 	    map != EDMA_MF_HDMA_COMPAT &&
@@ -141,13 +221,13 @@ static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
 		return;
 
 	pdata->mf = map;
-	pdata->rg.bar = FIELD_GET(DW_PCIE_VSEC_DMA_BAR, val);
+	pdata->rg.bar = FIELD_GET(DW_PCIE_SYNOPSYS_VSEC_DMA_BAR, val);
 
 	pci_read_config_dword(pdev, vsec + 0xc, &val);
 	pdata->wr_ch_cnt = min_t(u16, pdata->wr_ch_cnt,
-				 FIELD_GET(DW_PCIE_VSEC_DMA_WR_CH, val));
+				 FIELD_GET(DW_PCIE_SYNOPSYS_VSEC_DMA_WR_CH, val));
 	pdata->rd_ch_cnt = min_t(u16, pdata->rd_ch_cnt,
-				 FIELD_GET(DW_PCIE_VSEC_DMA_RD_CH, val));
+				 FIELD_GET(DW_PCIE_SYNOPSYS_VSEC_DMA_RD_CH, val));
 
 	pci_read_config_dword(pdev, vsec + 0x14, &val);
 	off = val;
@@ -157,6 +237,64 @@ static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
 	pdata->rg.off = off;
 }
 
+static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
+					     struct dw_edma_pcie_data *pdata)
+{
+	u32 val, map;
+	u16 vsec;
+	u64 off;
+
+	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
+
+	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
+					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
+	if (!vsec)
+		return;
+
+	pci_read_config_dword(pdev, vsec + PCI_VNDR_HEADER, &val);
+	if (PCI_VNDR_HEADER_REV(val) != 0x00 ||
+	    PCI_VNDR_HEADER_LEN(val) != 0x18)
+		return;
+
+	pci_dbg(pdev, "Detected Xilinx PCIe Vendor-Specific Extended Capability DMA\n");
+	pci_read_config_dword(pdev, vsec + 0x8, &val);
+	map = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_MAP, val);
+	if (map != EDMA_MF_HDMA_NATIVE)
+		return;
+
+	pdata->mf = map;
+	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_BAR, val);
+
+	pci_read_config_dword(pdev, vsec + 0xc, &val);
+	pdata->wr_ch_cnt = min_t(u16, pdata->wr_ch_cnt,
+				 FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
+	pdata->rd_ch_cnt = min_t(u16, pdata->rd_ch_cnt,
+				 FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
+
+	pci_read_config_dword(pdev, vsec + 0x14, &val);
+	off = val;
+	pci_read_config_dword(pdev, vsec + 0x10, &val);
+	off <<= 32;
+	off |= val;
+	pdata->rg.off = off;
+
+	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
+					DW_PCIE_XILINX_MDB_VSEC_ID);
+	if (!vsec)
+		return;
+
+	pci_read_config_dword(pdev,
+			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
+			      &val);
+	off = val;
+	pci_read_config_dword(pdev,
+			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
+			      &val);
+	off <<= 32;
+	off |= val;
+	pdata->devmem_phys_off = off;
+}
+
 static int dw_edma_pcie_probe(struct pci_dev *pdev,
 			      const struct pci_device_id *pid)
 {
@@ -184,7 +322,29 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 	 * Tries to find if exists a PCIe Vendor-Specific Extended Capability
 	 * for the DMA, if one exists, then reconfigures it.
 	 */
-	dw_edma_pcie_get_vsec_dma_data(pdev, vsec_data);
+	dw_edma_pcie_get_synopsys_dma_data(pdev, vsec_data);
+
+	if (pdev->vendor == PCI_VENDOR_ID_XILINX) {
+		dw_edma_pcie_get_xilinx_dma_data(pdev, vsec_data);
+
+		/*
+		 * There is no valid address found for the LL memory
+		 * space on the device side.
+		 */
+		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_MDB_INVALID_ADDR)
+			return -ENOMEM;
+
+		/*
+		 * Configure the channel LL and data blocks if number of
+		 * channels enabled in VSEC capability are more than the
+		 * channels configured in xilinx_mdb_data.
+		 */
+		dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
+					       DW_PCIE_XILINX_MDB_LL_OFF_GAP,
+					       DW_PCIE_XILINX_MDB_LL_SIZE,
+					       DW_PCIE_XILINX_MDB_DT_OFF_GAP,
+					       DW_PCIE_XILINX_MDB_DT_SIZE);
+	}
 
 	/* Mapping PCI BAR regions */
 	mask = BIT(vsec_data->rg.bar);
@@ -367,6 +527,8 @@ static void dw_edma_pcie_remove(struct pci_dev *pdev)
 
 static const struct pci_device_id dw_edma_pcie_id_table[] = {
 	{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
+	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
+	  (kernel_ulong_t)&xilinx_mdb_data },
 	{ }
 };
 MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);
-- 
2.43.0

Re: [PATCH RESEND v10 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support

[Frank Li]

On Mon, Feb 16, 2026 at 04:25:45PM +0530, Devendra K Verma wrote:
> AMD MDB PCIe endpoint support. For AMD specific support
> added the following
>   - AMD supported PCIe Device IDs and Vendor ID (Xilinx).
>   - AMD MDB specific driver data
>   - AMD MDB specific VSEC capability to retrieve the device DDR
>     base address.
>
> Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> ---
> Changes in v10:
> For Xilinx VSEC function kept only HDMA map format as
> Xilinx only supports HDMA.
>
> Changes in v9:
> Moved Xilinx specific VSEC capability functions under
> the vendor ID condition.
>
> Changes in v8:
> Changed the contant names to includer product vendor.
> Moved the vendor specific code to vendor specific functions.
>
> Changes in v7:
> Introduced vendor specific functions to retrieve the
> vsec data.
>
> Changes in v6:
> Included "sizes.h" header and used the appropriate
> definitions instead of constants.
>
> Changes in v5:
> Added the definitions for Xilinx specific VSEC header id,
> revision, and register offsets.
> Corrected the error type when no physical offset found for
> device side memory.
> Corrected the order of variables.
>
> Changes in v4:
> Configured 8 read and 8 write channels for Xilinx vendor
> Added checks to validate vendor ID for vendor
> specific vsec id.
> Added Xilinx specific vendor id for vsec specific to Xilinx
> Added the LL and data region offsets, size as input params to
> function dw_edma_set_chan_region_offset().
> Moved the LL and data region offsets assignment to function
> for Xilinx specific case.
> Corrected comments.
>
> Changes in v3:
> Corrected a typo when assigning AMD (Xilinx) vsec id macro
> and condition check.
>
> Changes in v2:
> Reverted the devmem_phys_off type to u64.
> Renamed the function appropriately to suit the
> functionality for setting the LL & data region offsets.
>
> Changes in v1:
> Removed the pci device id from pci_ids.h file.
> Added the vendor id macro as per the suggested method.
> Changed the type of the newly added devmem_phys_off variable.
> Added to logic to assign offsets for LL and data region blocks
> in case more number of channels are enabled than given in
> amd_mdb_data struct.
> ---
>  drivers/dma/dw-edma/dw-edma-pcie.c | 190 ++++++++++++++++++++++++++---
>  1 file changed, 176 insertions(+), 14 deletions(-)
>
...
>
> +static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> +					     struct dw_edma_pcie_data *pdata)
> +{
> +	u32 val, map;
> +	u16 vsec;
> +	u64 off;
> +
> +	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
> +
> +	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> +					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
> +	if (!vsec)
> +		return;
> +
> +	pci_read_config_dword(pdev, vsec + PCI_VNDR_HEADER, &val);
> +	if (PCI_VNDR_HEADER_REV(val) != 0x00 ||
> +	    PCI_VNDR_HEADER_LEN(val) != 0x18)
> +		return;
> +
> +	pci_dbg(pdev, "Detected Xilinx PCIe Vendor-Specific Extended Capability DMA\n");
> +	pci_read_config_dword(pdev, vsec + 0x8, &val);
> +	map = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_MAP, val);
> +	if (map != EDMA_MF_HDMA_NATIVE)
> +		return;
> +
> +	pdata->mf = map;
> +	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_BAR, val);
> +
> +	pci_read_config_dword(pdev, vsec + 0xc, &val);
> +	pdata->wr_ch_cnt = min_t(u16, pdata->wr_ch_cnt,
> +				 FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
> +	pdata->rd_ch_cnt = min_t(u16, pdata->rd_ch_cnt,
> +				 FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));

In https://lore.kernel.org/all/20251119224140.8616-1-david.laight.linux@gmail.com/

suggest direct use min()

Frank
> +
> +	pci_read_config_dword(pdev, vsec + 0x14, &val);
> +	off = val;
> +	pci_read_config_dword(pdev, vsec + 0x10, &val);
> +	off <<= 32;
> +	off |= val;
> +	pdata->rg.off = off;
> +
> +	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> +					DW_PCIE_XILINX_MDB_VSEC_ID);
> +	if (!vsec)
> +		return;
> +
> +	pci_read_config_dword(pdev,
> +			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
> +			      &val);
> +	off = val;
> +	pci_read_config_dword(pdev,
> +			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
> +			      &val);
> +	off <<= 32;
> +	off |= val;
> +	pdata->devmem_phys_off = off;
> +}
> +
>  static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  			      const struct pci_device_id *pid)
>  {
> @@ -184,7 +322,29 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  	 * Tries to find if exists a PCIe Vendor-Specific Extended Capability
>  	 * for the DMA, if one exists, then reconfigures it.
>  	 */
> -	dw_edma_pcie_get_vsec_dma_data(pdev, vsec_data);
> +	dw_edma_pcie_get_synopsys_dma_data(pdev, vsec_data);
> +
> +	if (pdev->vendor == PCI_VENDOR_ID_XILINX) {
> +		dw_edma_pcie_get_xilinx_dma_data(pdev, vsec_data);
> +
> +		/*
> +		 * There is no valid address found for the LL memory
> +		 * space on the device side.
> +		 */
> +		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_MDB_INVALID_ADDR)
> +			return -ENOMEM;
> +
> +		/*
> +		 * Configure the channel LL and data blocks if number of
> +		 * channels enabled in VSEC capability are more than the
> +		 * channels configured in xilinx_mdb_data.
> +		 */
> +		dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
> +					       DW_PCIE_XILINX_MDB_LL_OFF_GAP,
> +					       DW_PCIE_XILINX_MDB_LL_SIZE,
> +					       DW_PCIE_XILINX_MDB_DT_OFF_GAP,
> +					       DW_PCIE_XILINX_MDB_DT_SIZE);
> +	}
>
>  	/* Mapping PCI BAR regions */
>  	mask = BIT(vsec_data->rg.bar);
> @@ -367,6 +527,8 @@ static void dw_edma_pcie_remove(struct pci_dev *pdev)
>
>  static const struct pci_device_id dw_edma_pcie_id_table[] = {
>  	{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
> +	{ PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
> +	  (kernel_ulong_t)&xilinx_mdb_data },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);
> --
> 2.43.0
>

RE: [PATCH RESEND v10 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Tuesday, February 17, 2026 12:58 AM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 1/2] dmaengine: dw-edma: Add AMD MDB
> Endpoint Support
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Mon, Feb 16, 2026 at 04:25:45PM +0530, Devendra K Verma wrote:
> > AMD MDB PCIe endpoint support. For AMD specific support added the
> > following
> >   - AMD supported PCIe Device IDs and Vendor ID (Xilinx).
> >   - AMD MDB specific driver data
> >   - AMD MDB specific VSEC capability to retrieve the device DDR
> >     base address.
> >
> > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > ---
> > Changes in v10:
> > For Xilinx VSEC function kept only HDMA map format as Xilinx only
> > supports HDMA.
> >
> > Changes in v9:
> > Moved Xilinx specific VSEC capability functions under the vendor ID
> > condition.
> >
> > Changes in v8:
> > Changed the contant names to includer product vendor.
> > Moved the vendor specific code to vendor specific functions.
> >
> > Changes in v7:
> > Introduced vendor specific functions to retrieve the vsec data.
> >
> > Changes in v6:
> > Included "sizes.h" header and used the appropriate definitions instead
> > of constants.
> >
> > Changes in v5:
> > Added the definitions for Xilinx specific VSEC header id, revision,
> > and register offsets.
> > Corrected the error type when no physical offset found for device side
> > memory.
> > Corrected the order of variables.
> >
> > Changes in v4:
> > Configured 8 read and 8 write channels for Xilinx vendor Added checks
> > to validate vendor ID for vendor specific vsec id.
> > Added Xilinx specific vendor id for vsec specific to Xilinx Added the
> > LL and data region offsets, size as input params to function
> > dw_edma_set_chan_region_offset().
> > Moved the LL and data region offsets assignment to function for Xilinx
> > specific case.
> > Corrected comments.
> >
> > Changes in v3:
> > Corrected a typo when assigning AMD (Xilinx) vsec id macro and
> > condition check.
> >
> > Changes in v2:
> > Reverted the devmem_phys_off type to u64.
> > Renamed the function appropriately to suit the functionality for
> > setting the LL & data region offsets.
> >
> > Changes in v1:
> > Removed the pci device id from pci_ids.h file.
> > Added the vendor id macro as per the suggested method.
> > Changed the type of the newly added devmem_phys_off variable.
> > Added to logic to assign offsets for LL and data region blocks in case
> > more number of channels are enabled than given in amd_mdb_data struct.
> > ---
> >  drivers/dma/dw-edma/dw-edma-pcie.c | 190
> > ++++++++++++++++++++++++++---
> >  1 file changed, 176 insertions(+), 14 deletions(-)
> >
> ...
> >
> > +static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > +                                          struct dw_edma_pcie_data
> > +*pdata) {
> > +     u32 val, map;
> > +     u16 vsec;
> > +     u64 off;
> > +
> > +     pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
> > +
> > +     vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> > +                                     DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
> > +     if (!vsec)
> > +             return;
> > +
> > +     pci_read_config_dword(pdev, vsec + PCI_VNDR_HEADER, &val);
> > +     if (PCI_VNDR_HEADER_REV(val) != 0x00 ||
> > +         PCI_VNDR_HEADER_LEN(val) != 0x18)
> > +             return;
> > +
> > +     pci_dbg(pdev, "Detected Xilinx PCIe Vendor-Specific Extended Capability
> DMA\n");
> > +     pci_read_config_dword(pdev, vsec + 0x8, &val);
> > +     map = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_MAP, val);
> > +     if (map != EDMA_MF_HDMA_NATIVE)
> > +             return;
> > +
> > +     pdata->mf = map;
> > +     pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_BAR,
> val);
> > +
> > +     pci_read_config_dword(pdev, vsec + 0xc, &val);
> > +     pdata->wr_ch_cnt = min_t(u16, pdata->wr_ch_cnt,
> > +                              FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH,
> val));
> > +     pdata->rd_ch_cnt = min_t(u16, pdata->rd_ch_cnt,
> > +
> > + FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
>
> In https://lore.kernel.org/all/20251119224140.8616-1-
> david.laight.linux@gmail.com/
>
> suggest direct use min()
>
> Frank

Thank you Frank, this will be updated in the next revision.
- Devendra

> > +
> > +     pci_read_config_dword(pdev, vsec + 0x14, &val);
> > +     off = val;
> > +     pci_read_config_dword(pdev, vsec + 0x10, &val);
> > +     off <<= 32;
> > +     off |= val;
> > +     pdata->rg.off = off;
> > +
> > +     vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> > +                                     DW_PCIE_XILINX_MDB_VSEC_ID);
> > +     if (!vsec)
> > +             return;
> > +
> > +     pci_read_config_dword(pdev,
> > +                           vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
> > +                           &val);
> > +     off = val;
> > +     pci_read_config_dword(pdev,
> > +                           vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
> > +                           &val);
> > +     off <<= 32;
> > +     off |= val;
> > +     pdata->devmem_phys_off = off;
> > +}
> > +
> >  static int dw_edma_pcie_probe(struct pci_dev *pdev,
> >                             const struct pci_device_id *pid)  { @@
> > -184,7 +322,29 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> >        * Tries to find if exists a PCIe Vendor-Specific Extended Capability
> >        * for the DMA, if one exists, then reconfigures it.
> >        */
> > -     dw_edma_pcie_get_vsec_dma_data(pdev, vsec_data);
> > +     dw_edma_pcie_get_synopsys_dma_data(pdev, vsec_data);
> > +
> > +     if (pdev->vendor == PCI_VENDOR_ID_XILINX) {
> > +             dw_edma_pcie_get_xilinx_dma_data(pdev, vsec_data);
> > +
> > +             /*
> > +              * There is no valid address found for the LL memory
> > +              * space on the device side.
> > +              */
> > +             if (vsec_data->devmem_phys_off ==
> DW_PCIE_XILINX_MDB_INVALID_ADDR)
> > +                     return -ENOMEM;
> > +
> > +             /*
> > +              * Configure the channel LL and data blocks if number of
> > +              * channels enabled in VSEC capability are more than the
> > +              * channels configured in xilinx_mdb_data.
> > +              */
> > +             dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
> > +                                            DW_PCIE_XILINX_MDB_LL_OFF_GAP,
> > +                                            DW_PCIE_XILINX_MDB_LL_SIZE,
> > +                                            DW_PCIE_XILINX_MDB_DT_OFF_GAP,
> > +                                            DW_PCIE_XILINX_MDB_DT_SIZE);
> > +     }
> >
> >       /* Mapping PCI BAR regions */
> >       mask = BIT(vsec_data->rg.bar);
> > @@ -367,6 +527,8 @@ static void dw_edma_pcie_remove(struct pci_dev
> > *pdev)
> >
> >  static const struct pci_device_id dw_edma_pcie_id_table[] = {
> >       { PCI_DEVICE_DATA(SYNOPSYS, EDDA, &snps_edda_data) },
> > +     { PCI_VDEVICE(XILINX, PCI_DEVICE_ID_XILINX_B054),
> > +       (kernel_ulong_t)&xilinx_mdb_data },
> >       { }
> >  };
> >  MODULE_DEVICE_TABLE(pci, dw_edma_pcie_id_table);
> > --
> > 2.43.0
> >

[PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Devendra K Verma]

AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
The current code does not have the mechanisms to enable the
DMA transactions using the non-LL mode. The following two cases
are added with this patch:
- For the AMD (Xilinx) only, when a valid physical base address of
  the device side DDR is not configured, then the IP can still be
  used in non-LL mode. For all the channels DMA transactions will
  be using the non-LL mode only. This, the default non-LL mode,
  is not applicable for Synopsys IP with the current code addition.

- If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
  and if user wants to use non-LL mode then user can do so via
  configuring the peripheral_config param of dma_slave_config.

Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
---
Changes in v10
  Added the peripheral_config check only for HDMA IP in
  dw_edma_device_config().
  Replaced the loop with single entry retrieval for non-LL
  mode.
  Addressed review comments and handled the burst allocation
  by defining 'bursts_max' as per suggestions.

Changes in v9
  Fixed compilation errors related to macro name mismatch.

Changes in v8
  Cosmetic change related to comment and code.

Changes in v7
  No change

Changes in v6
  Gave definition to bits used for channel configuration.
  Removed the comment related to doorbell.

Changes in v5
  Variable name 'nollp' changed to 'non_ll'.
  In the dw_edma_device_config() WARN_ON replaced with dev_err().
  Comments follow the 80-column guideline.

Changes in v4
  No change

Changes in v3
  No change

Changes in v2
  Reverted the function return type to u64 for
  dw_edma_get_phys_addr().

Changes in v1
  Changed the function return type for dw_edma_get_phys_addr().
  Corrected the typo raised in review.
---
 drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
 drivers/dma/dw-edma/dw-edma-core.h    |  1 +
 drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
 drivers/dma/dw-edma/dw-hdma-v0-core.c | 65 ++++++++++++++++++++++++++-
 drivers/dma/dw-edma/dw-hdma-v0-regs.h |  1 +
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index b43255f914f3..ef3d79a9f88d 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -223,6 +223,31 @@ static int dw_edma_device_config(struct dma_chan *dchan,
 				 struct dma_slave_config *config)
 {
 	struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
+	int non_ll = 0;
+
+	chan->non_ll = false;
+	if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
+		if (config->peripheral_config &&
+		    config->peripheral_size != sizeof(int)) {
+			dev_err(dchan->device->dev,
+				"config param peripheral size mismatch\n");
+			return -EINVAL;
+		}
+
+		/*
+		 * When there is no valid LLP base address available then the
+		 * default DMA ops will use the non-LL mode.
+		 *
+		 * Cases where LL mode is enabled and client wants to use the
+		 * non-LL mode then also client can do so via providing the
+		 * peripheral_config param.
+		 */
+		if (config->peripheral_config)
+			non_ll = *(int *)config->peripheral_config;
+
+		if (chan->dw->chip->non_ll || (!chan->dw->chip->non_ll && non_ll))
+			chan->non_ll = true;
+	}
 
 	memcpy(&chan->config, config, sizeof(*config));
 	chan->configured = true;
@@ -358,6 +383,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
 	struct dw_edma_desc *desc;
 	u64 src_addr, dst_addr;
 	size_t fsz = 0;
+	u32 bursts_max;
 	u32 cnt = 0;
 	int i;
 
@@ -415,6 +441,13 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
 		return NULL;
 	}
 
+	/*
+	 * For non-LL mode, only a single burst can be handled
+	 * in a single chunk unlike LL mode where multiple bursts
+	 * can be configured in a single chunk.
+	 */
+	bursts_max = chan->non_ll ? 1 : chan->ll_max;
+
 	desc = dw_edma_alloc_desc(chan);
 	if (unlikely(!desc))
 		goto err_alloc;
@@ -450,7 +483,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
 		if (xfer->type == EDMA_XFER_SCATTER_GATHER && !sg)
 			break;
 
-		if (chunk->bursts_alloc == chan->ll_max) {
+		if (chunk->bursts_alloc == bursts_max) {
 			chunk = dw_edma_alloc_chunk(desc);
 			if (unlikely(!chunk))
 				goto err_alloc;
diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h
index 71894b9e0b15..c8e3d196a549 100644
--- a/drivers/dma/dw-edma/dw-edma-core.h
+++ b/drivers/dma/dw-edma/dw-edma-core.h
@@ -86,6 +86,7 @@ struct dw_edma_chan {
 	u8				configured;
 
 	struct dma_slave_config		config;
+	bool				non_ll;
 };
 
 struct dw_edma_irq {
diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index 3aefc48f8e0a..94621b0f87df 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -295,6 +295,15 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
 	pdata->devmem_phys_off = off;
 }
 
+static u64 dw_edma_get_phys_addr(struct pci_dev *pdev,
+				 struct dw_edma_pcie_data *pdata,
+				 enum pci_barno bar)
+{
+	if (pdev->vendor == PCI_VENDOR_ID_XILINX)
+		return pdata->devmem_phys_off;
+	return pci_bus_address(pdev, bar);
+}
+
 static int dw_edma_pcie_probe(struct pci_dev *pdev,
 			      const struct pci_device_id *pid)
 {
@@ -304,6 +313,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 	struct dw_edma_chip *chip;
 	int err, nr_irqs;
 	int i, mask;
+	bool non_ll = false;
 
 	vsec_data = kmalloc(sizeof(*vsec_data), GFP_KERNEL);
 	if (!vsec_data)
@@ -329,21 +339,24 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 
 		/*
 		 * There is no valid address found for the LL memory
-		 * space on the device side.
+		 * space on the device side. In the absence of LL base
+		 * address use the non-LL mode or simple mode supported by
+		 * the HDMA IP.
 		 */
 		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_MDB_INVALID_ADDR)
-			return -ENOMEM;
+			non_ll = true;
 
 		/*
 		 * Configure the channel LL and data blocks if number of
 		 * channels enabled in VSEC capability are more than the
 		 * channels configured in xilinx_mdb_data.
 		 */
-		dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
-					       DW_PCIE_XILINX_MDB_LL_OFF_GAP,
-					       DW_PCIE_XILINX_MDB_LL_SIZE,
-					       DW_PCIE_XILINX_MDB_DT_OFF_GAP,
-					       DW_PCIE_XILINX_MDB_DT_SIZE);
+		if (!non_ll)
+			dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
+						       DW_PCIE_XILINX_MDB_LL_OFF_GAP,
+						       DW_PCIE_XILINX_MDB_LL_SIZE,
+						       DW_PCIE_XILINX_MDB_DT_OFF_GAP,
+						       DW_PCIE_XILINX_MDB_DT_SIZE);
 	}
 
 	/* Mapping PCI BAR regions */
@@ -391,6 +404,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 	chip->mf = vsec_data->mf;
 	chip->nr_irqs = nr_irqs;
 	chip->ops = &dw_edma_pcie_plat_ops;
+	chip->non_ll = non_ll;
 
 	chip->ll_wr_cnt = vsec_data->wr_ch_cnt;
 	chip->ll_rd_cnt = vsec_data->rd_ch_cnt;
@@ -399,7 +413,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 	if (!chip->reg_base)
 		return -ENOMEM;
 
-	for (i = 0; i < chip->ll_wr_cnt; i++) {
+	for (i = 0; i < chip->ll_wr_cnt && !non_ll; i++) {
 		struct dw_edma_region *ll_region = &chip->ll_region_wr[i];
 		struct dw_edma_region *dt_region = &chip->dt_region_wr[i];
 		struct dw_edma_block *ll_block = &vsec_data->ll_wr[i];
@@ -410,7 +424,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 			return -ENOMEM;
 
 		ll_region->vaddr.io += ll_block->off;
-		ll_region->paddr = pci_bus_address(pdev, ll_block->bar);
+		ll_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
+							 ll_block->bar);
 		ll_region->paddr += ll_block->off;
 		ll_region->sz = ll_block->sz;
 
@@ -419,12 +434,13 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 			return -ENOMEM;
 
 		dt_region->vaddr.io += dt_block->off;
-		dt_region->paddr = pci_bus_address(pdev, dt_block->bar);
+		dt_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
+							 dt_block->bar);
 		dt_region->paddr += dt_block->off;
 		dt_region->sz = dt_block->sz;
 	}
 
-	for (i = 0; i < chip->ll_rd_cnt; i++) {
+	for (i = 0; i < chip->ll_rd_cnt && !non_ll; i++) {
 		struct dw_edma_region *ll_region = &chip->ll_region_rd[i];
 		struct dw_edma_region *dt_region = &chip->dt_region_rd[i];
 		struct dw_edma_block *ll_block = &vsec_data->ll_rd[i];
@@ -435,7 +451,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 			return -ENOMEM;
 
 		ll_region->vaddr.io += ll_block->off;
-		ll_region->paddr = pci_bus_address(pdev, ll_block->bar);
+		ll_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
+							 ll_block->bar);
 		ll_region->paddr += ll_block->off;
 		ll_region->sz = ll_block->sz;
 
@@ -444,7 +461,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 			return -ENOMEM;
 
 		dt_region->vaddr.io += dt_block->off;
-		dt_region->paddr = pci_bus_address(pdev, dt_block->bar);
+		dt_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
+							 dt_block->bar);
 		dt_region->paddr += dt_block->off;
 		dt_region->sz = dt_block->sz;
 	}
diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
index e3f8db4fe909..a1b04fec6310 100644
--- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
+++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
@@ -225,7 +225,7 @@ static void dw_hdma_v0_sync_ll_data(struct dw_edma_chunk *chunk)
 		readl(chunk->ll_region.vaddr.io);
 }
 
-static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
+static void dw_hdma_v0_core_ll_start(struct dw_edma_chunk *chunk, bool first)
 {
 	struct dw_edma_chan *chan = chunk->chan;
 	struct dw_edma *dw = chan->dw;
@@ -263,6 +263,69 @@ static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
 	SET_CH_32(dw, chan->dir, chan->id, doorbell, HDMA_V0_DOORBELL_START);
 }
 
+static void dw_hdma_v0_core_non_ll_start(struct dw_edma_chunk *chunk)
+{
+	struct dw_edma_chan *chan = chunk->chan;
+	struct dw_edma *dw = chan->dw;
+	struct dw_edma_burst *child;
+	u32 val;
+
+	child = list_first_entry_or_null(&chunk->burst->list,
+					 struct dw_edma_burst, list);
+	if (!child)
+		return;
+
+	SET_CH_32(dw, chan->dir, chan->id, ch_en, HDMA_V0_CH_EN);
+
+	/* Source address */
+	SET_CH_32(dw, chan->dir, chan->id, sar.lsb,
+		  lower_32_bits(child->sar));
+	SET_CH_32(dw, chan->dir, chan->id, sar.msb,
+		  upper_32_bits(child->sar));
+
+	/* Destination address */
+	SET_CH_32(dw, chan->dir, chan->id, dar.lsb,
+		  lower_32_bits(child->dar));
+	SET_CH_32(dw, chan->dir, chan->id, dar.msb,
+		  upper_32_bits(child->dar));
+
+	/* Transfer size */
+	SET_CH_32(dw, chan->dir, chan->id, transfer_size, child->sz);
+
+	/* Interrupt setup */
+	val = GET_CH_32(dw, chan->dir, chan->id, int_setup) |
+			HDMA_V0_STOP_INT_MASK |
+			HDMA_V0_ABORT_INT_MASK |
+			HDMA_V0_LOCAL_STOP_INT_EN |
+			HDMA_V0_LOCAL_ABORT_INT_EN;
+
+	if (!(dw->chip->flags & DW_EDMA_CHIP_LOCAL)) {
+		val |= HDMA_V0_REMOTE_STOP_INT_EN |
+		       HDMA_V0_REMOTE_ABORT_INT_EN;
+	}
+
+	SET_CH_32(dw, chan->dir, chan->id, int_setup, val);
+
+	/* Channel control setup */
+	val = GET_CH_32(dw, chan->dir, chan->id, control1);
+	val &= ~HDMA_V0_LINKLIST_EN;
+	SET_CH_32(dw, chan->dir, chan->id, control1, val);
+
+	SET_CH_32(dw, chan->dir, chan->id, doorbell,
+		  HDMA_V0_DOORBELL_START);
+	
+}
+
+static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
+{
+	struct dw_edma_chan *chan = chunk->chan;
+
+	if (chan->non_ll)
+		dw_hdma_v0_core_non_ll_start(chunk);
+	else
+		dw_hdma_v0_core_ll_start(chunk, first);
+}
+
 static void dw_hdma_v0_core_ch_config(struct dw_edma_chan *chan)
 {
 	struct dw_edma *dw = chan->dw;
diff --git a/drivers/dma/dw-edma/dw-hdma-v0-regs.h b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
index eab5fd7177e5..7759ba9b4850 100644
--- a/drivers/dma/dw-edma/dw-hdma-v0-regs.h
+++ b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
@@ -12,6 +12,7 @@
 #include <linux/dmaengine.h>
 
 #define HDMA_V0_MAX_NR_CH			8
+#define HDMA_V0_CH_EN				BIT(0)
 #define HDMA_V0_LOCAL_ABORT_INT_EN		BIT(6)
 #define HDMA_V0_REMOTE_ABORT_INT_EN		BIT(5)
 #define HDMA_V0_LOCAL_STOP_INT_EN		BIT(4)
diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
index 3080747689f6..78ce31b049ae 100644
--- a/include/linux/dma/edma.h
+++ b/include/linux/dma/edma.h
@@ -99,6 +99,7 @@ struct dw_edma_chip {
 	enum dw_edma_map_format	mf;
 
 	struct dw_edma		*dw;
+	bool			non_ll;
 };
 
 /* Export to the platform drivers */
-- 
2.43.0

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma wrote:
> AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> The current code does not have the mechanisms to enable the
> DMA transactions using the non-LL mode. The following two cases
> are added with this patch:
> - For the AMD (Xilinx) only, when a valid physical base address of
>   the device side DDR is not configured, then the IP can still be
>   used in non-LL mode. For all the channels DMA transactions will
>   be using the non-LL mode only. This, the default non-LL mode,
>   is not applicable for Synopsys IP with the current code addition.
>
> - If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
>   and if user wants to use non-LL mode then user can do so via
>   configuring the peripheral_config param of dma_slave_config.
>
> Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> ---
> Changes in v10
>   Added the peripheral_config check only for HDMA IP in
>   dw_edma_device_config().
>   Replaced the loop with single entry retrieval for non-LL
>   mode.
>   Addressed review comments and handled the burst allocation
>   by defining 'bursts_max' as per suggestions.
>
> Changes in v9
>   Fixed compilation errors related to macro name mismatch.
>
> Changes in v8
>   Cosmetic change related to comment and code.
>
> Changes in v7
>   No change
>
> Changes in v6
>   Gave definition to bits used for channel configuration.
>   Removed the comment related to doorbell.
>
> Changes in v5
>   Variable name 'nollp' changed to 'non_ll'.
>   In the dw_edma_device_config() WARN_ON replaced with dev_err().
>   Comments follow the 80-column guideline.
>
> Changes in v4
>   No change
>
> Changes in v3
>   No change
>
> Changes in v2
>   Reverted the function return type to u64 for
>   dw_edma_get_phys_addr().
>
> Changes in v1
>   Changed the function return type for dw_edma_get_phys_addr().
>   Corrected the typo raised in review.
> ---
>  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
>  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
>  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
>  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65 ++++++++++++++++++++++++++-
>  drivers/dma/dw-edma/dw-hdma-v0-regs.h |  1 +
>  include/linux/dma/edma.h              |  1 +
>  6 files changed, 132 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index b43255f914f3..ef3d79a9f88d 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
> @@ -223,6 +223,31 @@ static int dw_edma_device_config(struct dma_chan *dchan,
>  				 struct dma_slave_config *config)
>  {
>  	struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> +	int non_ll = 0;
> +
> +	chan->non_ll = false;
> +	if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {

Need handle EMDA case. if mf is EDMA, need return error when
config->peripheral_config is not NULL. Or remove above check to make
code work for both EDMA or HDMA.

> +		if (config->peripheral_config &&
> +		    config->peripheral_size != sizeof(int)) {
> +			dev_err(dchan->device->dev,
> +				"config param peripheral size mismatch\n");
> +			return -EINVAL;
> +		}
> +
> +		/*
> +		 * When there is no valid LLP base address available then the
> +		 * default DMA ops will use the non-LL mode.
> +		 *
> +		 * Cases where LL mode is enabled and client wants to use the
> +		 * non-LL mode then also client can do so via providing the
> +		 * peripheral_config param.
> +		 */
> +		if (config->peripheral_config)
> +			non_ll = *(int *)config->peripheral_config;
> +
> +		if (chan->dw->chip->non_ll || (!chan->dw->chip->non_ll && non_ll))

if chan->dw->chip->non_ll is true, It should return error if you set non_ll
false because no LLP base available.

> +			chan->non_ll = true;
> +	}
>
>  	memcpy(&chan->config, config, sizeof(*config));
>  	chan->configured = true;
> @@ -358,6 +383,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
>  	struct dw_edma_desc *desc;
>  	u64 src_addr, dst_addr;
>  	size_t fsz = 0;
> +	u32 bursts_max;
>  	u32 cnt = 0;
>  	int i;
>
> @@ -415,6 +441,13 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
>  		return NULL;
>  	}
>
> +	/*
> +	 * For non-LL mode, only a single burst can be handled
> +	 * in a single chunk unlike LL mode where multiple bursts
> +	 * can be configured in a single chunk.
> +	 */
> +	bursts_max = chan->non_ll ? 1 : chan->ll_max;
> +
>  	desc = dw_edma_alloc_desc(chan);
>  	if (unlikely(!desc))
>  		goto err_alloc;
> @@ -450,7 +483,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
>  		if (xfer->type == EDMA_XFER_SCATTER_GATHER && !sg)
>  			break;
>
> -		if (chunk->bursts_alloc == chan->ll_max) {
> +		if (chunk->bursts_alloc == bursts_max) {
>  			chunk = dw_edma_alloc_chunk(desc);
>  			if (unlikely(!chunk))
>  				goto err_alloc;
> diff --git a/drivers/dma/dw-edma/dw-edma-core.h b/drivers/dma/dw-edma/dw-edma-core.h
> index 71894b9e0b15..c8e3d196a549 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.h
> +++ b/drivers/dma/dw-edma/dw-edma-core.h
> @@ -86,6 +86,7 @@ struct dw_edma_chan {
>  	u8				configured;
>
>  	struct dma_slave_config		config;
> +	bool				non_ll;
>  };
>
>  struct dw_edma_irq {
> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 3aefc48f8e0a..94621b0f87df 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> @@ -295,6 +295,15 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>  	pdata->devmem_phys_off = off;
>  }
>
> +static u64 dw_edma_get_phys_addr(struct pci_dev *pdev,
> +				 struct dw_edma_pcie_data *pdata,
> +				 enum pci_barno bar)
> +{
> +	if (pdev->vendor == PCI_VENDOR_ID_XILINX)
> +		return pdata->devmem_phys_off;
> +	return pci_bus_address(pdev, bar);
> +}
> +
>  static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  			      const struct pci_device_id *pid)
>  {
> @@ -304,6 +313,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  	struct dw_edma_chip *chip;
>  	int err, nr_irqs;
>  	int i, mask;
> +	bool non_ll = false;
>
>  	vsec_data = kmalloc(sizeof(*vsec_data), GFP_KERNEL);
>  	if (!vsec_data)
> @@ -329,21 +339,24 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>
>  		/*
>  		 * There is no valid address found for the LL memory
> -		 * space on the device side.
> +		 * space on the device side. In the absence of LL base
> +		 * address use the non-LL mode or simple mode supported by
> +		 * the HDMA IP.
>  		 */
>  		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_MDB_INVALID_ADDR)
> -			return -ENOMEM;
> +			non_ll = true;
>
>  		/*
>  		 * Configure the channel LL and data blocks if number of
>  		 * channels enabled in VSEC capability are more than the
>  		 * channels configured in xilinx_mdb_data.
>  		 */
> -		dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
> -					       DW_PCIE_XILINX_MDB_LL_OFF_GAP,
> -					       DW_PCIE_XILINX_MDB_LL_SIZE,
> -					       DW_PCIE_XILINX_MDB_DT_OFF_GAP,
> -					       DW_PCIE_XILINX_MDB_DT_SIZE);
> +		if (!non_ll)
> +			dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
> +						       DW_PCIE_XILINX_MDB_LL_OFF_GAP,
> +						       DW_PCIE_XILINX_MDB_LL_SIZE,
> +						       DW_PCIE_XILINX_MDB_DT_OFF_GAP,
> +						       DW_PCIE_XILINX_MDB_DT_SIZE);
>  	}
>
>  	/* Mapping PCI BAR regions */
> @@ -391,6 +404,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  	chip->mf = vsec_data->mf;
>  	chip->nr_irqs = nr_irqs;
>  	chip->ops = &dw_edma_pcie_plat_ops;
> +	chip->non_ll = non_ll;
>
>  	chip->ll_wr_cnt = vsec_data->wr_ch_cnt;
>  	chip->ll_rd_cnt = vsec_data->rd_ch_cnt;
> @@ -399,7 +413,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  	if (!chip->reg_base)
>  		return -ENOMEM;
>
> -	for (i = 0; i < chip->ll_wr_cnt; i++) {
> +	for (i = 0; i < chip->ll_wr_cnt && !non_ll; i++) {
>  		struct dw_edma_region *ll_region = &chip->ll_region_wr[i];
>  		struct dw_edma_region *dt_region = &chip->dt_region_wr[i];
>  		struct dw_edma_block *ll_block = &vsec_data->ll_wr[i];
> @@ -410,7 +424,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  			return -ENOMEM;
>
>  		ll_region->vaddr.io += ll_block->off;
> -		ll_region->paddr = pci_bus_address(pdev, ll_block->bar);
> +		ll_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> +							 ll_block->bar);
>  		ll_region->paddr += ll_block->off;
>  		ll_region->sz = ll_block->sz;
>
> @@ -419,12 +434,13 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  			return -ENOMEM;
>
>  		dt_region->vaddr.io += dt_block->off;
> -		dt_region->paddr = pci_bus_address(pdev, dt_block->bar);
> +		dt_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> +							 dt_block->bar);
>  		dt_region->paddr += dt_block->off;
>  		dt_region->sz = dt_block->sz;
>  	}
>
> -	for (i = 0; i < chip->ll_rd_cnt; i++) {
> +	for (i = 0; i < chip->ll_rd_cnt && !non_ll; i++) {
>  		struct dw_edma_region *ll_region = &chip->ll_region_rd[i];
>  		struct dw_edma_region *dt_region = &chip->dt_region_rd[i];
>  		struct dw_edma_block *ll_block = &vsec_data->ll_rd[i];
> @@ -435,7 +451,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  			return -ENOMEM;
>
>  		ll_region->vaddr.io += ll_block->off;
> -		ll_region->paddr = pci_bus_address(pdev, ll_block->bar);
> +		ll_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> +							 ll_block->bar);
>  		ll_region->paddr += ll_block->off;
>  		ll_region->sz = ll_block->sz;
>
> @@ -444,7 +461,8 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  			return -ENOMEM;
>
>  		dt_region->vaddr.io += dt_block->off;
> -		dt_region->paddr = pci_bus_address(pdev, dt_block->bar);
> +		dt_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> +							 dt_block->bar);
>  		dt_region->paddr += dt_block->off;
>  		dt_region->sz = dt_block->sz;
>  	}
> diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> index e3f8db4fe909..a1b04fec6310 100644
> --- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> +++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> @@ -225,7 +225,7 @@ static void dw_hdma_v0_sync_ll_data(struct dw_edma_chunk *chunk)
>  		readl(chunk->ll_region.vaddr.io);
>  }
>
> -static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
> +static void dw_hdma_v0_core_ll_start(struct dw_edma_chunk *chunk, bool first)
>  {
>  	struct dw_edma_chan *chan = chunk->chan;
>  	struct dw_edma *dw = chan->dw;
> @@ -263,6 +263,69 @@ static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
>  	SET_CH_32(dw, chan->dir, chan->id, doorbell, HDMA_V0_DOORBELL_START);
>  }
>
> +static void dw_hdma_v0_core_non_ll_start(struct dw_edma_chunk *chunk)
> +{
> +	struct dw_edma_chan *chan = chunk->chan;
> +	struct dw_edma *dw = chan->dw;
> +	struct dw_edma_burst *child;
> +	u32 val;
> +
> +	child = list_first_entry_or_null(&chunk->burst->list,
> +					 struct dw_edma_burst, list);
> +	if (!child)
> +		return;
> +
> +	SET_CH_32(dw, chan->dir, chan->id, ch_en, HDMA_V0_CH_EN);
> +
> +	/* Source address */
> +	SET_CH_32(dw, chan->dir, chan->id, sar.lsb,
> +		  lower_32_bits(child->sar));
> +	SET_CH_32(dw, chan->dir, chan->id, sar.msb,
> +		  upper_32_bits(child->sar));
> +
> +	/* Destination address */
> +	SET_CH_32(dw, chan->dir, chan->id, dar.lsb,
> +		  lower_32_bits(child->dar));
> +	SET_CH_32(dw, chan->dir, chan->id, dar.msb,
> +		  upper_32_bits(child->dar));
> +
> +	/* Transfer size */
> +	SET_CH_32(dw, chan->dir, chan->id, transfer_size, child->sz);
> +
> +	/* Interrupt setup */
> +	val = GET_CH_32(dw, chan->dir, chan->id, int_setup) |
> +			HDMA_V0_STOP_INT_MASK |
> +			HDMA_V0_ABORT_INT_MASK |
> +			HDMA_V0_LOCAL_STOP_INT_EN |
> +			HDMA_V0_LOCAL_ABORT_INT_EN;
> +
> +	if (!(dw->chip->flags & DW_EDMA_CHIP_LOCAL)) {
> +		val |= HDMA_V0_REMOTE_STOP_INT_EN |
> +		       HDMA_V0_REMOTE_ABORT_INT_EN;
> +	}
> +
> +	SET_CH_32(dw, chan->dir, chan->id, int_setup, val);
> +
> +	/* Channel control setup */
> +	val = GET_CH_32(dw, chan->dir, chan->id, control1);
> +	val &= ~HDMA_V0_LINKLIST_EN;
> +	SET_CH_32(dw, chan->dir, chan->id, control1, val);
> +
> +	SET_CH_32(dw, chan->dir, chan->id, doorbell,
> +		  HDMA_V0_DOORBELL_START);
> +
> +}
> +
> +static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool first)
> +{
> +	struct dw_edma_chan *chan = chunk->chan;
> +
> +	if (chan->non_ll)
> +		dw_hdma_v0_core_non_ll_start(chunk);
> +	else
> +		dw_hdma_v0_core_ll_start(chunk, first);
> +}
> +
>  static void dw_hdma_v0_core_ch_config(struct dw_edma_chan *chan)
>  {
>  	struct dw_edma *dw = chan->dw;
> diff --git a/drivers/dma/dw-edma/dw-hdma-v0-regs.h b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
> index eab5fd7177e5..7759ba9b4850 100644
> --- a/drivers/dma/dw-edma/dw-hdma-v0-regs.h
> +++ b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
> @@ -12,6 +12,7 @@
>  #include <linux/dmaengine.h>
>
>  #define HDMA_V0_MAX_NR_CH			8
> +#define HDMA_V0_CH_EN				BIT(0)
>  #define HDMA_V0_LOCAL_ABORT_INT_EN		BIT(6)
>  #define HDMA_V0_REMOTE_ABORT_INT_EN		BIT(5)
>  #define HDMA_V0_LOCAL_STOP_INT_EN		BIT(4)
> diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
> index 3080747689f6..78ce31b049ae 100644
> --- a/include/linux/dma/edma.h
> +++ b/include/linux/dma/edma.h
> @@ -99,6 +99,7 @@ struct dw_edma_chip {
>  	enum dw_edma_map_format	mf;
>
>  	struct dw_edma		*dw;
> +	bool			non_ll;

Can you check ll_region directly? it should be equal to
(ll_region->sz == 0) ?

Frank
>  };
>
>  /* Export to the platform drivers */
> --
> 2.43.0
>

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Frank

Please check my responses inline.

Regards,
Devendra
> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Tuesday, February 17, 2026 1:16 AM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma wrote:
> > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > The current code does not have the mechanisms to enable the DMA
> > transactions using the non-LL mode. The following two cases are added
> > with this patch:
> > - For the AMD (Xilinx) only, when a valid physical base address of
> >   the device side DDR is not configured, then the IP can still be
> >   used in non-LL mode. For all the channels DMA transactions will
> >   be using the non-LL mode only. This, the default non-LL mode,
> >   is not applicable for Synopsys IP with the current code addition.
> >
> > - If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
> >   and if user wants to use non-LL mode then user can do so via
> >   configuring the peripheral_config param of dma_slave_config.
> >
> > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > ---
> > Changes in v10
> >   Added the peripheral_config check only for HDMA IP in
> >   dw_edma_device_config().
> >   Replaced the loop with single entry retrieval for non-LL
> >   mode.
> >   Addressed review comments and handled the burst allocation
> >   by defining 'bursts_max' as per suggestions.
> >
> > Changes in v9
> >   Fixed compilation errors related to macro name mismatch.
> >
> > Changes in v8
> >   Cosmetic change related to comment and code.
> >
> > Changes in v7
> >   No change
> >
> > Changes in v6
> >   Gave definition to bits used for channel configuration.
> >   Removed the comment related to doorbell.
> >
> > Changes in v5
> >   Variable name 'nollp' changed to 'non_ll'.
> >   In the dw_edma_device_config() WARN_ON replaced with dev_err().
> >   Comments follow the 80-column guideline.
> >
> > Changes in v4
> >   No change
> >
> > Changes in v3
> >   No change
> >
> > Changes in v2
> >   Reverted the function return type to u64 for
> >   dw_edma_get_phys_addr().
> >
> > Changes in v1
> >   Changed the function return type for dw_edma_get_phys_addr().
> >   Corrected the typo raised in review.
> > ---
> >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
> >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-hdma-v0-
> regs.h |  1 +
> >  include/linux/dma/edma.h              |  1 +
> >  6 files changed, 132 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > b/drivers/dma/dw-edma/dw-edma-core.c
> > index b43255f914f3..ef3d79a9f88d 100644
> > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > @@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
> dma_chan *dchan,
> >                                struct dma_slave_config *config)  {
> >       struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> > +     int non_ll = 0;
> > +
> > +     chan->non_ll = false;
> > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
>
> Need handle EMDA case. if mf is EDMA, need return error when
> config->peripheral_config is not NULL. Or remove above check to make
> code work for both EDMA or HDMA.
>

For the case of EDMA, the behavior is unchanged.
Even if the config->peripheral_config param is set then it would be simply ignored.
This is retention of the previous behavior. This is done because device_slave_config
has other params which affect the behavior of the DMA transactions, we do not check
all those params and return any error. The error is returned only in the cases where
particular parameter from dma_slave_config is used and if the parameter is not as expected
or in the expected form. The parameter used from dma_slave_config for the particular
IP type need to be known first then it can be checked for its correctness. This is behavior
for the peripheral_config which is used for HDMA and thus error checked.

> > +             if (config->peripheral_config &&
> > +                 config->peripheral_size != sizeof(int)) {
> > +                     dev_err(dchan->device->dev,
> > +                             "config param peripheral size mismatch\n");
> > +                     return -EINVAL;
> > +             }
> > +
> > +             /*
> > +              * When there is no valid LLP base address available then the
> > +              * default DMA ops will use the non-LL mode.
> > +              *
> > +              * Cases where LL mode is enabled and client wants to use the
> > +              * non-LL mode then also client can do so via providing the
> > +              * peripheral_config param.
> > +              */
> > +             if (config->peripheral_config)
> > +                     non_ll = *(int *)config->peripheral_config;
> > +
> > +             if (chan->dw->chip->non_ll || (!chan->dw->chip->non_ll
> > + && non_ll))
>
> if chan->dw->chip->non_ll is true, It should return error if you set non_ll false
> because no LLP base available.
>

In case the 'chan->dw->chip->non_ll' is true, then the default mode becomes
non-LL for HDMA ONLY. There is no option to the user to configure the LL mode
by giving 'non_ll = false' as part of the config->peripheral_config.
The configuration of default non-LL mode depends on how the IP is programmed
by the user. The user is aware of the IP configuration. The check for non-LL option
provided by the user is useful when LL-mode is default. That is why the value of
non_ll == false is not even evaluated.

> > +                     chan->non_ll = true;
> > +     }
> >
> >       memcpy(&chan->config, config, sizeof(*config));
> >       chan->configured = true;
> > @@ -358,6 +383,7 @@ dw_edma_device_transfer(struct
> dw_edma_transfer *xfer)
> >       struct dw_edma_desc *desc;
> >       u64 src_addr, dst_addr;
> >       size_t fsz = 0;
> > +     u32 bursts_max;
> >       u32 cnt = 0;
> >       int i;
> >
> > @@ -415,6 +441,13 @@ dw_edma_device_transfer(struct
> dw_edma_transfer *xfer)
> >               return NULL;
> >       }
> >
> > +     /*
> > +      * For non-LL mode, only a single burst can be handled
> > +      * in a single chunk unlike LL mode where multiple bursts
> > +      * can be configured in a single chunk.
> > +      */
> > +     bursts_max = chan->non_ll ? 1 : chan->ll_max;
> > +
> >       desc = dw_edma_alloc_desc(chan);
> >       if (unlikely(!desc))
> >               goto err_alloc;
> > @@ -450,7 +483,7 @@ dw_edma_device_transfer(struct
> dw_edma_transfer *xfer)
> >               if (xfer->type == EDMA_XFER_SCATTER_GATHER && !sg)
> >                       break;
> >
> > -             if (chunk->bursts_alloc == chan->ll_max) {
> > +             if (chunk->bursts_alloc == bursts_max) {
> >                       chunk = dw_edma_alloc_chunk(desc);
> >                       if (unlikely(!chunk))
> >                               goto err_alloc; diff --git
> > a/drivers/dma/dw-edma/dw-edma-core.h
> > b/drivers/dma/dw-edma/dw-edma-core.h
> > index 71894b9e0b15..c8e3d196a549 100644
> > --- a/drivers/dma/dw-edma/dw-edma-core.h
> > +++ b/drivers/dma/dw-edma/dw-edma-core.h
> > @@ -86,6 +86,7 @@ struct dw_edma_chan {
> >       u8                              configured;
> >
> >       struct dma_slave_config         config;
> > +     bool                            non_ll;
> >  };
> >
> >  struct dw_edma_irq {
> > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c
> > b/drivers/dma/dw-edma/dw-edma-pcie.c
> > index 3aefc48f8e0a..94621b0f87df 100644
> > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> > @@ -295,6 +295,15 @@ static void
> dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> >       pdata->devmem_phys_off = off;
> >  }
> >
> > +static u64 dw_edma_get_phys_addr(struct pci_dev *pdev,
> > +                              struct dw_edma_pcie_data *pdata,
> > +                              enum pci_barno bar) {
> > +     if (pdev->vendor == PCI_VENDOR_ID_XILINX)
> > +             return pdata->devmem_phys_off;
> > +     return pci_bus_address(pdev, bar); }
> > +
> >  static int dw_edma_pcie_probe(struct pci_dev *pdev,
> >                             const struct pci_device_id *pid)  { @@
> > -304,6 +313,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> >       struct dw_edma_chip *chip;
> >       int err, nr_irqs;
> >       int i, mask;
> > +     bool non_ll = false;
> >
> >       vsec_data = kmalloc(sizeof(*vsec_data), GFP_KERNEL);
> >       if (!vsec_data)
> > @@ -329,21 +339,24 @@ static int dw_edma_pcie_probe(struct pci_dev
> > *pdev,
> >
> >               /*
> >                * There is no valid address found for the LL memory
> > -              * space on the device side.
> > +              * space on the device side. In the absence of LL base
> > +              * address use the non-LL mode or simple mode supported by
> > +              * the HDMA IP.
> >                */
> >               if (vsec_data->devmem_phys_off ==
> DW_PCIE_XILINX_MDB_INVALID_ADDR)
> > -                     return -ENOMEM;
> > +                     non_ll = true;
> >
> >               /*
> >                * Configure the channel LL and data blocks if number of
> >                * channels enabled in VSEC capability are more than the
> >                * channels configured in xilinx_mdb_data.
> >                */
> > -             dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
> > -                                            DW_PCIE_XILINX_MDB_LL_OFF_GAP,
> > -                                            DW_PCIE_XILINX_MDB_LL_SIZE,
> > -                                            DW_PCIE_XILINX_MDB_DT_OFF_GAP,
> > -                                            DW_PCIE_XILINX_MDB_DT_SIZE);
> > +             if (!non_ll)
> > +                     dw_edma_set_chan_region_offset(vsec_data, BAR_2, 0,
> > +                                                    DW_PCIE_XILINX_MDB_LL_OFF_GAP,
> > +                                                    DW_PCIE_XILINX_MDB_LL_SIZE,
> > +                                                    DW_PCIE_XILINX_MDB_DT_OFF_GAP,
> > +
> > + DW_PCIE_XILINX_MDB_DT_SIZE);
> >       }
> >
> >       /* Mapping PCI BAR regions */
> > @@ -391,6 +404,7 @@ static int dw_edma_pcie_probe(struct pci_dev
> *pdev,
> >       chip->mf = vsec_data->mf;
> >       chip->nr_irqs = nr_irqs;
> >       chip->ops = &dw_edma_pcie_plat_ops;
> > +     chip->non_ll = non_ll;
> >
> >       chip->ll_wr_cnt = vsec_data->wr_ch_cnt;
> >       chip->ll_rd_cnt = vsec_data->rd_ch_cnt; @@ -399,7 +413,7 @@
> > static int dw_edma_pcie_probe(struct pci_dev *pdev,
> >       if (!chip->reg_base)
> >               return -ENOMEM;
> >
> > -     for (i = 0; i < chip->ll_wr_cnt; i++) {
> > +     for (i = 0; i < chip->ll_wr_cnt && !non_ll; i++) {
> >               struct dw_edma_region *ll_region = &chip->ll_region_wr[i];
> >               struct dw_edma_region *dt_region = &chip->dt_region_wr[i];
> >               struct dw_edma_block *ll_block = &vsec_data->ll_wr[i];
> > @@ -410,7 +424,8 @@ static int dw_edma_pcie_probe(struct pci_dev
> *pdev,
> >                       return -ENOMEM;
> >
> >               ll_region->vaddr.io += ll_block->off;
> > -             ll_region->paddr = pci_bus_address(pdev, ll_block->bar);
> > +             ll_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> > +                                                      ll_block->bar);
> >               ll_region->paddr += ll_block->off;
> >               ll_region->sz = ll_block->sz;
> >
> > @@ -419,12 +434,13 @@ static int dw_edma_pcie_probe(struct pci_dev
> *pdev,
> >                       return -ENOMEM;
> >
> >               dt_region->vaddr.io += dt_block->off;
> > -             dt_region->paddr = pci_bus_address(pdev, dt_block->bar);
> > +             dt_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> > +                                                      dt_block->bar);
> >               dt_region->paddr += dt_block->off;
> >               dt_region->sz = dt_block->sz;
> >       }
> >
> > -     for (i = 0; i < chip->ll_rd_cnt; i++) {
> > +     for (i = 0; i < chip->ll_rd_cnt && !non_ll; i++) {
> >               struct dw_edma_region *ll_region = &chip->ll_region_rd[i];
> >               struct dw_edma_region *dt_region = &chip->dt_region_rd[i];
> >               struct dw_edma_block *ll_block = &vsec_data->ll_rd[i];
> > @@ -435,7 +451,8 @@ static int dw_edma_pcie_probe(struct pci_dev
> *pdev,
> >                       return -ENOMEM;
> >
> >               ll_region->vaddr.io += ll_block->off;
> > -             ll_region->paddr = pci_bus_address(pdev, ll_block->bar);
> > +             ll_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> > +                                                      ll_block->bar);
> >               ll_region->paddr += ll_block->off;
> >               ll_region->sz = ll_block->sz;
> >
> > @@ -444,7 +461,8 @@ static int dw_edma_pcie_probe(struct pci_dev
> *pdev,
> >                       return -ENOMEM;
> >
> >               dt_region->vaddr.io += dt_block->off;
> > -             dt_region->paddr = pci_bus_address(pdev, dt_block->bar);
> > +             dt_region->paddr = dw_edma_get_phys_addr(pdev, vsec_data,
> > +                                                      dt_block->bar);
> >               dt_region->paddr += dt_block->off;
> >               dt_region->sz = dt_block->sz;
> >       }
> > diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> > b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> > index e3f8db4fe909..a1b04fec6310 100644
> > --- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
> > +++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
> > @@ -225,7 +225,7 @@ static void dw_hdma_v0_sync_ll_data(struct
> dw_edma_chunk *chunk)
> >               readl(chunk->ll_region.vaddr.io);  }
> >
> > -static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool
> > first)
> > +static void dw_hdma_v0_core_ll_start(struct dw_edma_chunk *chunk,
> > +bool first)
> >  {
> >       struct dw_edma_chan *chan = chunk->chan;
> >       struct dw_edma *dw = chan->dw;
> > @@ -263,6 +263,69 @@ static void dw_hdma_v0_core_start(struct
> dw_edma_chunk *chunk, bool first)
> >       SET_CH_32(dw, chan->dir, chan->id, doorbell,
> > HDMA_V0_DOORBELL_START);  }
> >
> > +static void dw_hdma_v0_core_non_ll_start(struct dw_edma_chunk
> *chunk)
> > +{
> > +     struct dw_edma_chan *chan = chunk->chan;
> > +     struct dw_edma *dw = chan->dw;
> > +     struct dw_edma_burst *child;
> > +     u32 val;
> > +
> > +     child = list_first_entry_or_null(&chunk->burst->list,
> > +                                      struct dw_edma_burst, list);
> > +     if (!child)
> > +             return;
> > +
> > +     SET_CH_32(dw, chan->dir, chan->id, ch_en, HDMA_V0_CH_EN);
> > +
> > +     /* Source address */
> > +     SET_CH_32(dw, chan->dir, chan->id, sar.lsb,
> > +               lower_32_bits(child->sar));
> > +     SET_CH_32(dw, chan->dir, chan->id, sar.msb,
> > +               upper_32_bits(child->sar));
> > +
> > +     /* Destination address */
> > +     SET_CH_32(dw, chan->dir, chan->id, dar.lsb,
> > +               lower_32_bits(child->dar));
> > +     SET_CH_32(dw, chan->dir, chan->id, dar.msb,
> > +               upper_32_bits(child->dar));
> > +
> > +     /* Transfer size */
> > +     SET_CH_32(dw, chan->dir, chan->id, transfer_size, child->sz);
> > +
> > +     /* Interrupt setup */
> > +     val = GET_CH_32(dw, chan->dir, chan->id, int_setup) |
> > +                     HDMA_V0_STOP_INT_MASK |
> > +                     HDMA_V0_ABORT_INT_MASK |
> > +                     HDMA_V0_LOCAL_STOP_INT_EN |
> > +                     HDMA_V0_LOCAL_ABORT_INT_EN;
> > +
> > +     if (!(dw->chip->flags & DW_EDMA_CHIP_LOCAL)) {
> > +             val |= HDMA_V0_REMOTE_STOP_INT_EN |
> > +                    HDMA_V0_REMOTE_ABORT_INT_EN;
> > +     }
> > +
> > +     SET_CH_32(dw, chan->dir, chan->id, int_setup, val);
> > +
> > +     /* Channel control setup */
> > +     val = GET_CH_32(dw, chan->dir, chan->id, control1);
> > +     val &= ~HDMA_V0_LINKLIST_EN;
> > +     SET_CH_32(dw, chan->dir, chan->id, control1, val);
> > +
> > +     SET_CH_32(dw, chan->dir, chan->id, doorbell,
> > +               HDMA_V0_DOORBELL_START);
> > +
> > +}
> > +
> > +static void dw_hdma_v0_core_start(struct dw_edma_chunk *chunk, bool
> > +first) {
> > +     struct dw_edma_chan *chan = chunk->chan;
> > +
> > +     if (chan->non_ll)
> > +             dw_hdma_v0_core_non_ll_start(chunk);
> > +     else
> > +             dw_hdma_v0_core_ll_start(chunk, first); }
> > +
> >  static void dw_hdma_v0_core_ch_config(struct dw_edma_chan *chan)  {
> >       struct dw_edma *dw = chan->dw;
> > diff --git a/drivers/dma/dw-edma/dw-hdma-v0-regs.h
> > b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
> > index eab5fd7177e5..7759ba9b4850 100644
> > --- a/drivers/dma/dw-edma/dw-hdma-v0-regs.h
> > +++ b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
> > @@ -12,6 +12,7 @@
> >  #include <linux/dmaengine.h>
> >
> >  #define HDMA_V0_MAX_NR_CH                    8
> > +#define HDMA_V0_CH_EN                                BIT(0)
> >  #define HDMA_V0_LOCAL_ABORT_INT_EN           BIT(6)
> >  #define HDMA_V0_REMOTE_ABORT_INT_EN          BIT(5)
> >  #define HDMA_V0_LOCAL_STOP_INT_EN            BIT(4)
> > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h index
> > 3080747689f6..78ce31b049ae 100644
> > --- a/include/linux/dma/edma.h
> > +++ b/include/linux/dma/edma.h
> > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> >       enum dw_edma_map_format mf;
> >
> >       struct dw_edma          *dw;
> > +     bool                    non_ll;
>
> Can you check ll_region directly? it should be equal to (ll_region->sz == 0) ?
>
> Frank
> >  };
> >
> >  /* Export to the platform drivers */
> > --
> > 2.43.0
> >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Tue, Feb 17, 2026 at 11:48:45AM +0000, Verma, Devendra wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Frank
>
> Please check my responses inline.
>
> Regards,
> Devendra
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Tuesday, February 17, 2026 1:16 AM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma wrote:
> > > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > > The current code does not have the mechanisms to enable the DMA
> > > transactions using the non-LL mode. The following two cases are added
> > > with this patch:
> > > - For the AMD (Xilinx) only, when a valid physical base address of
> > >   the device side DDR is not configured, then the IP can still be
> > >   used in non-LL mode. For all the channels DMA transactions will
> > >   be using the non-LL mode only. This, the default non-LL mode,
> > >   is not applicable for Synopsys IP with the current code addition.
> > >
> > > - If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
> > >   and if user wants to use non-LL mode then user can do so via
> > >   configuring the peripheral_config param of dma_slave_config.
> > >
> > > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > > ---
> > > Changes in v10
> > >   Added the peripheral_config check only for HDMA IP in
> > >   dw_edma_device_config().
> > >   Replaced the loop with single entry retrieval for non-LL
> > >   mode.
> > >   Addressed review comments and handled the burst allocation
> > >   by defining 'bursts_max' as per suggestions.
> > >
> > > Changes in v9
> > >   Fixed compilation errors related to macro name mismatch.
> > >
> > > Changes in v8
> > >   Cosmetic change related to comment and code.
> > >
> > > Changes in v7
> > >   No change
> > >
> > > Changes in v6
> > >   Gave definition to bits used for channel configuration.
> > >   Removed the comment related to doorbell.
> > >
> > > Changes in v5
> > >   Variable name 'nollp' changed to 'non_ll'.
> > >   In the dw_edma_device_config() WARN_ON replaced with dev_err().
> > >   Comments follow the 80-column guideline.
> > >
> > > Changes in v4
> > >   No change
> > >
> > > Changes in v3
> > >   No change
> > >
> > > Changes in v2
> > >   Reverted the function return type to u64 for
> > >   dw_edma_get_phys_addr().
> > >
> > > Changes in v1
> > >   Changed the function return type for dw_edma_get_phys_addr().
> > >   Corrected the typo raised in review.
> > > ---
> > >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
> > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-hdma-v0-
> > regs.h |  1 +
> > >  include/linux/dma/edma.h              |  1 +
> > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > index b43255f914f3..ef3d79a9f88d 100644
> > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > @@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
> > dma_chan *dchan,
> > >                                struct dma_slave_config *config)  {
> > >       struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> > > +     int non_ll = 0;
> > > +
> > > +     chan->non_ll = false;
> > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> >
> > Need handle EMDA case. if mf is EDMA, need return error when
> > config->peripheral_config is not NULL. Or remove above check to make
> > code work for both EDMA or HDMA.
> >
>
> For the case of EDMA, the behavior is unchanged.
> Even if the config->peripheral_config param is set then it would be simply ignored.
> This is retention of the previous behavior. This is done because device_slave_config
> has other params which affect the behavior of the DMA transactions, we do not check
> all those params and return any error. The error is returned only in the cases where
> particular parameter from dma_slave_config is used and if the parameter is not as expected
> or in the expected form. The parameter used from dma_slave_config for the particular
> IP type need to be known first then it can be checked for its correctness. This is behavior
> for the peripheral_config which is used for HDMA and thus error checked.

It actaully hidden error. Your patch provide an option, which need't ll
memory to do DMA transfer. DMA consumer actaully don't know which backend
used, which is private information by DMA engine providor.

dw-edma-pcie.c is only one of all edma users, which know DMA engine's
information because it creates this interface.

PCIE-EP framework also create dmaegine, PCIE-EP function driver use DMA
standard interface to get dma-chan.

if (config->peripheral_config) { /* only your specific dma consumer set it now */
	/* optional config information */
	if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
		dev_err("edma have not implmentent no-lll mode\n")
		return -EINVAL
	}

	...
}

Add EDMA support no-ll mode is quite easily in future.

>
> > > +             if (config->peripheral_config &&
> > > +                 config->peripheral_size != sizeof(int)) {
> > > +                     dev_err(dchan->device->dev,
> > > +                             "config param peripheral size mismatch\n");
> > > +                     return -EINVAL;
> > > +             }
> > > +
> > > +             /*
> > > +              * When there is no valid LLP base address available then the
> > > +              * default DMA ops will use the non-LL mode.
> > > +              *
> > > +              * Cases where LL mode is enabled and client wants to use the
> > > +              * non-LL mode then also client can do so via providing the
> > > +              * peripheral_config param.
> > > +              */
> > > +             if (config->peripheral_config)
> > > +                     non_ll = *(int *)config->peripheral_config;
> > > +
> > > +             if (chan->dw->chip->non_ll || (!chan->dw->chip->non_ll
> > > + && non_ll))
> >
> > if chan->dw->chip->non_ll is true, It should return error if you set non_ll false
> > because no LLP base available.
> >
>
> In case the 'chan->dw->chip->non_ll' is true, then the default mode becomes
> non-LL for HDMA ONLY. There is no option to the user to configure the LL mode
> by giving 'non_ll = false' as part of the config->peripheral_config.

This is API's callback, you can't assume caller do all correct things.

> The configuration of default non-LL mode depends on how the IP is programmed
> by the user. The user is aware of the IP configuration.

It is not true. DMA consumer don't know such detail information, which
only know which dma engineer providor.

> The check for non-LL option
> provided by the user is useful when LL-mode is default. That is why the value of
> non_ll == false is not even evaluated.
>
> > > +                     chan->non_ll = true;
> > > +     }
> > >
...
> > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h index
> > > 3080747689f6..78ce31b049ae 100644
> > > --- a/include/linux/dma/edma.h
> > > +++ b/include/linux/dma/edma.h
> > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > >       enum dw_edma_map_format mf;
> > >
> > >       struct dw_edma          *dw;
> > > +     bool                    non_ll;
> >
> > Can you check ll_region directly? it should be equal to (ll_region->sz == 0) ?

Do you miss this questin?

Frank

> >
> > Frank
> > >  };
> > >
> > >  /* Export to the platform drivers */
> > > --
> > > 2.43.0
> > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Tuesday, February 17, 2026 10:09 PM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode

---[ Snipped some text to reduce mail size ]---

> > > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma wrote:
> > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > > > The current code does not have the mechanisms to enable the DMA
> > > > transactions using the non-LL mode. The following two cases are
> > > > added with this patch:
> > > > - For the AMD (Xilinx) only, when a valid physical base address of
> > > >   the device side DDR is not configured, then the IP can still be
> > > >   used in non-LL mode. For all the channels DMA transactions will
> > > >   be using the non-LL mode only. This, the default non-LL mode,
> > > >   is not applicable for Synopsys IP with the current code addition.
> > > >
> > > > - If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
> > > >   and if user wants to use non-LL mode then user can do so via
> > > >   configuring the peripheral_config param of dma_slave_config.
> > > >
> > > > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > > > ---
> > > > Changes in v10
> > > >   Added the peripheral_config check only for HDMA IP in
> > > >   dw_edma_device_config().
> > > >   Replaced the loop with single entry retrieval for non-LL
> > > >   mode.
> > > >   Addressed review comments and handled the burst allocation
> > > >   by defining 'bursts_max' as per suggestions.
> > > >
> > > > Changes in v9
> > > >   Fixed compilation errors related to macro name mismatch.
> > > >
> > > > Changes in v8
> > > >   Cosmetic change related to comment and code.
> > > >
> > > > Changes in v7
> > > >   No change
> > > >
> > > > Changes in v6
> > > >   Gave definition to bits used for channel configuration.
> > > >   Removed the comment related to doorbell.
> > > >
> > > > Changes in v5
> > > >   Variable name 'nollp' changed to 'non_ll'.
> > > >   In the dw_edma_device_config() WARN_ON replaced with dev_err().
> > > >   Comments follow the 80-column guideline.
> > > >
> > > > Changes in v4
> > > >   No change
> > > >
> > > > Changes in v3
> > > >   No change
> > > >
> > > > Changes in v2
> > > >   Reverted the function return type to u64 for
> > > >   dw_edma_get_phys_addr().
> > > >
> > > > Changes in v1
> > > >   Changed the function return type for dw_edma_get_phys_addr().
> > > >   Corrected the typo raised in review.
> > > > ---
> > > >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> > > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
> > > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-hdma-v0-
> > > regs.h |  1 +
> > > >  include/linux/dma/edma.h              |  1 +
> > > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > > index b43255f914f3..ef3d79a9f88d 100644
> > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > @@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
> > > dma_chan *dchan,
> > > >                                struct dma_slave_config *config)  {
> > > >       struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> > > > +     int non_ll = 0;
> > > > +
> > > > +     chan->non_ll = false;
> > > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> > >
> > > Need handle EMDA case. if mf is EDMA, need return error when
> > > config->peripheral_config is not NULL. Or remove above check to make
> > > code work for both EDMA or HDMA.
> > >
> >
> > For the case of EDMA, the behavior is unchanged.
> > Even if the config->peripheral_config param is set then it would be simply
> ignored.
> > This is retention of the previous behavior. This is done because
> > device_slave_config has other params which affect the behavior of the
> > DMA transactions, we do not check all those params and return any
> > error. The error is returned only in the cases where particular
> > parameter from dma_slave_config is used and if the parameter is not as
> > expected or in the expected form. The parameter used from
> > dma_slave_config for the particular IP type need to be known first then it
> can be checked for its correctness. This is behavior for the peripheral_config
> which is used for HDMA and thus error checked.
>
> It actaully hidden error. Your patch provide an option, which need't ll memory
> to do DMA transfer. DMA consumer actaully don't know which backend used,
> which is private information by DMA engine providor.
>
> dw-edma-pcie.c is only one of all edma users, which know DMA engine's
> information because it creates this interface.
>
> PCIE-EP framework also create dmaegine, PCIE-EP function driver use DMA
> standard interface to get dma-chan.
>
> if (config->peripheral_config) { /* only your specific dma consumer set it now
> */
>         /* optional config information */
>         if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
>                 dev_err("edma have not implmentent no-lll mode\n")
>                 return -EINVAL
>         }
>
>         ...
> }
>
> Add EDMA support no-ll mode is quite easily in future.
>

This looks reasonable provided that HDMA got the support for this param.
An error check can be added in the next revision.
The addition may be slightly different as following:
If (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
...
} else if (config->peripheral_config) {
 /* error handling */
}

Using the above, if support needs to be added to EDMA then a check for correct 'mf'
in the if() shall be sufficient.

> >
> > > > +             if (config->peripheral_config &&
> > > > +                 config->peripheral_size != sizeof(int)) {
> > > > +                     dev_err(dchan->device->dev,
> > > > +                             "config param peripheral size mismatch\n");
> > > > +                     return -EINVAL;
> > > > +             }
> > > > +
> > > > +             /*
> > > > +              * When there is no valid LLP base address available then the
> > > > +              * default DMA ops will use the non-LL mode.
> > > > +              *
> > > > +              * Cases where LL mode is enabled and client wants to use the
> > > > +              * non-LL mode then also client can do so via providing the
> > > > +              * peripheral_config param.
> > > > +              */
> > > > +             if (config->peripheral_config)
> > > > +                     non_ll = *(int *)config->peripheral_config;
> > > > +
> > > > +             if (chan->dw->chip->non_ll ||
> > > > + (!chan->dw->chip->non_ll && non_ll))
> > >
> > > if chan->dw->chip->non_ll is true, It should return error if you set
> > > non_ll false because no LLP base available.
> > >
> >
> > In case the 'chan->dw->chip->non_ll' is true, then the default mode
> > becomes non-LL for HDMA ONLY. There is no option to the user to
> > configure the LL mode by giving 'non_ll = false' as part of the config-
> >peripheral_config.
>
> This is API's callback, you can't assume caller do all correct things.
>
> > The configuration of default non-LL mode depends on how the IP is
> > programmed by the user. The user is aware of the IP configuration.
>
> It is not true. DMA consumer don't know such detail information, which only
> know which dma engineer providor.
>

For the DMA consumer the only option is LL mode as default mode. In order to
use the non-LL mode it need to provide the parameter in the form of peripheral_config.
Given the above statement, the consumer even if gives the 'non_ll = false', it is not going
to change any behavior.
Even if the user is not giving the option the assumption is that controller is in LL mode,
unless the DMA engine provider provides the information regarding non-LL mode as default mode
to the DMA consumer explicitly.
In the case where chan->dw->chip->non_ll = true, following case may happen:
- DMA consumer provides no peripheral_config param or simply config->peripheral_config = NULL,
   in this case non_ll = false which is the current flow.
- DMA consumer provides a valid peripheral_config (!= NULL) param but the value is '0', in this case
  It is explicit but it would have the same effect as above case.

DMA consumer is supposed to provide the only option non_ll as it was not available and LL mode
is set as default for the DMA operations.
When 'chan->dw->chip->non_ll = true' then this was added to make the chip usable when
the LLP base addresses are not configured. Without this, user cannot use any of the modes
be it LL or non-LL if the LLP base address is not configured.

> > The check for non-LL option
> > provided by the user is useful when LL-mode is default. That is why
> > the value of non_ll == false is not even evaluated.
> >
> > > > +                     chan->non_ll = true;
> > > > +     }
> > > >
> ...
> > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
> > > > index 3080747689f6..78ce31b049ae 100644
> > > > --- a/include/linux/dma/edma.h
> > > > +++ b/include/linux/dma/edma.h
> > > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > > >       enum dw_edma_map_format mf;
> > > >
> > > >       struct dw_edma          *dw;
> > > > +     bool                    non_ll;
> > >
> > > Can you check ll_region directly? it should be equal to (ll_region->sz == 0)
> ?
>
> Do you miss this questin?
>
> Frank
>

Yes, looks like I missed this question. Could you explain a little bit more? I am unable to understand the context.

> > >
> > > Frank
> > > >  };
> > > >
> > > >  /* Export to the platform drivers */
> > > > --
> > > > 2.43.0
> > > >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Wed, Feb 18, 2026 at 11:32:57AM +0000, Verma, Devendra wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Tuesday, February 17, 2026 10:09 PM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
>
> ---[ Snipped some text to reduce mail size ]---
>
> > > > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma wrote:
> > > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > > > > The current code does not have the mechanisms to enable the DMA
> > > > > transactions using the non-LL mode. The following two cases are
> > > > > added with this patch:
> > > > > - For the AMD (Xilinx) only, when a valid physical base address of
> > > > >   the device side DDR is not configured, then the IP can still be
> > > > >   used in non-LL mode. For all the channels DMA transactions will
> > > > >   be using the non-LL mode only. This, the default non-LL mode,
> > > > >   is not applicable for Synopsys IP with the current code addition.
> > > > >
> > > > > - If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
> > > > >   and if user wants to use non-LL mode then user can do so via
> > > > >   configuring the peripheral_config param of dma_slave_config.
> > > > >
> > > > > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > > > > ---
> > > > > Changes in v10
> > > > >   Added the peripheral_config check only for HDMA IP in
> > > > >   dw_edma_device_config().
> > > > >   Replaced the loop with single entry retrieval for non-LL
> > > > >   mode.
> > > > >   Addressed review comments and handled the burst allocation
> > > > >   by defining 'bursts_max' as per suggestions.
> > > > >
> > > > > Changes in v9
> > > > >   Fixed compilation errors related to macro name mismatch.
> > > > >
> > > > > Changes in v8
> > > > >   Cosmetic change related to comment and code.
> > > > >
> > > > > Changes in v7
> > > > >   No change
> > > > >
> > > > > Changes in v6
> > > > >   Gave definition to bits used for channel configuration.
> > > > >   Removed the comment related to doorbell.
> > > > >
> > > > > Changes in v5
> > > > >   Variable name 'nollp' changed to 'non_ll'.
> > > > >   In the dw_edma_device_config() WARN_ON replaced with dev_err().
> > > > >   Comments follow the 80-column guideline.
> > > > >
> > > > > Changes in v4
> > > > >   No change
> > > > >
> > > > > Changes in v3
> > > > >   No change
> > > > >
> > > > > Changes in v2
> > > > >   Reverted the function return type to u64 for
> > > > >   dw_edma_get_phys_addr().
> > > > >
> > > > > Changes in v1
> > > > >   Changed the function return type for dw_edma_get_phys_addr().
> > > > >   Corrected the typo raised in review.
> > > > > ---
> > > > >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> > > > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > > > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
> > > > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-hdma-v0-
> > > > regs.h |  1 +
> > > > >  include/linux/dma/edma.h              |  1 +
> > > > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > > > >
> > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > index b43255f914f3..ef3d79a9f88d 100644
> > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > @@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
> > > > dma_chan *dchan,
> > > > >                                struct dma_slave_config *config)  {
> > > > >       struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> > > > > +     int non_ll = 0;
> > > > > +
> > > > > +     chan->non_ll = false;
> > > > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> > > >
> > > > Need handle EMDA case. if mf is EDMA, need return error when
> > > > config->peripheral_config is not NULL. Or remove above check to make
> > > > code work for both EDMA or HDMA.
> > > >
> > >
> > > For the case of EDMA, the behavior is unchanged.
> > > Even if the config->peripheral_config param is set then it would be simply
> > ignored.
> > > This is retention of the previous behavior. This is done because
> > > device_slave_config has other params which affect the behavior of the
> > > DMA transactions, we do not check all those params and return any
> > > error. The error is returned only in the cases where particular
> > > parameter from dma_slave_config is used and if the parameter is not as
> > > expected or in the expected form. The parameter used from
> > > dma_slave_config for the particular IP type need to be known first then it
> > can be checked for its correctness. This is behavior for the peripheral_config
> > which is used for HDMA and thus error checked.
> >
> > It actaully hidden error. Your patch provide an option, which need't ll memory
> > to do DMA transfer. DMA consumer actaully don't know which backend used,
> > which is private information by DMA engine providor.
> >
> > dw-edma-pcie.c is only one of all edma users, which know DMA engine's
> > information because it creates this interface.
> >
> > PCIE-EP framework also create dmaegine, PCIE-EP function driver use DMA
> > standard interface to get dma-chan.
> >
> > if (config->peripheral_config) { /* only your specific dma consumer set it now
> > */
> >         /* optional config information */
> >         if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
> >                 dev_err("edma have not implmentent no-lll mode\n")
> >                 return -EINVAL
> >         }
> >
> >         ...
> > }
> >
> > Add EDMA support no-ll mode is quite easily in future.
> >
>
> This looks reasonable provided that HDMA got the support for this param.
> An error check can be added in the next revision.
> The addition may be slightly different as following:
> If (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> ...
> } else if (config->peripheral_config) {
>  /* error handling */
> }
>
> Using the above, if support needs to be added to EDMA then a check for correct 'mf'
> in the if() shall be sufficient.
>
> > >
> > > > > +             if (config->peripheral_config &&
> > > > > +                 config->peripheral_size != sizeof(int)) {
> > > > > +                     dev_err(dchan->device->dev,
> > > > > +                             "config param peripheral size mismatch\n");
> > > > > +                     return -EINVAL;
> > > > > +             }
> > > > > +
> > > > > +             /*
> > > > > +              * When there is no valid LLP base address available then the
> > > > > +              * default DMA ops will use the non-LL mode.
> > > > > +              *
> > > > > +              * Cases where LL mode is enabled and client wants to use the
> > > > > +              * non-LL mode then also client can do so via providing the
> > > > > +              * peripheral_config param.
> > > > > +              */
> > > > > +             if (config->peripheral_config)
> > > > > +                     non_ll = *(int *)config->peripheral_config;
> > > > > +
> > > > > +             if (chan->dw->chip->non_ll ||
> > > > > + (!chan->dw->chip->non_ll && non_ll))
> > > >
> > > > if chan->dw->chip->non_ll is true, It should return error if you set
> > > > non_ll false because no LLP base available.
> > > >
> > >
> > > In case the 'chan->dw->chip->non_ll' is true, then the default mode
> > > becomes non-LL for HDMA ONLY. There is no option to the user to
> > > configure the LL mode by giving 'non_ll = false' as part of the config-
> > >peripheral_config.
> >
> > This is API's callback, you can't assume caller do all correct things.
> >
> > > The configuration of default non-LL mode depends on how the IP is
> > > programmed by the user. The user is aware of the IP configuration.
> >
> > It is not true. DMA consumer don't know such detail information, which only
> > know which dma engineer providor.
> >
>
> For the DMA consumer the only option is LL mode as default mode. In order to
> use the non-LL mode it need to provide the parameter in the form of peripheral_config.
> Given the above statement, the consumer even if gives the 'non_ll = false', it is not going
> to change any behavior.
> Even if the user is not giving the option the assumption is that controller is in LL mode,
> unless the DMA engine provider provides the information regarding non-LL mode as default mode
> to the DMA consumer explicitly.
> In the case where chan->dw->chip->non_ll = true, following case may happen:
> - DMA consumer provides no peripheral_config param or simply config->peripheral_config = NULL,
>    in this case non_ll = false which is the current flow.
> - DMA consumer provides a valid peripheral_config (!= NULL) param but the value is '0', in this case
>   It is explicit but it would have the same effect as above case.
>
> DMA consumer is supposed to provide the only option non_ll as it was not available and LL mode
> is set as default for the DMA operations.
> When 'chan->dw->chip->non_ll = true' then this was added to make the chip usable when
> the LLP base addresses are not configured. Without this, user cannot use any of the modes
> be it LL or non-LL if the LLP base address is not configured.

little bit confuse, Maybe the same as you. I expected behavor

config->peripheral_config = NULL        choose hardware default one
					- 	    LL mode if hardware support
					-      none-LL mode if not ll list region

config->peripheral_config != NULL
EDMA: return false
HDMA:
		0			force to none_ll mode. (always success)
		1			force back to ll mode  (return false if no ll list region in chip)

DMA consumer decide if fall back to none_ll to continue.

>
> > > The check for non-LL option
> > > provided by the user is useful when LL-mode is default. That is why
> > > the value of non_ll == false is not even evaluated.
> > >
> > > > > +                     chan->non_ll = true;
> > > > > +     }
> > > > >
> > ...
> > > > > diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
> > > > > index 3080747689f6..78ce31b049ae 100644
> > > > > --- a/include/linux/dma/edma.h
> > > > > +++ b/include/linux/dma/edma.h
> > > > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > > > >       enum dw_edma_map_format mf;
> > > > >
> > > > >       struct dw_edma          *dw;
> > > > > +     bool                    non_ll;
> > > >
> > > > Can you check ll_region directly? it should be equal to (ll_region->sz == 0)
> > ?
> >
> > Do you miss this questin?
> >
> > Frank
> >
>
> Yes, looks like I missed this question. Could you explain a little bit more? I am unable to understand the context.

you set chip->non_ll = non_ll in dw_edma_pcie_probe()

and only set ll_region->sz = ll_block->sz when !chip->non_ll.

Thats means ll_region->sz is 0 when chip->non_ll is true.

So non_ll have not bring new infomation into dw_edma_chip.

check !ll_region->sz, which should be equal to this non_ll.

dw_edma_chip is the exchange information between controller and dma core
driver. Needn't cache it here because you already save a copy in dma-chan.

Frank
>
> > > >
> > > > Frank
> > > > >  };
> > > > >
> > > > >  /* Export to the platform drivers */
> > > > > --
> > > > > 2.43.0
> > > > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Wednesday, February 18, 2026 9:20 PM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode

---[ Snipped some text to reduce mail size ]---

> > > > > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma wrote:
> > > > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > > > > > The current code does not have the mechanisms to enable the
> > > > > > DMA transactions using the non-LL mode. The following two
> > > > > > cases are added with this patch:
> > > > > > - For the AMD (Xilinx) only, when a valid physical base address of
> > > > > >   the device side DDR is not configured, then the IP can still be
> > > > > >   used in non-LL mode. For all the channels DMA transactions will
> > > > > >   be using the non-LL mode only. This, the default non-LL mode,
> > > > > >   is not applicable for Synopsys IP with the current code addition.
> > > > > >
> > > > > > - If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
> > > > > >   and if user wants to use non-LL mode then user can do so via
> > > > > >   configuring the peripheral_config param of dma_slave_config.
> > > > > >
> > > > > > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > > > > > ---
> > > > > > Changes in v10
> > > > > >   Added the peripheral_config check only for HDMA IP in
> > > > > >   dw_edma_device_config().
> > > > > >   Replaced the loop with single entry retrieval for non-LL
> > > > > >   mode.
> > > > > >   Addressed review comments and handled the burst allocation
> > > > > >   by defining 'bursts_max' as per suggestions.
> > > > > >
> > > > > > Changes in v9
> > > > > >   Fixed compilation errors related to macro name mismatch.
> > > > > >
> > > > > > Changes in v8
> > > > > >   Cosmetic change related to comment and code.
> > > > > >
> > > > > > Changes in v7
> > > > > >   No change
> > > > > >
> > > > > > Changes in v6
> > > > > >   Gave definition to bits used for channel configuration.
> > > > > >   Removed the comment related to doorbell.
> > > > > >
> > > > > > Changes in v5
> > > > > >   Variable name 'nollp' changed to 'non_ll'.
> > > > > >   In the dw_edma_device_config() WARN_ON replaced with
> dev_err().
> > > > > >   Comments follow the 80-column guideline.
> > > > > >
> > > > > > Changes in v4
> > > > > >   No change
> > > > > >
> > > > > > Changes in v3
> > > > > >   No change
> > > > > >
> > > > > > Changes in v2
> > > > > >   Reverted the function return type to u64 for
> > > > > >   dw_edma_get_phys_addr().
> > > > > >
> > > > > > Changes in v1
> > > > > >   Changed the function return type for dw_edma_get_phys_addr().
> > > > > >   Corrected the typo raised in review.
> > > > > > ---
> > > > > >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> > > > > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > > > > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
> > > > > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > > > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-hdma-
> v0-
> > > > > regs.h |  1 +
> > > > > >  include/linux/dma/edma.h              |  1 +
> > > > > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > index b43255f914f3..ef3d79a9f88d 100644
> > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > @@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
> > > > > dma_chan *dchan,
> > > > > >                                struct dma_slave_config *config)  {
> > > > > >       struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> > > > > > +     int non_ll = 0;
> > > > > > +
> > > > > > +     chan->non_ll = false;
> > > > > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> > > > >
> > > > > Need handle EMDA case. if mf is EDMA, need return error when
> > > > > config->peripheral_config is not NULL. Or remove above check to
> > > > > config->make
> > > > > code work for both EDMA or HDMA.
> > > > >
> > > >
> > > > For the case of EDMA, the behavior is unchanged.
> > > > Even if the config->peripheral_config param is set then it would
> > > > be simply
> > > ignored.
> > > > This is retention of the previous behavior. This is done because
> > > > device_slave_config has other params which affect the behavior of
> > > > the DMA transactions, we do not check all those params and return
> > > > any error. The error is returned only in the cases where
> > > > particular parameter from dma_slave_config is used and if the
> > > > parameter is not as expected or in the expected form. The
> > > > parameter used from dma_slave_config for the particular IP type
> > > > need to be known first then it
> > > can be checked for its correctness. This is behavior for the
> > > peripheral_config which is used for HDMA and thus error checked.
> > >
> > > It actaully hidden error. Your patch provide an option, which need't
> > > ll memory to do DMA transfer. DMA consumer actaully don't know which
> > > backend used, which is private information by DMA engine providor.
> > >
> > > dw-edma-pcie.c is only one of all edma users, which know DMA
> > > engine's information because it creates this interface.
> > >
> > > PCIE-EP framework also create dmaegine, PCIE-EP function driver use
> > > DMA standard interface to get dma-chan.
> > >
> > > if (config->peripheral_config) { /* only your specific dma consumer
> > > set it now */
> > >         /* optional config information */
> > >         if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
> > >                 dev_err("edma have not implmentent no-lll mode\n")
> > >                 return -EINVAL
> > >         }
> > >
> > >         ...
> > > }
> > >
> > > Add EDMA support no-ll mode is quite easily in future.
> > >
> >
> > This looks reasonable provided that HDMA got the support for this param.
> > An error check can be added in the next revision.
> > The addition may be slightly different as following:
> > If (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) { ...
> > } else if (config->peripheral_config) {
> >  /* error handling */
> > }
> >
> > Using the above, if support needs to be added to EDMA then a check for
> correct 'mf'
> > in the if() shall be sufficient.
> >
> > > >
> > > > > > +             if (config->peripheral_config &&
> > > > > > +                 config->peripheral_size != sizeof(int)) {
> > > > > > +                     dev_err(dchan->device->dev,
> > > > > > +                             "config param peripheral size mismatch\n");
> > > > > > +                     return -EINVAL;
> > > > > > +             }
> > > > > > +
> > > > > > +             /*
> > > > > > +              * When there is no valid LLP base address available then
> the
> > > > > > +              * default DMA ops will use the non-LL mode.
> > > > > > +              *
> > > > > > +              * Cases where LL mode is enabled and client wants to use
> the
> > > > > > +              * non-LL mode then also client can do so via providing the
> > > > > > +              * peripheral_config param.
> > > > > > +              */
> > > > > > +             if (config->peripheral_config)
> > > > > > +                     non_ll = *(int
> > > > > > + *)config->peripheral_config;
> > > > > > +
> > > > > > +             if (chan->dw->chip->non_ll ||
> > > > > > + (!chan->dw->chip->non_ll && non_ll))
> > > > >
> > > > > if chan->dw->chip->non_ll is true, It should return error if you
> > > > > set non_ll false because no LLP base available.
> > > > >
> > > >
> > > > In case the 'chan->dw->chip->non_ll' is true, then the default
> > > >mode  becomes non-LL for HDMA ONLY. There is no option to the user
> > > >to  configure the LL mode by giving 'non_ll = false' as part of the
> > > >config- peripheral_config.
> > >
> > > This is API's callback, you can't assume caller do all correct things.
> > >
> > > > The configuration of default non-LL mode depends on how the IP is
> > > > programmed by the user. The user is aware of the IP configuration.
> > >
> > > It is not true. DMA consumer don't know such detail information,
> > > which only know which dma engineer providor.
> > >
> >
> > For the DMA consumer the only option is LL mode as default mode. In
> > order to use the non-LL mode it need to provide the parameter in the form
> of peripheral_config.
> > Given the above statement, the consumer even if gives the 'non_ll =
> > false', it is not going to change any behavior.
> > Even if the user is not giving the option the assumption is that
> > controller is in LL mode, unless the DMA engine provider provides the
> > information regarding non-LL mode as default mode to the DMA consumer
> explicitly.
> > In the case where chan->dw->chip->non_ll = true, following case may
> happen:
> > - DMA consumer provides no peripheral_config param or simply config-
> >peripheral_config = NULL,
> >    in this case non_ll = false which is the current flow.
> > - DMA consumer provides a valid peripheral_config (!= NULL) param but the
> value is '0', in this case
> >   It is explicit but it would have the same effect as above case.
> >
> > DMA consumer is supposed to provide the only option non_ll as it was
> > not available and LL mode is set as default for the DMA operations.
> > When 'chan->dw->chip->non_ll = true' then this was added to make the
> > chip usable when the LLP base addresses are not configured. Without
> > this, user cannot use any of the modes be it LL or non-LL if the LLP base
> address is not configured.
>
> little bit confuse, Maybe the same as you. I expected behavor
>
> config->peripheral_config = NULL        choose hardware default one
>                                         -           LL mode if hardware support
>                                         -      none-LL mode if not ll list region
>
> config->peripheral_config != NULL
> EDMA: return false
> HDMA:
>                 0                       force to none_ll mode. (always success)
>                 1                       force back to ll mode  (return false if no ll list region in
> chip)
>
> DMA consumer decide if fall back to none_ll to continue.
>

Thank you for the elaboration!
I have few questions, why shall a DMA consumer decide to enable LL mode when the
default mode supported is LL mode only?

If DMA consumer is trying to enable the LL mode, then one must be knowing the configuration
of the controller that controller is working in non-LL mode, as LLP base address is not configured,
then why to try and enable the LL mode?

The user need to know, at least, one detail from the above two cases.

The use for non-LL mode is useful in the following scenario:
- When user want to utilize the LL regions also for DMA data transfers.
- For single and big chunks non-LL mode is useful in both use-cases when non-LL mode is default or
  user enables it via peripheral_config params.
- This addition, inadvertently, makes the DMA controller usable, for AMD (Xilinx) only, when the LLP
  base addresses are not configured; it can be used in non-LL mode. For Synopsys, DMA controller
  cannot be used in any mode if LLP base address is not configured.

Based on the above points, if user is trying to enable LL mode when default mode is LL mode, it looks
Intentionally making the choice when user is aware of the mode DMA controller operating in.
Please let me know if this clarifies the doubt.

> >
> > > > The check for non-LL option
> > > > provided by the user is useful when LL-mode is default. That is
> > > > why the value of non_ll == false is not even evaluated.
> > > >
> > > > > > +                     chan->non_ll = true;
> > > > > > +     }
> > > > > >
> > > ...
> > > > > > diff --git a/include/linux/dma/edma.h
> > > > > > b/include/linux/dma/edma.h index 3080747689f6..78ce31b049ae
> > > > > > 100644
> > > > > > --- a/include/linux/dma/edma.h
> > > > > > +++ b/include/linux/dma/edma.h
> > > > > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > > > > >       enum dw_edma_map_format mf;
> > > > > >
> > > > > >       struct dw_edma          *dw;
> > > > > > +     bool                    non_ll;
> > > > >
> > > > > Can you check ll_region directly? it should be equal to
> > > > > (ll_region->sz == 0)
> > > ?
> > >
> > > Do you miss this questin?
> > >
> > > Frank
> > >
> >
> > Yes, looks like I missed this question. Could you explain a little bit more? I
> am unable to understand the context.
>
> you set chip->non_ll = non_ll in dw_edma_pcie_probe()
>
> and only set ll_region->sz = ll_block->sz when !chip->non_ll.
>
> Thats means ll_region->sz is 0 when chip->non_ll is true.
>
> So non_ll have not bring new infomation into dw_edma_chip.
>
> check !ll_region->sz, which should be equal to this non_ll.
>
> dw_edma_chip is the exchange information between controller and dma core
> driver. Needn't cache it here because you already save a copy in dma-chan.
>
> Frank

I understand the concern here but it does not look good to piggyback the
non_ll related information on the existing variable.
The use of bool readily points out the information related to what mode is being intended
but using the ll_region->sz is an inference the user has to make.

Having ll_region->sz == 0 does not really tell it is non_ll mode or not, it can also mean that
the size of LL region is zero while in LL mode which could be an error.
This does not translate to support for non-LL mode. This brings the ambiguity.
The introduction of the non_ll provides clarity and easy comparison with the similar
choice (non_ll) provided by the DMA consumer in the dmaengine_slave_config().
I request we shall retain the clarity here.

> >
> > > > >
> > > > > Frank
> > > > > >  };
> > > > > >
> > > > > >  /* Export to the platform drivers */
> > > > > > --
> > > > > > 2.43.0
> > > > > >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Thu, Feb 19, 2026 at 09:55:49AM +0000, Verma, Devendra wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Wednesday, February 18, 2026 9:20 PM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
>
> ---[ Snipped some text to reduce mail size ]---
>
> > > > > > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma wrote:
> > > > > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL mode.
> > > > > > > The current code does not have the mechanisms to enable the
> > > > > > > DMA transactions using the non-LL mode. The following two
> > > > > > > cases are added with this patch:
> > > > > > > - For the AMD (Xilinx) only, when a valid physical base address of
> > > > > > >   the device side DDR is not configured, then the IP can still be
> > > > > > >   used in non-LL mode. For all the channels DMA transactions will
> > > > > > >   be using the non-LL mode only. This, the default non-LL mode,
> > > > > > >   is not applicable for Synopsys IP with the current code addition.
> > > > > > >
> > > > > > > - If the default mode is LL-mode, for both AMD (Xilinx) and Synosys,
> > > > > > >   and if user wants to use non-LL mode then user can do so via
> > > > > > >   configuring the peripheral_config param of dma_slave_config.
> > > > > > >
> > > > > > > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > > > > > > ---
> > > > > > > Changes in v10
> > > > > > >   Added the peripheral_config check only for HDMA IP in
> > > > > > >   dw_edma_device_config().
> > > > > > >   Replaced the loop with single entry retrieval for non-LL
> > > > > > >   mode.
> > > > > > >   Addressed review comments and handled the burst allocation
> > > > > > >   by defining 'bursts_max' as per suggestions.
> > > > > > >
> > > > > > > Changes in v9
> > > > > > >   Fixed compilation errors related to macro name mismatch.
> > > > > > >
> > > > > > > Changes in v8
> > > > > > >   Cosmetic change related to comment and code.
> > > > > > >
> > > > > > > Changes in v7
> > > > > > >   No change
> > > > > > >
> > > > > > > Changes in v6
> > > > > > >   Gave definition to bits used for channel configuration.
> > > > > > >   Removed the comment related to doorbell.
> > > > > > >
> > > > > > > Changes in v5
> > > > > > >   Variable name 'nollp' changed to 'non_ll'.
> > > > > > >   In the dw_edma_device_config() WARN_ON replaced with
> > dev_err().
> > > > > > >   Comments follow the 80-column guideline.
> > > > > > >
> > > > > > > Changes in v4
> > > > > > >   No change
> > > > > > >
> > > > > > > Changes in v3
> > > > > > >   No change
> > > > > > >
> > > > > > > Changes in v2
> > > > > > >   Reverted the function return type to u64 for
> > > > > > >   dw_edma_get_phys_addr().
> > > > > > >
> > > > > > > Changes in v1
> > > > > > >   Changed the function return type for dw_edma_get_phys_addr().
> > > > > > >   Corrected the typo raised in review.
> > > > > > > ---
> > > > > > >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> > > > > > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > > > > > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++------
> > > > > > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > > > > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-hdma-
> > v0-
> > > > > > regs.h |  1 +
> > > > > > >  include/linux/dma/edma.h              |  1 +
> > > > > > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > index b43255f914f3..ef3d79a9f88d 100644
> > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > @@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
> > > > > > dma_chan *dchan,
> > > > > > >                                struct dma_slave_config *config)  {
> > > > > > >       struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> > > > > > > +     int non_ll = 0;
> > > > > > > +
> > > > > > > +     chan->non_ll = false;
> > > > > > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> > > > > >
> > > > > > Need handle EMDA case. if mf is EDMA, need return error when
> > > > > > config->peripheral_config is not NULL. Or remove above check to
> > > > > > config->make
> > > > > > code work for both EDMA or HDMA.
> > > > > >
> > > > >
> > > > > For the case of EDMA, the behavior is unchanged.
> > > > > Even if the config->peripheral_config param is set then it would
> > > > > be simply
> > > > ignored.
> > > > > This is retention of the previous behavior. This is done because
> > > > > device_slave_config has other params which affect the behavior of
> > > > > the DMA transactions, we do not check all those params and return
> > > > > any error. The error is returned only in the cases where
> > > > > particular parameter from dma_slave_config is used and if the
> > > > > parameter is not as expected or in the expected form. The
> > > > > parameter used from dma_slave_config for the particular IP type
> > > > > need to be known first then it
> > > > can be checked for its correctness. This is behavior for the
> > > > peripheral_config which is used for HDMA and thus error checked.
> > > >
> > > > It actaully hidden error. Your patch provide an option, which need't
> > > > ll memory to do DMA transfer. DMA consumer actaully don't know which
> > > > backend used, which is private information by DMA engine providor.
> > > >
> > > > dw-edma-pcie.c is only one of all edma users, which know DMA
> > > > engine's information because it creates this interface.
> > > >
> > > > PCIE-EP framework also create dmaegine, PCIE-EP function driver use
> > > > DMA standard interface to get dma-chan.
> > > >
> > > > if (config->peripheral_config) { /* only your specific dma consumer
> > > > set it now */
> > > >         /* optional config information */
> > > >         if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
> > > >                 dev_err("edma have not implmentent no-lll mode\n")
> > > >                 return -EINVAL
> > > >         }
> > > >
> > > >         ...
> > > > }
> > > >
> > > > Add EDMA support no-ll mode is quite easily in future.
> > > >
> > >
> > > This looks reasonable provided that HDMA got the support for this param.
> > > An error check can be added in the next revision.
> > > The addition may be slightly different as following:
> > > If (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) { ...
> > > } else if (config->peripheral_config) {
> > >  /* error handling */
> > > }
> > >
> > > Using the above, if support needs to be added to EDMA then a check for
> > correct 'mf'
> > > in the if() shall be sufficient.
> > >
> > > > >
> > > > > > > +             if (config->peripheral_config &&
> > > > > > > +                 config->peripheral_size != sizeof(int)) {
> > > > > > > +                     dev_err(dchan->device->dev,
> > > > > > > +                             "config param peripheral size mismatch\n");
> > > > > > > +                     return -EINVAL;
> > > > > > > +             }
> > > > > > > +
> > > > > > > +             /*
> > > > > > > +              * When there is no valid LLP base address available then
> > the
> > > > > > > +              * default DMA ops will use the non-LL mode.
> > > > > > > +              *
> > > > > > > +              * Cases where LL mode is enabled and client wants to use
> > the
> > > > > > > +              * non-LL mode then also client can do so via providing the
> > > > > > > +              * peripheral_config param.
> > > > > > > +              */
> > > > > > > +             if (config->peripheral_config)
> > > > > > > +                     non_ll = *(int
> > > > > > > + *)config->peripheral_config;
> > > > > > > +
> > > > > > > +             if (chan->dw->chip->non_ll ||
> > > > > > > + (!chan->dw->chip->non_ll && non_ll))
> > > > > >
> > > > > > if chan->dw->chip->non_ll is true, It should return error if you
> > > > > > set non_ll false because no LLP base available.
> > > > > >
> > > > >
> > > > > In case the 'chan->dw->chip->non_ll' is true, then the default
> > > > >mode  becomes non-LL for HDMA ONLY. There is no option to the user
> > > > >to  configure the LL mode by giving 'non_ll = false' as part of the
> > > > >config- peripheral_config.
> > > >
> > > > This is API's callback, you can't assume caller do all correct things.
> > > >
> > > > > The configuration of default non-LL mode depends on how the IP is
> > > > > programmed by the user. The user is aware of the IP configuration.
> > > >
> > > > It is not true. DMA consumer don't know such detail information,
> > > > which only know which dma engineer providor.
> > > >
> > >
> > > For the DMA consumer the only option is LL mode as default mode. In
> > > order to use the non-LL mode it need to provide the parameter in the form
> > of peripheral_config.
> > > Given the above statement, the consumer even if gives the 'non_ll =
> > > false', it is not going to change any behavior.
> > > Even if the user is not giving the option the assumption is that
> > > controller is in LL mode, unless the DMA engine provider provides the
> > > information regarding non-LL mode as default mode to the DMA consumer
> > explicitly.
> > > In the case where chan->dw->chip->non_ll = true, following case may
> > happen:
> > > - DMA consumer provides no peripheral_config param or simply config-
> > >peripheral_config = NULL,
> > >    in this case non_ll = false which is the current flow.
> > > - DMA consumer provides a valid peripheral_config (!= NULL) param but the
> > value is '0', in this case
> > >   It is explicit but it would have the same effect as above case.
> > >
> > > DMA consumer is supposed to provide the only option non_ll as it was
> > > not available and LL mode is set as default for the DMA operations.
> > > When 'chan->dw->chip->non_ll = true' then this was added to make the
> > > chip usable when the LLP base addresses are not configured. Without
> > > this, user cannot use any of the modes be it LL or non-LL if the LLP base
> > address is not configured.
> >
> > little bit confuse, Maybe the same as you. I expected behavor
> >
> > config->peripheral_config = NULL        choose hardware default one
> >                                         -           LL mode if hardware support
> >                                         -      none-LL mode if not ll list region
> >
> > config->peripheral_config != NULL
> > EDMA: return false
> > HDMA:
> >                 0                       force to none_ll mode. (always success)
> >                 1                       force back to ll mode  (return false if no ll list region in
> > chip)
> >
> > DMA consumer decide if fall back to none_ll to continue.
> >
>
> Thank you for the elaboration!
> I have few questions, why shall a DMA consumer decide to enable LL mode when the
> default mode supported is LL mode only?

LL mode only is software driver implement. Hardware support both LL mode
and no-LL mode. Previous driver implement only support LL mode. You try
to add non-LL mode. Choose straightforward forward method.

One indicate hardware capacity,  one actually used. Like PCI INTX and MSI.
If support MSI, most case use MSI. But still support switch to use INTX.

My key point avoid hidden beavior. Every branch is clean and
straightforward.

>
> If DMA consumer is trying to enable the LL mode, then one must be knowing the configuration
> of the controller that controller is working in non-LL mode,
> as LLP base address is not configured,then why to try and enable the LL mode?

The DMA consumer don't know these informaiton.

>
> The user need to know, at least, one detail from the above two cases.
>
> The use for non-LL mode is useful in the following scenario:
> - When user want to utilize the LL regions also for DMA data transfers.
> - For single and big chunks non-LL mode is useful in both use-cases when non-LL mode is default or
>   user enables it via peripheral_config params.
> - This addition, inadvertently, makes the DMA controller usable, for AMD (Xilinx) only, when the LLP
>   base addresses are not configured; it can be used in non-LL mode.

LL regions may not visiable,  User can use non-ll to config LL-region and
switch back to use LL-region to continue transfer. User may use non-ll
as indirectly reg access.

> For Synopsys, DMA controller
>   cannot be used in any mode if LLP base address is not configured.

Does spec said it? It doesn't make sense. it should be controlled by LLE
of DMA_CH_CONTROL1_OFF_RDCH_0.

>
> Based on the above points, if user is trying to enable LL mode when default mode is LL mode, it looks
> Intentionally making the choice when user is aware of the mode DMA controller operating in.
> Please let me know if this clarifies the doubt.

No API to get mode, only use set and test to know it.

Actually Needn't consider so complex. like functions API(x)

We just consider input x,

	validate x's input ragion,

	if x is out of region, just return error.

>
> > >
> > > > > The check for non-LL option
> > > > > provided by the user is useful when LL-mode is default. That is
> > > > > why the value of non_ll == false is not even evaluated.
> > > > >
> > > > > > > +                     chan->non_ll = true;
> > > > > > > +     }
> > > > > > >
> > > > ...
> > > > > > > diff --git a/include/linux/dma/edma.h
> > > > > > > b/include/linux/dma/edma.h index 3080747689f6..78ce31b049ae
> > > > > > > 100644
> > > > > > > --- a/include/linux/dma/edma.h
> > > > > > > +++ b/include/linux/dma/edma.h
> > > > > > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > > > > > >       enum dw_edma_map_format mf;
> > > > > > >
> > > > > > >       struct dw_edma          *dw;
> > > > > > > +     bool                    non_ll;
> > > > > >
> > > > > > Can you check ll_region directly? it should be equal to
> > > > > > (ll_region->sz == 0)
> > > > ?
> > > >
> > > > Do you miss this questin?
> > > >
> > > > Frank
> > > >
> > >
> > > Yes, looks like I missed this question. Could you explain a little bit more? I
> > am unable to understand the context.
> >
> > you set chip->non_ll = non_ll in dw_edma_pcie_probe()
> >
> > and only set ll_region->sz = ll_block->sz when !chip->non_ll.
> >
> > Thats means ll_region->sz is 0 when chip->non_ll is true.
> >
> > So non_ll have not bring new infomation into dw_edma_chip.
> >
> > check !ll_region->sz, which should be equal to this non_ll.
> >
> > dw_edma_chip is the exchange information between controller and dma core
> > driver. Needn't cache it here because you already save a copy in dma-chan.
> >
> > Frank
>
> I understand the concern here but it does not look good to piggyback the
> non_ll related information on the existing variable.
> The use of bool readily points out the information related to what mode is being intended
> but using the ll_region->sz is an inference the user has to make.
>
> Having ll_region->sz == 0 does not really tell it is non_ll mode or not, it can also mean that
> the size of LL region is zero while in LL mode which could be an error.
> This does not translate to support for non-LL mode. This brings the ambiguity.
> The introduction of the non_ll provides clarity and easy comparison with the similar
> choice (non_ll) provided by the DMA consumer in the dmaengine_slave_config().
> I request we shall retain the clarity here.

You can use helper(dw_chip_is_support_ll()) macro to check chip's capatiblity.

Frank
>
> > >
> > > > > >
> > > > > > Frank
> > > > > > >  };
> > > > > > >
> > > > > > >  /* Export to the platform drivers */
> > > > > > > --
> > > > > > > 2.43.0
> > > > > > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Frank
Please check my response inline

Regards,
Devendra
> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Thursday, February 19, 2026 10:38 PM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode

---[ Snipped some text to reduce mail size ]---

> > > > > > > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma
> wrote:
> > > > > > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL
> mode.
> > > > > > > > The current code does not have the mechanisms to enable
> > > > > > > > the DMA transactions using the non-LL mode. The following
> > > > > > > > two cases are added with this patch:
> > > > > > > > - For the AMD (Xilinx) only, when a valid physical base address of
> > > > > > > >   the device side DDR is not configured, then the IP can still be
> > > > > > > >   used in non-LL mode. For all the channels DMA transactions will
> > > > > > > >   be using the non-LL mode only. This, the default non-LL mode,
> > > > > > > >   is not applicable for Synopsys IP with the current code addition.
> > > > > > > >
> > > > > > > > - If the default mode is LL-mode, for both AMD (Xilinx) and
> Synosys,
> > > > > > > >   and if user wants to use non-LL mode then user can do so via
> > > > > > > >   configuring the peripheral_config param of dma_slave_config.
> > > > > > > >
> > > > > > > > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > > > > > > > ---
> > > > > > > > Changes in v10
> > > > > > > >   Added the peripheral_config check only for HDMA IP in
> > > > > > > >   dw_edma_device_config().
> > > > > > > >   Replaced the loop with single entry retrieval for non-LL
> > > > > > > >   mode.
> > > > > > > >   Addressed review comments and handled the burst allocation
> > > > > > > >   by defining 'bursts_max' as per suggestions.
> > > > > > > >
> > > > > > > > Changes in v9
> > > > > > > >   Fixed compilation errors related to macro name mismatch.
> > > > > > > >
> > > > > > > > Changes in v8
> > > > > > > >   Cosmetic change related to comment and code.
> > > > > > > >
> > > > > > > > Changes in v7
> > > > > > > >   No change
> > > > > > > >
> > > > > > > > Changes in v6
> > > > > > > >   Gave definition to bits used for channel configuration.
> > > > > > > >   Removed the comment related to doorbell.
> > > > > > > >
> > > > > > > > Changes in v5
> > > > > > > >   Variable name 'nollp' changed to 'non_ll'.
> > > > > > > >   In the dw_edma_device_config() WARN_ON replaced with
> > > dev_err().
> > > > > > > >   Comments follow the 80-column guideline.
> > > > > > > >
> > > > > > > > Changes in v4
> > > > > > > >   No change
> > > > > > > >
> > > > > > > > Changes in v3
> > > > > > > >   No change
> > > > > > > >
> > > > > > > > Changes in v2
> > > > > > > >   Reverted the function return type to u64 for
> > > > > > > >   dw_edma_get_phys_addr().
> > > > > > > >
> > > > > > > > Changes in v1
> > > > > > > >   Changed the function return type for
> dw_edma_get_phys_addr().
> > > > > > > >   Corrected the typo raised in review.
> > > > > > > > ---
> > > > > > > >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> > > > > > > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > > > > > > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++----
> --
> > > > > > > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > > > > > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-
> hdma-
> > > v0-
> > > > > > > regs.h |  1 +
> > > > > > > >  include/linux/dma/edma.h              |  1 +
> > > > > > > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > index b43255f914f3..ef3d79a9f88d 100644
> > > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > @@ -223,6 +223,31 @@ static int
> > > > > > > > dw_edma_device_config(struct
> > > > > > > dma_chan *dchan,
> > > > > > > >                                struct dma_slave_config *config)  {
> > > > > > > >       struct dw_edma_chan *chan =
> > > > > > > > dchan2dw_edma_chan(dchan);
> > > > > > > > +     int non_ll = 0;
> > > > > > > > +
> > > > > > > > +     chan->non_ll = false;
> > > > > > > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> > > > > > >
> > > > > > > Need handle EMDA case. if mf is EDMA, need return error when
> > > > > > > config->peripheral_config is not NULL. Or remove above check
> > > > > > > config->to make
> > > > > > > code work for both EDMA or HDMA.
> > > > > > >
> > > > > >
> > > > > > For the case of EDMA, the behavior is unchanged.
> > > > > > Even if the config->peripheral_config param is set then it
> > > > > > would be simply
> > > > > ignored.
> > > > > > This is retention of the previous behavior. This is done
> > > > > > because device_slave_config has other params which affect the
> > > > > > behavior of the DMA transactions, we do not check all those
> > > > > > params and return any error. The error is returned only in the
> > > > > > cases where particular parameter from dma_slave_config is used
> > > > > > and if the parameter is not as expected or in the expected
> > > > > > form. The parameter used from dma_slave_config for the
> > > > > > particular IP type need to be known first then it
> > > > > can be checked for its correctness. This is behavior for the
> > > > > peripheral_config which is used for HDMA and thus error checked.
> > > > >
> > > > > It actaully hidden error. Your patch provide an option, which
> > > > > need't ll memory to do DMA transfer. DMA consumer actaully don't
> > > > > know which backend used, which is private information by DMA
> engine providor.
> > > > >
> > > > > dw-edma-pcie.c is only one of all edma users, which know DMA
> > > > > engine's information because it creates this interface.
> > > > >
> > > > > PCIE-EP framework also create dmaegine, PCIE-EP function driver
> > > > > use DMA standard interface to get dma-chan.
> > > > >
> > > > > if (config->peripheral_config) { /* only your specific dma
> > > > > consumer set it now */
> > > > >         /* optional config information */
> > > > >         if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
> > > > >                 dev_err("edma have not implmentent no-lll mode\n")
> > > > >                 return -EINVAL
> > > > >         }
> > > > >
> > > > >         ...
> > > > > }
> > > > >
> > > > > Add EDMA support no-ll mode is quite easily in future.
> > > > >
> > > >
> > > > This looks reasonable provided that HDMA got the support for this
> param.
> > > > An error check can be added in the next revision.
> > > > The addition may be slightly different as following:
> > > > If (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) { ...
> > > > } else if (config->peripheral_config) {
> > > >  /* error handling */
> > > > }
> > > >
> > > > Using the above, if support needs to be added to EDMA then a check
> > > > for
> > > correct 'mf'
> > > > in the if() shall be sufficient.
> > > >
> > > > > >
> > > > > > > > +             if (config->peripheral_config &&
> > > > > > > > +                 config->peripheral_size != sizeof(int)) {
> > > > > > > > +                     dev_err(dchan->device->dev,
> > > > > > > > +                             "config param peripheral size mismatch\n");
> > > > > > > > +                     return -EINVAL;
> > > > > > > > +             }
> > > > > > > > +
> > > > > > > > +             /*
> > > > > > > > +              * When there is no valid LLP base address
> > > > > > > > + available then
> > > the
> > > > > > > > +              * default DMA ops will use the non-LL mode.
> > > > > > > > +              *
> > > > > > > > +              * Cases where LL mode is enabled and client
> > > > > > > > + wants to use
> > > the
> > > > > > > > +              * non-LL mode then also client can do so via providing
> the
> > > > > > > > +              * peripheral_config param.
> > > > > > > > +              */
> > > > > > > > +             if (config->peripheral_config)
> > > > > > > > +                     non_ll = *(int
> > > > > > > > + *)config->peripheral_config;
> > > > > > > > +
> > > > > > > > +             if (chan->dw->chip->non_ll ||
> > > > > > > > + (!chan->dw->chip->non_ll && non_ll))
> > > > > > >
> > > > > > > if chan->dw->chip->non_ll is true, It should return error if
> > > > > > > you set non_ll false because no LLP base available.
> > > > > > >
> > > > > >
> > > > > > In case the 'chan->dw->chip->non_ll' is true, then the default
> > > > > >mode  becomes non-LL for HDMA ONLY. There is no option to the
> > > > > >user to  configure the LL mode by giving 'non_ll = false' as
> > > > > >part of the
> > > > > >config- peripheral_config.
> > > > >
> > > > > This is API's callback, you can't assume caller do all correct things.
> > > > >
> > > > > > The configuration of default non-LL mode depends on how the IP
> > > > > > is programmed by the user. The user is aware of the IP configuration.
> > > > >
> > > > > It is not true. DMA consumer don't know such detail information,
> > > > > which only know which dma engineer providor.
> > > > >
> > > >
> > > > For the DMA consumer the only option is LL mode as default mode.
> > > > In order to use the non-LL mode it need to provide the parameter
> > > > in the form
> > > of peripheral_config.
> > > > Given the above statement, the consumer even if gives the 'non_ll
> > > > = false', it is not going to change any behavior.
> > > > Even if the user is not giving the option the assumption is that
> > > > controller is in LL mode, unless the DMA engine provider provides
> > > > the information regarding non-LL mode as default mode to the DMA
> > > > consumer
> > > explicitly.
> > > > In the case where chan->dw->chip->non_ll = true, following case
> > > > may
> > > happen:
> > > > - DMA consumer provides no peripheral_config param or simply
> > > >config- peripheral_config = NULL,
> > > >    in this case non_ll = false which is the current flow.
> > > > - DMA consumer provides a valid peripheral_config (!= NULL) param
> > > >but the
> > > value is '0', in this case
> > > >   It is explicit but it would have the same effect as above case.
> > > >
> > > > DMA consumer is supposed to provide the only option non_ll as it
> > > > was not available and LL mode is set as default for the DMA operations.
> > > > When 'chan->dw->chip->non_ll = true' then this was added to make
> > > > the chip usable when the LLP base addresses are not configured.
> > > > Without this, user cannot use any of the modes be it LL or non-LL
> > > > if the LLP base
> > > address is not configured.
> > >
> > > little bit confuse, Maybe the same as you. I expected behavor
> > >
> > > config->peripheral_config = NULL        choose hardware default one
> > >                                         -           LL mode if hardware support
> > >                                         -      none-LL mode if not ll list region
> > >
> > > config->peripheral_config != NULL
> > > EDMA: return false
> > > HDMA:
> > >                 0                       force to none_ll mode. (always success)
> > >                 1                       force back to ll mode  (return false if no ll list region
> in
> > > chip)
> > >
> > > DMA consumer decide if fall back to none_ll to continue.
> > >
> >
> > Thank you for the elaboration!
> > I have few questions, why shall a DMA consumer decide to enable LL
> > mode when the default mode supported is LL mode only?
>
> LL mode only is software driver implement. Hardware support both LL mode
> and no-LL mode. Previous driver implement only support LL mode. You try to
> add non-LL mode. Choose straightforward forward method.
>
> One indicate hardware capacity,  one actually used. Like PCI INTX and MSI.
> If support MSI, most case use MSI. But still support switch to use INTX.
>
> My key point avoid hidden beavior. Every branch is clean and straightforward.
>
> >
> > If DMA consumer is trying to enable the LL mode, then one must be
> > knowing the configuration of the controller that controller is working
> > in non-LL mode, as LLP base address is not configured,then why to try and
> enable the LL mode?
>
> The DMA consumer don't know these informaiton.
>
> >
> > The user need to know, at least, one detail from the above two cases.
> >
> > The use for non-LL mode is useful in the following scenario:
> > - When user want to utilize the LL regions also for DMA data transfers.
> > - For single and big chunks non-LL mode is useful in both use-cases when
> non-LL mode is default or
> >   user enables it via peripheral_config params.
> > - This addition, inadvertently, makes the DMA controller usable, for AMD
> (Xilinx) only, when the LLP
> >   base addresses are not configured; it can be used in non-LL mode.
>
> LL regions may not visiable,  User can use non-ll to config LL-region and switch
> back to use LL-region to continue transfer. User may use non-ll as indirectly
> reg access.
>
> > For Synopsys, DMA controller
> >   cannot be used in any mode if LLP base address is not configured.
>
> Does spec said it? It doesn't make sense. it should be controlled by LLE of
> DMA_CH_CONTROL1_OFF_RDCH_0.
>
> >
> > Based on the above points, if user is trying to enable LL mode when
> > default mode is LL mode, it looks Intentionally making the choice when user
> is aware of the mode DMA controller operating in.
> > Please let me know if this clarifies the doubt.
>
> No API to get mode, only use set and test to know it.
>
> Actually Needn't consider so complex. like functions API(x)
>
> We just consider input x,
>
>         validate x's input ragion,
>
>         if x is out of region, just return error.
>

Thanks! Will update in the next version.

> >
> > > >
> > > > > > The check for non-LL option
> > > > > > provided by the user is useful when LL-mode is default. That
> > > > > > is why the value of non_ll == false is not even evaluated.
> > > > > >
> > > > > > > > +                     chan->non_ll = true;
> > > > > > > > +     }
> > > > > > > >
> > > > > ...
> > > > > > > > diff --git a/include/linux/dma/edma.h
> > > > > > > > b/include/linux/dma/edma.h index
> > > > > > > > 3080747689f6..78ce31b049ae
> > > > > > > > 100644
> > > > > > > > --- a/include/linux/dma/edma.h
> > > > > > > > +++ b/include/linux/dma/edma.h
> > > > > > > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > > > > > > >       enum dw_edma_map_format mf;
> > > > > > > >
> > > > > > > >       struct dw_edma          *dw;
> > > > > > > > +     bool                    non_ll;
> > > > > > >
> > > > > > > Can you check ll_region directly? it should be equal to
> > > > > > > (ll_region->sz == 0)
> > > > > ?
> > > > >
> > > > > Do you miss this questin?
> > > > >
> > > > > Frank
> > > > >
> > > >
> > > > Yes, looks like I missed this question. Could you explain a little
> > > > bit more? I
> > > am unable to understand the context.
> > >
> > > you set chip->non_ll = non_ll in dw_edma_pcie_probe()
> > >
> > > and only set ll_region->sz = ll_block->sz when !chip->non_ll.
> > >
> > > Thats means ll_region->sz is 0 when chip->non_ll is true.
> > >
> > > So non_ll have not bring new infomation into dw_edma_chip.
> > >
> > > check !ll_region->sz, which should be equal to this non_ll.
> > >
> > > dw_edma_chip is the exchange information between controller and dma
> > > core driver. Needn't cache it here because you already save a copy in dma-
> chan.
> > >
> > > Frank
> >
> > I understand the concern here but it does not look good to piggyback
> > the non_ll related information on the existing variable.
> > The use of bool readily points out the information related to what
> > mode is being intended but using the ll_region->sz is an inference the user
> has to make.
> >
> > Having ll_region->sz == 0 does not really tell it is non_ll mode or
> > not, it can also mean that the size of LL region is zero while in LL mode
> which could be an error.
> > This does not translate to support for non-LL mode. This brings the
> ambiguity.
> > The introduction of the non_ll provides clarity and easy comparison
> > with the similar choice (non_ll) provided by the DMA consumer in the
> dmaengine_slave_config().
> > I request we shall retain the clarity here.
>
> You can use helper(dw_chip_is_support_ll()) macro to check chip's
> capatiblity.
>

I do not understand what you mean with the above statement.
But if it about writing a new function to check the LL mode support
then I think the current variable is good enough which provides good readability
and do not create any ambiguity compared to the ll region size comparison.

> Frank
> >
> > > >
> > > > > > >
> > > > > > > Frank
> > > > > > > >  };
> > > > > > > >
> > > > > > > >  /* Export to the platform drivers */
> > > > > > > > --
> > > > > > > > 2.43.0
> > > > > > > >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Fri, Feb 20, 2026 at 11:47:59AM +0000, Verma, Devendra wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hi Frank
> Please check my response inline
>
> Regards,
> Devendra
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Thursday, February 19, 2026 10:38 PM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
>
> ---[ Snipped some text to reduce mail size ]---
>
> > > > > > > > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma
> > wrote:
> > > > > > > > > AMD MDB IP supports Linked List (LL) mode as well as non-LL
> > mode.
> > > > > > > > > The current code does not have the mechanisms to enable
> > > > > > > > > the DMA transactions using the non-LL mode. The following
> > > > > > > > > two cases are added with this patch:
> > > > > > > > > - For the AMD (Xilinx) only, when a valid physical base address of
> > > > > > > > >   the device side DDR is not configured, then the IP can still be
> > > > > > > > >   used in non-LL mode. For all the channels DMA transactions will
> > > > > > > > >   be using the non-LL mode only. This, the default non-LL mode,
> > > > > > > > >   is not applicable for Synopsys IP with the current code addition.
> > > > > > > > >
> > > > > > > > > - If the default mode is LL-mode, for both AMD (Xilinx) and
> > Synosys,
> > > > > > > > >   and if user wants to use non-LL mode then user can do so via
> > > > > > > > >   configuring the peripheral_config param of dma_slave_config.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Devendra K Verma <devendra.verma@amd.com>
> > > > > > > > > ---
> > > > > > > > > Changes in v10
> > > > > > > > >   Added the peripheral_config check only for HDMA IP in
> > > > > > > > >   dw_edma_device_config().
> > > > > > > > >   Replaced the loop with single entry retrieval for non-LL
> > > > > > > > >   mode.
> > > > > > > > >   Addressed review comments and handled the burst allocation
> > > > > > > > >   by defining 'bursts_max' as per suggestions.
> > > > > > > > >
> > > > > > > > > Changes in v9
> > > > > > > > >   Fixed compilation errors related to macro name mismatch.
> > > > > > > > >
> > > > > > > > > Changes in v8
> > > > > > > > >   Cosmetic change related to comment and code.
> > > > > > > > >
> > > > > > > > > Changes in v7
> > > > > > > > >   No change
> > > > > > > > >
> > > > > > > > > Changes in v6
> > > > > > > > >   Gave definition to bits used for channel configuration.
> > > > > > > > >   Removed the comment related to doorbell.
> > > > > > > > >
> > > > > > > > > Changes in v5
> > > > > > > > >   Variable name 'nollp' changed to 'non_ll'.
> > > > > > > > >   In the dw_edma_device_config() WARN_ON replaced with
> > > > dev_err().
> > > > > > > > >   Comments follow the 80-column guideline.
> > > > > > > > >
> > > > > > > > > Changes in v4
> > > > > > > > >   No change
> > > > > > > > >
> > > > > > > > > Changes in v3
> > > > > > > > >   No change
> > > > > > > > >
> > > > > > > > > Changes in v2
> > > > > > > > >   Reverted the function return type to u64 for
> > > > > > > > >   dw_edma_get_phys_addr().
> > > > > > > > >
> > > > > > > > > Changes in v1
> > > > > > > > >   Changed the function return type for
> > dw_edma_get_phys_addr().
> > > > > > > > >   Corrected the typo raised in review.
> > > > > > > > > ---
> > > > > > > > >  drivers/dma/dw-edma/dw-edma-core.c    | 35 ++++++++++++++-
> > > > > > > > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > > > > > > > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44 ++++++++++++----
> > --
> > > > > > > > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > > > > > > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-
> > hdma-
> > > > v0-
> > > > > > > > regs.h |  1 +
> > > > > > > > >  include/linux/dma/edma.h              |  1 +
> > > > > > > > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > index b43255f914f3..ef3d79a9f88d 100644
> > > > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > @@ -223,6 +223,31 @@ static int
> > > > > > > > > dw_edma_device_config(struct
> > > > > > > > dma_chan *dchan,
> > > > > > > > >                                struct dma_slave_config *config)  {
> > > > > > > > >       struct dw_edma_chan *chan =
> > > > > > > > > dchan2dw_edma_chan(dchan);
> > > > > > > > > +     int non_ll = 0;
> > > > > > > > > +
> > > > > > > > > +     chan->non_ll = false;
> > > > > > > > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> > > > > > > >
> > > > > > > > Need handle EMDA case. if mf is EDMA, need return error when
> > > > > > > > config->peripheral_config is not NULL. Or remove above check
> > > > > > > > config->to make
> > > > > > > > code work for both EDMA or HDMA.
> > > > > > > >
> > > > > > >
> > > > > > > For the case of EDMA, the behavior is unchanged.
> > > > > > > Even if the config->peripheral_config param is set then it
> > > > > > > would be simply
> > > > > > ignored.
> > > > > > > This is retention of the previous behavior. This is done
> > > > > > > because device_slave_config has other params which affect the
> > > > > > > behavior of the DMA transactions, we do not check all those
> > > > > > > params and return any error. The error is returned only in the
> > > > > > > cases where particular parameter from dma_slave_config is used
> > > > > > > and if the parameter is not as expected or in the expected
> > > > > > > form. The parameter used from dma_slave_config for the
> > > > > > > particular IP type need to be known first then it
> > > > > > can be checked for its correctness. This is behavior for the
> > > > > > peripheral_config which is used for HDMA and thus error checked.
> > > > > >
> > > > > > It actaully hidden error. Your patch provide an option, which
> > > > > > need't ll memory to do DMA transfer. DMA consumer actaully don't
> > > > > > know which backend used, which is private information by DMA
> > engine providor.
> > > > > >
> > > > > > dw-edma-pcie.c is only one of all edma users, which know DMA
> > > > > > engine's information because it creates this interface.
> > > > > >
> > > > > > PCIE-EP framework also create dmaegine, PCIE-EP function driver
> > > > > > use DMA standard interface to get dma-chan.
> > > > > >
> > > > > > if (config->peripheral_config) { /* only your specific dma
> > > > > > consumer set it now */
> > > > > >         /* optional config information */
> > > > > >         if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
> > > > > >                 dev_err("edma have not implmentent no-lll mode\n")
> > > > > >                 return -EINVAL
> > > > > >         }
> > > > > >
> > > > > >         ...
> > > > > > }
> > > > > >
> > > > > > Add EDMA support no-ll mode is quite easily in future.
> > > > > >
> > > > >
> > > > > This looks reasonable provided that HDMA got the support for this
> > param.
> > > > > An error check can be added in the next revision.
> > > > > The addition may be slightly different as following:
> > > > > If (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) { ...
> > > > > } else if (config->peripheral_config) {
> > > > >  /* error handling */
> > > > > }
> > > > >
> > > > > Using the above, if support needs to be added to EDMA then a check
> > > > > for
> > > > correct 'mf'
> > > > > in the if() shall be sufficient.
> > > > >
> > > > > > >
> > > > > > > > > +             if (config->peripheral_config &&
> > > > > > > > > +                 config->peripheral_size != sizeof(int)) {
> > > > > > > > > +                     dev_err(dchan->device->dev,
> > > > > > > > > +                             "config param peripheral size mismatch\n");
> > > > > > > > > +                     return -EINVAL;
> > > > > > > > > +             }
> > > > > > > > > +
> > > > > > > > > +             /*
> > > > > > > > > +              * When there is no valid LLP base address
> > > > > > > > > + available then
> > > > the
> > > > > > > > > +              * default DMA ops will use the non-LL mode.
> > > > > > > > > +              *
> > > > > > > > > +              * Cases where LL mode is enabled and client
> > > > > > > > > + wants to use
> > > > the
> > > > > > > > > +              * non-LL mode then also client can do so via providing
> > the
> > > > > > > > > +              * peripheral_config param.
> > > > > > > > > +              */
> > > > > > > > > +             if (config->peripheral_config)
> > > > > > > > > +                     non_ll = *(int
> > > > > > > > > + *)config->peripheral_config;
> > > > > > > > > +
> > > > > > > > > +             if (chan->dw->chip->non_ll ||
> > > > > > > > > + (!chan->dw->chip->non_ll && non_ll))
> > > > > > > >
> > > > > > > > if chan->dw->chip->non_ll is true, It should return error if
> > > > > > > > you set non_ll false because no LLP base available.
> > > > > > > >
> > > > > > >
> > > > > > > In case the 'chan->dw->chip->non_ll' is true, then the default
> > > > > > >mode  becomes non-LL for HDMA ONLY. There is no option to the
> > > > > > >user to  configure the LL mode by giving 'non_ll = false' as
> > > > > > >part of the
> > > > > > >config- peripheral_config.
> > > > > >
> > > > > > This is API's callback, you can't assume caller do all correct things.
> > > > > >
> > > > > > > The configuration of default non-LL mode depends on how the IP
> > > > > > > is programmed by the user. The user is aware of the IP configuration.
> > > > > >
> > > > > > It is not true. DMA consumer don't know such detail information,
> > > > > > which only know which dma engineer providor.
> > > > > >
> > > > >
> > > > > For the DMA consumer the only option is LL mode as default mode.
> > > > > In order to use the non-LL mode it need to provide the parameter
> > > > > in the form
> > > > of peripheral_config.
> > > > > Given the above statement, the consumer even if gives the 'non_ll
> > > > > = false', it is not going to change any behavior.
> > > > > Even if the user is not giving the option the assumption is that
> > > > > controller is in LL mode, unless the DMA engine provider provides
> > > > > the information regarding non-LL mode as default mode to the DMA
> > > > > consumer
> > > > explicitly.
> > > > > In the case where chan->dw->chip->non_ll = true, following case
> > > > > may
> > > > happen:
> > > > > - DMA consumer provides no peripheral_config param or simply
> > > > >config- peripheral_config = NULL,
> > > > >    in this case non_ll = false which is the current flow.
> > > > > - DMA consumer provides a valid peripheral_config (!= NULL) param
> > > > >but the
> > > > value is '0', in this case
> > > > >   It is explicit but it would have the same effect as above case.
> > > > >
> > > > > DMA consumer is supposed to provide the only option non_ll as it
> > > > > was not available and LL mode is set as default for the DMA operations.
> > > > > When 'chan->dw->chip->non_ll = true' then this was added to make
> > > > > the chip usable when the LLP base addresses are not configured.
> > > > > Without this, user cannot use any of the modes be it LL or non-LL
> > > > > if the LLP base
> > > > address is not configured.
> > > >
> > > > little bit confuse, Maybe the same as you. I expected behavor
> > > >
> > > > config->peripheral_config = NULL        choose hardware default one
> > > >                                         -           LL mode if hardware support
> > > >                                         -      none-LL mode if not ll list region
> > > >
> > > > config->peripheral_config != NULL
> > > > EDMA: return false
> > > > HDMA:
> > > >                 0                       force to none_ll mode. (always success)
> > > >                 1                       force back to ll mode  (return false if no ll list region
> > in
> > > > chip)
> > > >
> > > > DMA consumer decide if fall back to none_ll to continue.
> > > >
> > >
> > > Thank you for the elaboration!
> > > I have few questions, why shall a DMA consumer decide to enable LL
> > > mode when the default mode supported is LL mode only?
> >
> > LL mode only is software driver implement. Hardware support both LL mode
> > and no-LL mode. Previous driver implement only support LL mode. You try to
> > add non-LL mode. Choose straightforward forward method.
> >
> > One indicate hardware capacity,  one actually used. Like PCI INTX and MSI.
> > If support MSI, most case use MSI. But still support switch to use INTX.
> >
> > My key point avoid hidden beavior. Every branch is clean and straightforward.
> >
> > >
> > > If DMA consumer is trying to enable the LL mode, then one must be
> > > knowing the configuration of the controller that controller is working
> > > in non-LL mode, as LLP base address is not configured,then why to try and
> > enable the LL mode?
> >
> > The DMA consumer don't know these informaiton.
> >
> > >
> > > The user need to know, at least, one detail from the above two cases.
> > >
> > > The use for non-LL mode is useful in the following scenario:
> > > - When user want to utilize the LL regions also for DMA data transfers.
> > > - For single and big chunks non-LL mode is useful in both use-cases when
> > non-LL mode is default or
> > >   user enables it via peripheral_config params.
> > > - This addition, inadvertently, makes the DMA controller usable, for AMD
> > (Xilinx) only, when the LLP
> > >   base addresses are not configured; it can be used in non-LL mode.
> >
> > LL regions may not visiable,  User can use non-ll to config LL-region and switch
> > back to use LL-region to continue transfer. User may use non-ll as indirectly
> > reg access.
> >
> > > For Synopsys, DMA controller
> > >   cannot be used in any mode if LLP base address is not configured.
> >
> > Does spec said it? It doesn't make sense. it should be controlled by LLE of
> > DMA_CH_CONTROL1_OFF_RDCH_0.
> >
> > >
> > > Based on the above points, if user is trying to enable LL mode when
> > > default mode is LL mode, it looks Intentionally making the choice when user
> > is aware of the mode DMA controller operating in.
> > > Please let me know if this clarifies the doubt.
> >
> > No API to get mode, only use set and test to know it.
> >
> > Actually Needn't consider so complex. like functions API(x)
> >
> > We just consider input x,
> >
> >         validate x's input ragion,
> >
> >         if x is out of region, just return error.
> >
>
> Thanks! Will update in the next version.
>
> > >
> > > > >
> > > > > > > The check for non-LL option
> > > > > > > provided by the user is useful when LL-mode is default. That
> > > > > > > is why the value of non_ll == false is not even evaluated.
> > > > > > >
> > > > > > > > > +                     chan->non_ll = true;
> > > > > > > > > +     }
> > > > > > > > >
> > > > > > ...
> > > > > > > > > diff --git a/include/linux/dma/edma.h
> > > > > > > > > b/include/linux/dma/edma.h index
> > > > > > > > > 3080747689f6..78ce31b049ae
> > > > > > > > > 100644
> > > > > > > > > --- a/include/linux/dma/edma.h
> > > > > > > > > +++ b/include/linux/dma/edma.h
> > > > > > > > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > > > > > > > >       enum dw_edma_map_format mf;
> > > > > > > > >
> > > > > > > > >       struct dw_edma          *dw;
> > > > > > > > > +     bool                    non_ll;
> > > > > > > >
> > > > > > > > Can you check ll_region directly? it should be equal to
> > > > > > > > (ll_region->sz == 0)
> > > > > > ?
> > > > > >
> > > > > > Do you miss this questin?
> > > > > >
> > > > > > Frank
> > > > > >
> > > > >
> > > > > Yes, looks like I missed this question. Could you explain a little
> > > > > bit more? I
> > > > am unable to understand the context.
> > > >
> > > > you set chip->non_ll = non_ll in dw_edma_pcie_probe()
> > > >
> > > > and only set ll_region->sz = ll_block->sz when !chip->non_ll.
> > > >
> > > > Thats means ll_region->sz is 0 when chip->non_ll is true.
> > > >
> > > > So non_ll have not bring new infomation into dw_edma_chip.
> > > >
> > > > check !ll_region->sz, which should be equal to this non_ll.
> > > >
> > > > dw_edma_chip is the exchange information between controller and dma
> > > > core driver. Needn't cache it here because you already save a copy in dma-
> > chan.
> > > >
> > > > Frank
> > >
> > > I understand the concern here but it does not look good to piggyback
> > > the non_ll related information on the existing variable.
> > > The use of bool readily points out the information related to what
> > > mode is being intended but using the ll_region->sz is an inference the user
> > has to make.
> > >
> > > Having ll_region->sz == 0 does not really tell it is non_ll mode or
> > > not, it can also mean that the size of LL region is zero while in LL mode
> > which could be an error.
> > > This does not translate to support for non-LL mode. This brings the
> > ambiguity.
> > > The introduction of the non_ll provides clarity and easy comparison
> > > with the similar choice (non_ll) provided by the DMA consumer in the
> > dmaengine_slave_config().
> > > I request we shall retain the clarity here.
> >
> > You can use helper(dw_chip_is_support_ll()) macro to check chip's
> > capatiblity.
> >
>
> I do not understand what you mean with the above statement.
> But if it about writing a new function to check the LL mode support
> then I think the current variable is good enough which provides good readability
> and do not create any ambiguity compared to the ll region size comparison.

It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip. So we add
more cap flags in future.

Frank

>
> > Frank
> > >
> > > > >
> > > > > > > >
> > > > > > > > Frank
> > > > > > > > >  };
> > > > > > > > >
> > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > --
> > > > > > > > > 2.43.0
> > > > > > > > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Friday, February 20, 2026 9:33 PM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Fri, Feb 20, 2026 at 11:47:59AM +0000, Verma, Devendra wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > Hi Frank
> > Please check my response inline
> >
> > Regards,
> > Devendra
> > > -----Original Message-----
> > > From: Frank Li <Frank.li@nxp.com>
> > > Sent: Thursday, February 19, 2026 10:38 PM
> > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > > mode
> >
> > ---[ Snipped some text to reduce mail size ]---
> >
> > > > > > > > > On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K
> > > > > > > > > Verma
> > > wrote:
> > > > > > > > > > AMD MDB IP supports Linked List (LL) mode as well as
> > > > > > > > > > non-LL
> > > mode.
> > > > > > > > > > The current code does not have the mechanisms to
> > > > > > > > > > enable the DMA transactions using the non-LL mode. The
> > > > > > > > > > following two cases are added with this patch:
> > > > > > > > > > - For the AMD (Xilinx) only, when a valid physical base
> address of
> > > > > > > > > >   the device side DDR is not configured, then the IP can still be
> > > > > > > > > >   used in non-LL mode. For all the channels DMA transactions
> will
> > > > > > > > > >   be using the non-LL mode only. This, the default non-LL
> mode,
> > > > > > > > > >   is not applicable for Synopsys IP with the current code
> addition.
> > > > > > > > > >
> > > > > > > > > > - If the default mode is LL-mode, for both AMD
> > > > > > > > > > (Xilinx) and
> > > Synosys,
> > > > > > > > > >   and if user wants to use non-LL mode then user can do so
> via
> > > > > > > > > >   configuring the peripheral_config param of
> dma_slave_config.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Devendra K Verma
> > > > > > > > > > <devendra.verma@amd.com>
> > > > > > > > > > ---
> > > > > > > > > > Changes in v10
> > > > > > > > > >   Added the peripheral_config check only for HDMA IP in
> > > > > > > > > >   dw_edma_device_config().
> > > > > > > > > >   Replaced the loop with single entry retrieval for non-LL
> > > > > > > > > >   mode.
> > > > > > > > > >   Addressed review comments and handled the burst
> allocation
> > > > > > > > > >   by defining 'bursts_max' as per suggestions.
> > > > > > > > > >
> > > > > > > > > > Changes in v9
> > > > > > > > > >   Fixed compilation errors related to macro name mismatch.
> > > > > > > > > >
> > > > > > > > > > Changes in v8
> > > > > > > > > >   Cosmetic change related to comment and code.
> > > > > > > > > >
> > > > > > > > > > Changes in v7
> > > > > > > > > >   No change
> > > > > > > > > >
> > > > > > > > > > Changes in v6
> > > > > > > > > >   Gave definition to bits used for channel configuration.
> > > > > > > > > >   Removed the comment related to doorbell.
> > > > > > > > > >
> > > > > > > > > > Changes in v5
> > > > > > > > > >   Variable name 'nollp' changed to 'non_ll'.
> > > > > > > > > >   In the dw_edma_device_config() WARN_ON replaced with
> > > > > dev_err().
> > > > > > > > > >   Comments follow the 80-column guideline.
> > > > > > > > > >
> > > > > > > > > > Changes in v4
> > > > > > > > > >   No change
> > > > > > > > > >
> > > > > > > > > > Changes in v3
> > > > > > > > > >   No change
> > > > > > > > > >
> > > > > > > > > > Changes in v2
> > > > > > > > > >   Reverted the function return type to u64 for
> > > > > > > > > >   dw_edma_get_phys_addr().
> > > > > > > > > >
> > > > > > > > > > Changes in v1
> > > > > > > > > >   Changed the function return type for
> > > dw_edma_get_phys_addr().
> > > > > > > > > >   Corrected the typo raised in review.
> > > > > > > > > > ---
> > > > > > > > > >  drivers/dma/dw-edma/dw-edma-core.c    | 35
> ++++++++++++++-
> > > > > > > > > >  drivers/dma/dw-edma/dw-edma-core.h    |  1 +
> > > > > > > > > >  drivers/dma/dw-edma/dw-edma-pcie.c    | 44
> ++++++++++++----
> > > --
> > > > > > > > > >  drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
> > > > > > > > > > ++++++++++++++++++++++++++-  drivers/dma/dw-edma/dw-
> > > hdma-
> > > > > v0-
> > > > > > > > > regs.h |  1 +
> > > > > > > > > >  include/linux/dma/edma.h              |  1 +
> > > > > > > > > >  6 files changed, 132 insertions(+), 15 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > > b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > > index b43255f914f3..ef3d79a9f88d 100644
> > > > > > > > > > --- a/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-core.c
> > > > > > > > > > @@ -223,6 +223,31 @@ static int
> > > > > > > > > > dw_edma_device_config(struct
> > > > > > > > > dma_chan *dchan,
> > > > > > > > > >                                struct dma_slave_config *config)  {
> > > > > > > > > >       struct dw_edma_chan *chan =
> > > > > > > > > > dchan2dw_edma_chan(dchan);
> > > > > > > > > > +     int non_ll = 0;
> > > > > > > > > > +
> > > > > > > > > > +     chan->non_ll = false;
> > > > > > > > > > +     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
> > > > > > > > >
> > > > > > > > > Need handle EMDA case. if mf is EDMA, need return error
> > > > > > > > > when
> > > > > > > > > config->peripheral_config is not NULL. Or remove above
> > > > > > > > > config->check to make
> > > > > > > > > code work for both EDMA or HDMA.
> > > > > > > > >
> > > > > > > >
> > > > > > > > For the case of EDMA, the behavior is unchanged.
> > > > > > > > Even if the config->peripheral_config param is set then it
> > > > > > > > would be simply
> > > > > > > ignored.
> > > > > > > > This is retention of the previous behavior. This is done
> > > > > > > > because device_slave_config has other params which affect
> > > > > > > > the behavior of the DMA transactions, we do not check all
> > > > > > > > those params and return any error. The error is returned
> > > > > > > > only in the cases where particular parameter from
> > > > > > > > dma_slave_config is used and if the parameter is not as
> > > > > > > > expected or in the expected form. The parameter used from
> > > > > > > > dma_slave_config for the particular IP type need to be
> > > > > > > > known first then it
> > > > > > > can be checked for its correctness. This is behavior for the
> > > > > > > peripheral_config which is used for HDMA and thus error checked.
> > > > > > >
> > > > > > > It actaully hidden error. Your patch provide an option,
> > > > > > > which need't ll memory to do DMA transfer. DMA consumer
> > > > > > > actaully don't know which backend used, which is private
> > > > > > > information by DMA
> > > engine providor.
> > > > > > >
> > > > > > > dw-edma-pcie.c is only one of all edma users, which know DMA
> > > > > > > engine's information because it creates this interface.
> > > > > > >
> > > > > > > PCIE-EP framework also create dmaegine, PCIE-EP function
> > > > > > > driver use DMA standard interface to get dma-chan.
> > > > > > >
> > > > > > > if (config->peripheral_config) { /* only your specific dma
> > > > > > > consumer set it now */
> > > > > > >         /* optional config information */
> > > > > > >         if (chan->dw->chip->mf != EDMA_MF_HDMA_NATIVE) {
> > > > > > >                 dev_err("edma have not implmentent no-lll mode\n")
> > > > > > >                 return -EINVAL
> > > > > > >         }
> > > > > > >
> > > > > > >         ...
> > > > > > > }
> > > > > > >
> > > > > > > Add EDMA support no-ll mode is quite easily in future.
> > > > > > >
> > > > > >
> > > > > > This looks reasonable provided that HDMA got the support for
> > > > > > this
> > > param.
> > > > > > An error check can be added in the next revision.
> > > > > > The addition may be slightly different as following:
> > > > > > If (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) { ...
> > > > > > } else if (config->peripheral_config) {
> > > > > >  /* error handling */
> > > > > > }
> > > > > >
> > > > > > Using the above, if support needs to be added to EDMA then a
> > > > > > check for
> > > > > correct 'mf'
> > > > > > in the if() shall be sufficient.
> > > > > >
> > > > > > > >
> > > > > > > > > > +             if (config->peripheral_config &&
> > > > > > > > > > +                 config->peripheral_size != sizeof(int)) {
> > > > > > > > > > +                     dev_err(dchan->device->dev,
> > > > > > > > > > +                             "config param peripheral size mismatch\n");
> > > > > > > > > > +                     return -EINVAL;
> > > > > > > > > > +             }
> > > > > > > > > > +
> > > > > > > > > > +             /*
> > > > > > > > > > +              * When there is no valid LLP base
> > > > > > > > > > + address available then
> > > > > the
> > > > > > > > > > +              * default DMA ops will use the non-LL mode.
> > > > > > > > > > +              *
> > > > > > > > > > +              * Cases where LL mode is enabled and
> > > > > > > > > > + client wants to use
> > > > > the
> > > > > > > > > > +              * non-LL mode then also client can do
> > > > > > > > > > + so via providing
> > > the
> > > > > > > > > > +              * peripheral_config param.
> > > > > > > > > > +              */
> > > > > > > > > > +             if (config->peripheral_config)
> > > > > > > > > > +                     non_ll = *(int
> > > > > > > > > > + *)config->peripheral_config;
> > > > > > > > > > +
> > > > > > > > > > +             if (chan->dw->chip->non_ll ||
> > > > > > > > > > + (!chan->dw->chip->non_ll && non_ll))
> > > > > > > > >
> > > > > > > > > if chan->dw->chip->non_ll is true, It should return
> > > > > > > > > error if you set non_ll false because no LLP base available.
> > > > > > > > >
> > > > > > > >
> > > > > > > > In case the 'chan->dw->chip->non_ll' is true, then the
> > > > > > > >default mode  becomes non-LL for HDMA ONLY. There is no
> > > > > > > >option to the user to  configure the LL mode by giving
> > > > > > > >'non_ll = false' as part of the
> > > > > > > >config- peripheral_config.
> > > > > > >
> > > > > > > This is API's callback, you can't assume caller do all correct things.
> > > > > > >
> > > > > > > > The configuration of default non-LL mode depends on how
> > > > > > > > the IP is programmed by the user. The user is aware of the IP
> configuration.
> > > > > > >
> > > > > > > It is not true. DMA consumer don't know such detail
> > > > > > > information, which only know which dma engineer providor.
> > > > > > >
> > > > > >
> > > > > > For the DMA consumer the only option is LL mode as default mode.
> > > > > > In order to use the non-LL mode it need to provide the
> > > > > > parameter in the form
> > > > > of peripheral_config.
> > > > > > Given the above statement, the consumer even if gives the
> > > > > > 'non_ll = false', it is not going to change any behavior.
> > > > > > Even if the user is not giving the option the assumption is
> > > > > > that controller is in LL mode, unless the DMA engine provider
> > > > > > provides the information regarding non-LL mode as default mode
> > > > > > to the DMA consumer
> > > > > explicitly.
> > > > > > In the case where chan->dw->chip->non_ll = true, following
> > > > > > case may
> > > > > happen:
> > > > > > - DMA consumer provides no peripheral_config param or simply
> > > > > >config- peripheral_config = NULL,
> > > > > >    in this case non_ll = false which is the current flow.
> > > > > > - DMA consumer provides a valid peripheral_config (!= NULL)
> > > > > >param but the
> > > > > value is '0', in this case
> > > > > >   It is explicit but it would have the same effect as above case.
> > > > > >
> > > > > > DMA consumer is supposed to provide the only option non_ll as
> > > > > > it was not available and LL mode is set as default for the DMA
> operations.
> > > > > > When 'chan->dw->chip->non_ll = true' then this was added to
> > > > > > make the chip usable when the LLP base addresses are not
> configured.
> > > > > > Without this, user cannot use any of the modes be it LL or
> > > > > > non-LL if the LLP base
> > > > > address is not configured.
> > > > >
> > > > > little bit confuse, Maybe the same as you. I expected behavor
> > > > >
> > > > > config->peripheral_config = NULL        choose hardware default one
> > > > >                                         -           LL mode if hardware support
> > > > >                                         -      none-LL mode if not ll list region
> > > > >
> > > > > config->peripheral_config != NULL
> > > > > EDMA: return false
> > > > > HDMA:
> > > > >                 0                       force to none_ll mode. (always success)
> > > > >                 1                       force back to ll mode  (return false if no ll list
> region
> > > in
> > > > > chip)
> > > > >
> > > > > DMA consumer decide if fall back to none_ll to continue.
> > > > >
> > > >
> > > > Thank you for the elaboration!
> > > > I have few questions, why shall a DMA consumer decide to enable LL
> > > > mode when the default mode supported is LL mode only?
> > >
> > > LL mode only is software driver implement. Hardware support both LL
> > > mode and no-LL mode. Previous driver implement only support LL mode.
> > > You try to add non-LL mode. Choose straightforward forward method.
> > >
> > > One indicate hardware capacity,  one actually used. Like PCI INTX and MSI.
> > > If support MSI, most case use MSI. But still support switch to use INTX.
> > >
> > > My key point avoid hidden beavior. Every branch is clean and
> straightforward.
> > >
> > > >
> > > > If DMA consumer is trying to enable the LL mode, then one must be
> > > > knowing the configuration of the controller that controller is
> > > > working in non-LL mode, as LLP base address is not configured,then
> > > > why to try and
> > > enable the LL mode?
> > >
> > > The DMA consumer don't know these informaiton.
> > >
> > > >
> > > > The user need to know, at least, one detail from the above two cases.
> > > >
> > > > The use for non-LL mode is useful in the following scenario:
> > > > - When user want to utilize the LL regions also for DMA data transfers.
> > > > - For single and big chunks non-LL mode is useful in both
> > > > use-cases when
> > > non-LL mode is default or
> > > >   user enables it via peripheral_config params.
> > > > - This addition, inadvertently, makes the DMA controller usable,
> > > > for AMD
> > > (Xilinx) only, when the LLP
> > > >   base addresses are not configured; it can be used in non-LL mode.
> > >
> > > LL regions may not visiable,  User can use non-ll to config
> > > LL-region and switch back to use LL-region to continue transfer.
> > > User may use non-ll as indirectly reg access.
> > >
> > > > For Synopsys, DMA controller
> > > >   cannot be used in any mode if LLP base address is not configured.
> > >
> > > Does spec said it? It doesn't make sense. it should be controlled by
> > > LLE of DMA_CH_CONTROL1_OFF_RDCH_0.
> > >
> > > >
> > > > Based on the above points, if user is trying to enable LL mode
> > > > when default mode is LL mode, it looks Intentionally making the
> > > > choice when user
> > > is aware of the mode DMA controller operating in.
> > > > Please let me know if this clarifies the doubt.
> > >
> > > No API to get mode, only use set and test to know it.
> > >
> > > Actually Needn't consider so complex. like functions API(x)
> > >
> > > We just consider input x,
> > >
> > >         validate x's input ragion,
> > >
> > >         if x is out of region, just return error.
> > >
> >
> > Thanks! Will update in the next version.
> >
> > > >
> > > > > >
> > > > > > > > The check for non-LL option provided by the user is useful
> > > > > > > > when LL-mode is default. That is why the value of non_ll
> > > > > > > > == false is not even evaluated.
> > > > > > > >
> > > > > > > > > > +                     chan->non_ll = true;
> > > > > > > > > > +     }
> > > > > > > > > >
> > > > > > > ...
> > > > > > > > > > diff --git a/include/linux/dma/edma.h
> > > > > > > > > > b/include/linux/dma/edma.h index
> > > > > > > > > > 3080747689f6..78ce31b049ae
> > > > > > > > > > 100644
> > > > > > > > > > --- a/include/linux/dma/edma.h
> > > > > > > > > > +++ b/include/linux/dma/edma.h
> > > > > > > > > > @@ -99,6 +99,7 @@ struct dw_edma_chip {
> > > > > > > > > >       enum dw_edma_map_format mf;
> > > > > > > > > >
> > > > > > > > > >       struct dw_edma          *dw;
> > > > > > > > > > +     bool                    non_ll;
> > > > > > > > >
> > > > > > > > > Can you check ll_region directly? it should be equal to
> > > > > > > > > (ll_region->sz == 0)
> > > > > > > ?
> > > > > > >
> > > > > > > Do you miss this questin?
> > > > > > >
> > > > > > > Frank
> > > > > > >
> > > > > >
> > > > > > Yes, looks like I missed this question. Could you explain a
> > > > > > little bit more? I
> > > > > am unable to understand the context.
> > > > >
> > > > > you set chip->non_ll = non_ll in dw_edma_pcie_probe()
> > > > >
> > > > > and only set ll_region->sz = ll_block->sz when !chip->non_ll.
> > > > >
> > > > > Thats means ll_region->sz is 0 when chip->non_ll is true.
> > > > >
> > > > > So non_ll have not bring new infomation into dw_edma_chip.
> > > > >
> > > > > check !ll_region->sz, which should be equal to this non_ll.
> > > > >
> > > > > dw_edma_chip is the exchange information between controller and
> > > > > dma core driver. Needn't cache it here because you already save
> > > > > a copy in dma-
> > > chan.
> > > > >
> > > > > Frank
> > > >
> > > > I understand the concern here but it does not look good to
> > > > piggyback the non_ll related information on the existing variable.
> > > > The use of bool readily points out the information related to what
> > > > mode is being intended but using the ll_region->sz is an inference
> > > > the user
> > > has to make.
> > > >
> > > > Having ll_region->sz == 0 does not really tell it is non_ll mode
> > > > or not, it can also mean that the size of LL region is zero while
> > > > in LL mode
> > > which could be an error.
> > > > This does not translate to support for non-LL mode. This brings
> > > > the
> > > ambiguity.
> > > > The introduction of the non_ll provides clarity and easy
> > > > comparison with the similar choice (non_ll) provided by the DMA
> > > > consumer in the
> > > dmaengine_slave_config().
> > > > I request we shall retain the clarity here.
> > >
> > > You can use helper(dw_chip_is_support_ll()) macro to check chip's
> > > capatiblity.
> > >
> >
> > I do not understand what you mean with the above statement.
> > But if it about writing a new function to check the LL mode support
> > then I think the current variable is good enough which provides good
> > readability and do not create any ambiguity compared to the ll region size
> comparison.
>
> It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip. So we add more
> cap flags in future.
>
> Frank
>

Hi Frank, could you elaborate what you mean by adding the cap flag? How it is going
To help identify the overall chip state?
I do not understand what is being implied here.

- Regards,
Devendra

> >
> > > Frank
> > > >
> > > > > >
> > > > > > > > >
> > > > > > > > > Frank
> > > > > > > > > >  };
> > > > > > > > > >
> > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > --
> > > > > > > > > > 2.43.0
> > > > > > > > > >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Mon, Feb 23, 2026 at 04:40:07PM +0000, Verma, Devendra wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Friday, February 20, 2026 9:33 PM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
> >
...
> > > But if it about writing a new function to check the LL mode support
> > > then I think the current variable is good enough which provides good
> > > readability and do not create any ambiguity compared to the ll region size
> > comparison.
> >
> > It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip. So we add more
> > cap flags in future.
> >
> > Frank
> >
>
> Hi Frank, could you elaborate what you mean by adding the cap flag? How it is going
> To help identify the overall chip state?
> I do not understand what is being implied here.

non_ll in chan means current status, which indicate one channel work at
non_ll mode or ll mode.

here dw_edma_chip means hardware's captiblity, indicate if hardware support
ll mode.

Distingiush hardware limition or current working mode.

Frank
>
> - Regards,
> Devendra
>
> > >
> > > > Frank
> > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > > > > > Frank
> > > > > > > > > > >  };
> > > > > > > > > > >
> > > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > > --
> > > > > > > > > > > 2.43.0
> > > > > > > > > > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Wednesday, February 25, 2026 3:58 AM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Mon, Feb 23, 2026 at 04:40:07PM +0000, Verma, Devendra wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > > -----Original Message-----
> > > From: Frank Li <Frank.li@nxp.com>
> > > Sent: Friday, February 20, 2026 9:33 PM
> > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > > mode
> > >
> ...
> > > > But if it about writing a new function to check the LL mode
> > > > support then I think the current variable is good enough which
> > > > provides good readability and do not create any ambiguity compared
> > > > to the ll region size
> > > comparison.
> > >
> > > It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip. So we
> > > add more cap flags in future.
> > >
> > > Frank
> > >
> >
> > Hi Frank, could you elaborate what you mean by adding the cap flag?
> > How it is going To help identify the overall chip state?
> > I do not understand what is being implied here.
>
> non_ll in chan means current status, which indicate one channel work at
> non_ll mode or ll mode.
>
> here dw_edma_chip means hardware's captiblity, indicate if hardware
> support ll mode.
>
> Distingiush hardware limition or current working mode.
>
> Frank

Thanks for the explanation!
Hardware supports the LL mode / non-LL mode, just that there is no
piece of code available which can perform the non-LL mode as only one
mode was supported initially by the respective developers.
So, providing it as capability does not look justified as in any scenario
hardware is capable of non-LL mode. Theoretically, non-LL mode should
have been the default mode.

The non-LL mode is not a hardware limitation either. LL mode needs extra
configurations and in the absence of that, interpretation could be, enable
the supported other mode which is non-LL mode.

With the current non_ll inside the dw_edma_chip, when non_ll = false, indicates
It supports both the modes LL and non-LL, but requires user inputs to enable it.
With non_ll = true, the dw_edma_chip or the hardware has no choice but to work in non-LL
mode only. This is the interpretation for the flag in non_ll.

With the capability, would it not make the statement, that if non_ll = true, it supports
non-LL mode but that does not mean to be mutually exclusive and not support LL mode
at the same time?
If there is a requirement regarding the capability then it can be taken as a separate update
but I am not sure what purpose it can serve wrt non-LL functionality.
Please let me know your thoughts on this and lets conclude.

Thanks!

> >
> > - Regards,
> > Devendra
> >
> > > >
> > > > > Frank
> > > > > >
> > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Frank
> > > > > > > > > > > >  };
> > > > > > > > > > > >
> > > > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > > > --
> > > > > > > > > > > > 2.43.0
> > > > > > > > > > > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Frank

Could you provide your inputs on this?

Regards,
Dev

> -----Original Message-----
> From: Verma, Devendra
> Sent: Wednesday, February 25, 2026 5:36 PM
> To: 'Frank Li' <Frank.li@nxp.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>; Verma,
> Devendra <Devendra.Verma@amd.com>
> Subject: RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Wednesday, February 25, 2026 3:58 AM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Mon, Feb 23, 2026 at 04:40:07PM +0000, Verma, Devendra wrote:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > > -----Original Message-----
> > > > From: Frank Li <Frank.li@nxp.com>
> > > > Sent: Friday, February 20, 2026 9:33 PM
> > > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > > > mode
> > > >
> > ...
> > > > > But if it about writing a new function to check the LL mode
> > > > > support then I think the current variable is good enough which
> > > > > provides good readability and do not create any ambiguity
> > > > > compared to the ll region size
> > > > comparison.
> > > >
> > > > It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip. So
> > > > we add more cap flags in future.
> > > >
> > > > Frank
> > > >
> > >
> > > Hi Frank, could you elaborate what you mean by adding the cap flag?
> > > How it is going To help identify the overall chip state?
> > > I do not understand what is being implied here.
> >
> > non_ll in chan means current status, which indicate one channel work
> > at non_ll mode or ll mode.
> >
> > here dw_edma_chip means hardware's captiblity, indicate if hardware
> > support ll mode.
> >
> > Distingiush hardware limition or current working mode.
> >
> > Frank
>
> Thanks for the explanation!
> Hardware supports the LL mode / non-LL mode, just that there is no piece of
> code available which can perform the non-LL mode as only one mode was
> supported initially by the respective developers.
> So, providing it as capability does not look justified as in any scenario
> hardware is capable of non-LL mode. Theoretically, non-LL mode should have
> been the default mode.
>
> The non-LL mode is not a hardware limitation either. LL mode needs extra
> configurations and in the absence of that, interpretation could be, enable the
> supported other mode which is non-LL mode.
>
> With the current non_ll inside the dw_edma_chip, when non_ll = false,
> indicates It supports both the modes LL and non-LL, but requires user inputs
> to enable it.
> With non_ll = true, the dw_edma_chip or the hardware has no choice but to
> work in non-LL mode only. This is the interpretation for the flag in non_ll.
>
> With the capability, would it not make the statement, that if non_ll = true, it
> supports non-LL mode but that does not mean to be mutually exclusive and
> not support LL mode at the same time?
> If there is a requirement regarding the capability then it can be taken as a
> separate update but I am not sure what purpose it can serve wrt non-LL
> functionality.
> Please let me know your thoughts on this and lets conclude.
>
> Thanks!
>
> > >
> > > - Regards,
> > > Devendra
> > >
> > > > >
> > > > > > Frank
> > > > > > >
> > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Frank
> > > > > > > > > > > > >  };
> > > > > > > > > > > > >
> > > > > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > > > > --
> > > > > > > > > > > > > 2.43.0
> > > > > > > > > > > > >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Wed, Feb 25, 2026 at 12:06:12PM +0000, Verma, Devendra wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Wednesday, February 25, 2026 3:58 AM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Mon, Feb 23, 2026 at 04:40:07PM +0000, Verma, Devendra wrote:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > > -----Original Message-----
> > > > From: Frank Li <Frank.li@nxp.com>
> > > > Sent: Friday, February 20, 2026 9:33 PM
> > > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > > > mode
> > > >
> > ...
> > > > > But if it about writing a new function to check the LL mode
> > > > > support then I think the current variable is good enough which
> > > > > provides good readability and do not create any ambiguity compared
> > > > > to the ll region size
> > > > comparison.
> > > >
> > > > It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip. So we
> > > > add more cap flags in future.
> > > >
> > > > Frank
> > > >
> > >
> > > Hi Frank, could you elaborate what you mean by adding the cap flag?
> > > How it is going To help identify the overall chip state?
> > > I do not understand what is being implied here.
> >
> > non_ll in chan means current status, which indicate one channel work at
> > non_ll mode or ll mode.
> >
> > here dw_edma_chip means hardware's captiblity, indicate if hardware
> > support ll mode.
> >
> > Distingiush hardware limition or current working mode.
> >
> > Frank
>
> Thanks for the explanation!
> Hardware supports the LL mode / non-LL mode, just that there is no
> piece of code available which can perform the non-LL mode as only one
> mode was supported initially by the respective developers.
> So, providing it as capability does not look justified as in any scenario
> hardware is capable of non-LL mode. Theoretically, non-LL mode should
> have been the default mode.
>
> The non-LL mode is not a hardware limitation either. LL mode needs extra
> configurations and in the absence of that, interpretation could be, enable
> the supported other mode which is non-LL mode.

Yes, that's reason why I don't want to add non-ll in dw_edma_chip, which
should provide hardware's information.  non-ll actually miss ll_region
information.

>
> With the current non_ll inside the dw_edma_chip, when non_ll = false, indicates
> It supports both the modes LL and non-LL, but requires user inputs to enable it.
> With non_ll = true, the dw_edma_chip or the hardware has no choice but to work in non-LL
> mode only. This is the interpretation for the flag in non_ll.

we need distingiush current state and HW/SW captiblity. in dma_chan, non_ll
means current working state.

but the same words 'non_ll' in dw_edma_chip is HW/SW capablity.

dma_chan: non_ll       means current channel use LL OR non LL.
dma_edma_chips: non_ll means only support non LL mode OR both.

The same words "non_ll" means difference. We should try to avoid this case.

if you want to add field in dw_edma_chip, avoid use the same words because
their means is difference.

Frank
>
> With the capability, would it not make the statement, that if non_ll = true, it supports
> non-LL mode but that does not mean to be mutually exclusive and not support LL mode
> at the same time?
> If there is a requirement regarding the capability then it can be taken as a separate update
> but I am not sure what purpose it can serve wrt non-LL functionality.
> Please let me know your thoughts on this and lets conclude.

>
> Thanks!
>
> > >
> > > - Regards,
> > > Devendra
> > >
> > > > >
> > > > > > Frank
> > > > > > >
> > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Frank
> > > > > > > > > > > > >  };
> > > > > > > > > > > > >
> > > > > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > > > > --
> > > > > > > > > > > > > 2.43.0
> > > > > > > > > > > > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[Public]

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Wednesday, March 4, 2026 10:26 PM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Wed, Feb 25, 2026 at 12:06:12PM +0000, Verma, Devendra wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > > -----Original Message-----
> > > From: Frank Li <Frank.li@nxp.com>
> > > Sent: Wednesday, February 25, 2026 3:58 AM
> > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > > mode
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > On Mon, Feb 23, 2026 at 04:40:07PM +0000, Verma, Devendra wrote:
> > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > >
> > > > > -----Original Message-----
> > > > > From: Frank Li <Frank.li@nxp.com>
> > > > > Sent: Friday, February 20, 2026 9:33 PM
> > > > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add
> > > > > non-LL mode
> > > > >
> > > ...
> > > > > > But if it about writing a new function to check the LL mode
> > > > > > support then I think the current variable is good enough which
> > > > > > provides good readability and do not create any ambiguity
> > > > > > compared to the ll region size
> > > > > comparison.
> > > > >
> > > > > It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip.
> > > > > So we add more cap flags in future.
> > > > >
> > > > > Frank
> > > > >
> > > >
> > > > Hi Frank, could you elaborate what you mean by adding the cap flag?
> > > > How it is going To help identify the overall chip state?
> > > > I do not understand what is being implied here.
> > >
> > > non_ll in chan means current status, which indicate one channel work
> > > at non_ll mode or ll mode.
> > >
> > > here dw_edma_chip means hardware's captiblity, indicate if hardware
> > > support ll mode.
> > >
> > > Distingiush hardware limition or current working mode.
> > >
> > > Frank
> >
> > Thanks for the explanation!
> > Hardware supports the LL mode / non-LL mode, just that there is no
> > piece of code available which can perform the non-LL mode as only one
> > mode was supported initially by the respective developers.
> > So, providing it as capability does not look justified as in any
> > scenario hardware is capable of non-LL mode. Theoretically, non-LL
> > mode should have been the default mode.
> >
> > The non-LL mode is not a hardware limitation either. LL mode needs
> > extra configurations and in the absence of that, interpretation could
> > be, enable the supported other mode which is non-LL mode.
>
> Yes, that's reason why I don't want to add non-ll in dw_edma_chip, which
> should provide hardware's information.  non-ll actually miss ll_region
> information.
>

I think, non_ll can be interpreted without using the ll-region related information
as well. My view regarding the dw_edma_chip struct is slightly different,
it does not provide the hardware capability rather stores a snapshot of
configuration based on information provided by different means,
please take a look at my comment below related to this.

> >
> > With the current non_ll inside the dw_edma_chip, when non_ll = false,
> > indicates It supports both the modes LL and non-LL, but requires user
> inputs to enable it.
> > With non_ll = true, the dw_edma_chip or the hardware has no choice but
> > to work in non-LL mode only. This is the interpretation for the flag in non_ll.
>
> we need distingiush current state and HW/SW captiblity. in dma_chan, non_ll
> means current working state.
>
> but the same words 'non_ll' in dw_edma_chip is HW/SW capablity.
>
> dma_chan: non_ll       means current channel use LL OR non LL.
> dma_edma_chips: non_ll means only support non LL mode OR both.
>
> The same words "non_ll" means difference. We should try to avoid this case.
>
> if you want to add field in dw_edma_chip, avoid use the same words because
> their means is difference.
>
> Frank

Can we please simplify this interpretation, the non_ll in all the scenarios should mean non-LL mode
only if set to true.
dw_edma_chip : non_ll = true, it shall mean that all the channel, at chip level, can work in non-LL mode ONLY.
dw_edma_chan: non_ll = true, it shall mean that individual channel is configured for a transaction in non-LL mode.

Above all, a nice comment related to the flag shall be good enough to make the understanding clear, at the
places where declared.
Since the beginning my emphasis is that 'non_ll' flag should be treated for what it implies, i.e non-LL mode.
It was included in two different sets of structs to show the hierarchy how it could affect the overall functionality
depending upon where 'non_ll' is set to true.
Coming to the dw_edma_chip struct, I do not understand why the dw_edma_chip struct is about
hardware capability, it is more about the configuration of the chip which is filled anyway at the time
of probe() function calling. This struct does not provide any capability information at the time of probe() calling
rather it is filled based on the params configured by user either as static info (eg: snps_edda_data) or by reading
the capability registers (eg: VSEC and channels enabled by reading config space).
I hope this clears the doubt. Please let me know if any further information required related to the non_ll flag
Interpretation.

Regards,
Devendra

> >
> > With the capability, would it not make the statement, that if non_ll =
> > true, it supports non-LL mode but that does not mean to be mutually
> > exclusive and not support LL mode at the same time?
> > If there is a requirement regarding the capability then it can be
> > taken as a separate update but I am not sure what purpose it can serve wrt
> non-LL functionality.
> > Please let me know your thoughts on this and lets conclude.
>
> >
> > Thanks!
> >
> > > >
> > > > - Regards,
> > > > Devendra
> > > >
> > > > > >
> > > > > > > Frank
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Frank
> > > > > > > > > > > > > >  };
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > 2.43.0
> > > > > > > > > > > > > >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Thu, Mar 05, 2026 at 12:15:41PM +0000, Verma, Devendra wrote:
> [Public]
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Wednesday, March 4, 2026 10:26 PM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
> >
> > Caution: This message originated from an External Source. Use proper
> > caution when opening attachments, clicking links, or responding.
> >
> >
> > On Wed, Feb 25, 2026 at 12:06:12PM +0000, Verma, Devendra wrote:
> > > [AMD Official Use Only - AMD Internal Distribution Only]
> > >
> > > > -----Original Message-----
> > > > From: Frank Li <Frank.li@nxp.com>
> > > > Sent: Wednesday, February 25, 2026 3:58 AM
> > > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > > > mode
> > > >
> > > > Caution: This message originated from an External Source. Use proper
> > > > caution when opening attachments, clicking links, or responding.
> > > >
> > > >
> > > > On Mon, Feb 23, 2026 at 04:40:07PM +0000, Verma, Devendra wrote:
> > > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Frank Li <Frank.li@nxp.com>
> > > > > > Sent: Friday, February 20, 2026 9:33 PM
> > > > > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > > > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > > > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > > > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > > > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add
> > > > > > non-LL mode
> > > > > >
> > > > ...
> > > > > > > But if it about writing a new function to check the LL mode
> > > > > > > support then I think the current variable is good enough which
> > > > > > > provides good readability and do not create any ambiguity
> > > > > > > compared to the ll region size
> > > > > > comparison.
> > > > > >
> > > > > > It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip.
> > > > > > So we add more cap flags in future.
> > > > > >
> > > > > > Frank
> > > > > >
> > > > >
> > > > > Hi Frank, could you elaborate what you mean by adding the cap flag?
> > > > > How it is going To help identify the overall chip state?
> > > > > I do not understand what is being implied here.
> > > >
> > > > non_ll in chan means current status, which indicate one channel work
> > > > at non_ll mode or ll mode.
> > > >
> > > > here dw_edma_chip means hardware's captiblity, indicate if hardware
> > > > support ll mode.
> > > >
> > > > Distingiush hardware limition or current working mode.
> > > >
> > > > Frank
> > >
> > > Thanks for the explanation!
> > > Hardware supports the LL mode / non-LL mode, just that there is no
> > > piece of code available which can perform the non-LL mode as only one
> > > mode was supported initially by the respective developers.
> > > So, providing it as capability does not look justified as in any
> > > scenario hardware is capable of non-LL mode. Theoretically, non-LL
> > > mode should have been the default mode.
> > >
> > > The non-LL mode is not a hardware limitation either. LL mode needs
> > > extra configurations and in the absence of that, interpretation could
> > > be, enable the supported other mode which is non-LL mode.
> >
> > Yes, that's reason why I don't want to add non-ll in dw_edma_chip, which
> > should provide hardware's information.  non-ll actually miss ll_region
> > information.
> >
>
> I think, non_ll can be interpreted without using the ll-region related information
> as well. My view regarding the dw_edma_chip struct is slightly different,
> it does not provide the hardware capability rather stores a snapshot of
> configuration based on information provided by different means,
> please take a look at my comment below related to this.
>
> > >
> > > With the current non_ll inside the dw_edma_chip, when non_ll = false,
> > > indicates It supports both the modes LL and non-LL, but requires user
> > inputs to enable it.
> > > With non_ll = true, the dw_edma_chip or the hardware has no choice but
> > > to work in non-LL mode only. This is the interpretation for the flag in non_ll.
> >
> > we need distingiush current state and HW/SW captiblity. in dma_chan, non_ll
> > means current working state.
> >
> > but the same words 'non_ll' in dw_edma_chip is HW/SW capablity.
> >
> > dma_chan: non_ll       means current channel use LL OR non LL.
> > dma_edma_chips: non_ll means only support non LL mode OR both.
> >
> > The same words "non_ll" means difference. We should try to avoid this case.
> >
> > if you want to add field in dw_edma_chip, avoid use the same words because
> > their means is difference.
> >
> > Frank
>
> Can we please simplify this interpretation, the non_ll in all the scenarios should mean non-LL mode
> only if set to true.
> dw_edma_chip : non_ll = true, it shall mean that all the channel, at chip level, can work in non-LL mode ONLY.
> dw_edma_chan: non_ll = true, it shall mean that individual channel is configured for a transaction in non-LL mode.

When read "a->non_ll", need good back check what type of a to know which
one.  if use difference name
	a->non_ll;
	b->cfg_no_ll;

It will not think more about what is a/b.

>
> Above all, a nice comment related to the flag shall be good enough to make the understanding clear, at the
> places where declared.
> Since the beginning my emphasis is that 'non_ll' flag should be treated for what it implies, i.e non-LL mode.
> It was included in two different sets of structs to show the hierarchy how it could affect the overall functionality
> depending upon where 'non_ll' is set to true.

> Coming to the dw_edma_chip struct, I do not understand why the dw_edma_chip struct is about
> hardware capability, it is more about the configuration of the chip which is filled anyway at the time
> of probe() function calling. This struct does not provide any capability information at the time of probe() calling
> rather it is filled based on the params configured by user either as static info (eg: snps_edda_data) or by reading
> the capability registers (eg: VSEC and channels enabled by reading config space).
> I hope this clears the doubt. Please let me know if any further information required related to the non_ll flag
> Interpretation.

I don't want to take more time at this kind small stuff. I am fine if
vnod Or mani (who pick up these patches) think it is okay.

Frank

>
> Regards,
> Devendra
>
> > >
> > > With the capability, would it not make the statement, that if non_ll =
> > > true, it supports non-LL mode but that does not mean to be mutually
> > > exclusive and not support LL mode at the same time?
> > > If there is a requirement regarding the capability then it can be
> > > taken as a separate update but I am not sure what purpose it can serve wrt
> > non-LL functionality.
> > > Please let me know your thoughts on this and lets conclude.
> >
> > >
> > > Thanks!
> > >
> > > > >
> > > > > - Regards,
> > > > > Devendra
> > > > >
> > > > > > >
> > > > > > > > Frank
> > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Frank
> > > > > > > > > > > > > > >  };
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > 2.43.0
> > > > > > > > > > > > > > >

RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Verma, Devendra]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Thursday, March 5, 2026 9:34 PM
> To: Verma, Devendra <Devendra.Verma@amd.com>
> Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> mode
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Mar 05, 2026 at 12:15:41PM +0000, Verma, Devendra wrote:
> > [Public]
> >
> > > -----Original Message-----
> > > From: Frank Li <Frank.li@nxp.com>
> > > Sent: Wednesday, March 4, 2026 10:26 PM
> > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > > mode
> > >
> > > Caution: This message originated from an External Source. Use proper
> > > caution when opening attachments, clicking links, or responding.
> > >
> > >
> > > On Wed, Feb 25, 2026 at 12:06:12PM +0000, Verma, Devendra wrote:
> > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > >
> > > > > -----Original Message-----
> > > > > From: Frank Li <Frank.li@nxp.com>
> > > > > Sent: Wednesday, February 25, 2026 3:58 AM
> > > > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add
> > > > > non-LL mode
> > > > >
> > > > > Caution: This message originated from an External Source. Use
> > > > > proper caution when opening attachments, clicking links, or
> responding.
> > > > >
> > > > >
> > > > > On Mon, Feb 23, 2026 at 04:40:07PM +0000, Verma, Devendra wrote:
> > > > > > [AMD Official Use Only - AMD Internal Distribution Only]
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Frank Li <Frank.li@nxp.com>
> > > > > > > Sent: Friday, February 20, 2026 9:33 PM
> > > > > > > To: Verma, Devendra <Devendra.Verma@amd.com>
> > > > > > > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > > > > > > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > > > > > > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > > > > > > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add
> > > > > > > non-LL mode
> > > > > > >
> > > > > ...
> > > > > > > > But if it about writing a new function to check the LL
> > > > > > > > mode support then I think the current variable is good
> > > > > > > > enough which provides good readability and do not create
> > > > > > > > any ambiguity compared to the ll region size
> > > > > > > comparison.
> > > > > > >
> > > > > > > It is not big deal,  use 'bool cap_non_ll: 1' in dw_edma_chip.
> > > > > > > So we add more cap flags in future.
> > > > > > >
> > > > > > > Frank
> > > > > > >
> > > > > >
> > > > > > Hi Frank, could you elaborate what you mean by adding the cap flag?
> > > > > > How it is going To help identify the overall chip state?
> > > > > > I do not understand what is being implied here.
> > > > >
> > > > > non_ll in chan means current status, which indicate one channel
> > > > > work at non_ll mode or ll mode.
> > > > >
> > > > > here dw_edma_chip means hardware's captiblity, indicate if
> > > > > hardware support ll mode.
> > > > >
> > > > > Distingiush hardware limition or current working mode.
> > > > >
> > > > > Frank
> > > >
> > > > Thanks for the explanation!
> > > > Hardware supports the LL mode / non-LL mode, just that there is no
> > > > piece of code available which can perform the non-LL mode as only
> > > > one mode was supported initially by the respective developers.
> > > > So, providing it as capability does not look justified as in any
> > > > scenario hardware is capable of non-LL mode. Theoretically, non-LL
> > > > mode should have been the default mode.
> > > >
> > > > The non-LL mode is not a hardware limitation either. LL mode needs
> > > > extra configurations and in the absence of that, interpretation
> > > > could be, enable the supported other mode which is non-LL mode.
> > >
> > > Yes, that's reason why I don't want to add non-ll in dw_edma_chip,
> > > which should provide hardware's information.  non-ll actually miss
> > > ll_region information.
> > >
> >
> > I think, non_ll can be interpreted without using the ll-region related
> > information as well. My view regarding the dw_edma_chip struct is
> > slightly different, it does not provide the hardware capability rather
> > stores a snapshot of configuration based on information provided by
> > different means, please take a look at my comment below related to this.
> >
> > > >
> > > > With the current non_ll inside the dw_edma_chip, when non_ll =
> > > > false, indicates It supports both the modes LL and non-LL, but
> > > > requires user
> > > inputs to enable it.
> > > > With non_ll = true, the dw_edma_chip or the hardware has no choice
> > > > but to work in non-LL mode only. This is the interpretation for the flag in
> non_ll.
> > >
> > > we need distingiush current state and HW/SW captiblity. in dma_chan,
> > > non_ll means current working state.
> > >
> > > but the same words 'non_ll' in dw_edma_chip is HW/SW capablity.
> > >
> > > dma_chan: non_ll       means current channel use LL OR non LL.
> > > dma_edma_chips: non_ll means only support non LL mode OR both.
> > >
> > > The same words "non_ll" means difference. We should try to avoid this
> case.
> > >
> > > if you want to add field in dw_edma_chip, avoid use the same words
> > > because their means is difference.
> > >
> > > Frank
> >
> > Can we please simplify this interpretation, the non_ll in all the
> > scenarios should mean non-LL mode only if set to true.
> > dw_edma_chip : non_ll = true, it shall mean that all the channel, at chip level,
> can work in non-LL mode ONLY.
> > dw_edma_chan: non_ll = true, it shall mean that individual channel is
> configured for a transaction in non-LL mode.
>
> When read "a->non_ll", need good back check what type of a to know which
> one.  if use difference name
>         a->non_ll;
>         b->cfg_no_ll;
>
> It will not think more about what is a/b.
>

This suggestion is taken. I will push in next version of patches. Thanks!

> >
> > Above all, a nice comment related to the flag shall be good enough to
> > make the understanding clear, at the places where declared.
> > Since the beginning my emphasis is that 'non_ll' flag should be treated for
> what it implies, i.e non-LL mode.
> > It was included in two different sets of structs to show the hierarchy
> > how it could affect the overall functionality depending upon where 'non_ll' is
> set to true.
>
> > Coming to the dw_edma_chip struct, I do not understand why the
> > dw_edma_chip struct is about hardware capability, it is more about the
> > configuration of the chip which is filled anyway at the time of
> > probe() function calling. This struct does not provide any capability
> > information at the time of probe() calling rather it is filled based on the
> params configured by user either as static info (eg: snps_edda_data) or by
> reading the capability registers (eg: VSEC and channels enabled by reading
> config space).
> > I hope this clears the doubt. Please let me know if any further
> > information required related to the non_ll flag Interpretation.
>
> I don't want to take more time at this kind small stuff. I am fine if vnod Or mani
> (who pick up these patches) think it is okay.
>

Frank, could you please approve the patches if changes look ok to you?

> Frank
>
> >
> > Regards,
> > Devendra
> >
> > > >
> > > > With the capability, would it not make the statement, that if
> > > > non_ll = true, it supports non-LL mode but that does not mean to
> > > > be mutually exclusive and not support LL mode at the same time?
> > > > If there is a requirement regarding the capability then it can be
> > > > taken as a separate update but I am not sure what purpose it can
> > > > serve wrt
> > > non-LL functionality.
> > > > Please let me know your thoughts on this and lets conclude.
> > >
> > > >
> > > > Thanks!
> > > >
> > > > > >
> > > > > > - Regards,
> > > > > > Devendra
> > > > > >
> > > > > > > >
> > > > > > > > > Frank
> > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Frank
> > > > > > > > > > > > > > > >  };
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >  /* Export to the platform drivers */
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > 2.43.0
> > > > > > > > > > > > > > > >

Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

[Frank Li]

On Fri, Mar 06, 2026 at 11:50:39AM +0000, Verma, Devendra wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Thursday, March 5, 2026 9:34 PM
> > To: Verma, Devendra <Devendra.Verma@amd.com>
> > Cc: bhelgaas@google.com; mani@kernel.org; vkoul@kernel.org;
> > dmaengine@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org; Simek, Michal <michal.simek@amd.com>
> > Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL
> > mode
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > I don't want to take more time at this kind small stuff. I am fine if vnod Or mani
> > (who pick up these patches) think it is okay.
> >
>
> Frank, could you please approve the patches if changes look ok to you?

I will provide review by tags if I am satisfied.

Frank