Add AMD MDB Endpoint and non-LL mode Support

PATCH RESEND Superseded Devendra K Verma 2 participants 23 messages Feb 16 – Mar 6

Subsystems (3)

PCI dmaengine DesignWare edma core IP driver

lore

Share & tools

lore

Devendra K Verma

author

2026-02-16 10:55 UTC #0 lore raw

v10 cover Add AMD MDB Endpoint and non-LL mode Support

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

Signature · 1 line

2.43.0

Devendra K Verma

author

2026-02-16 10:56 UTC #1 lore raw

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

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 <[email protected]>

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

drivers/dma/dw-edma/dw-edma-pcie.c +176 ~~-14~~

index 3371e0a76d3c..3aefc48f8e0a 100644
@@ -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);

Signature · 1 line

2.43.0

Frank Li

2026-02-16 19:28 UTC #2 lore raw

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

Quoted 67 lines · 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 <[email protected]>
---
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(-)

...

Quoted 24 lines

drivers/dma/dw-edma/dw-edma-pcie.c +23 -0

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

drivers/dma/dw-edma/dw-edma-pcie.c static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev, · line 272

Quoted 10 lines

drivers/dma/dw-edma/dw-edma-pcie.c +10 -0

+		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/[email protected]/

suggest direct use min()

Frank

Quoted 71 lines

drivers/dma/dw-edma/dw-edma-pcie.c +50 -2

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

Verma, Devendra

author

2026-02-17 11:36 UTC #3 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Quoted 120 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Tuesday, February 17, 2026 12:58 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 65 lines · 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 <[email protected]>
---
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(-)
...
Quoted 11 lines
drivers/dma/dw-edma/dw-edma-pcie.c +10 -0
+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,
drivers/dma/dw-edma/dw-edma-pcie.c static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
Quoted 10 lines
drivers/dma/dw-edma/dw-edma-pcie.c +10 -0
+                                     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");
drivers/dma/dw-edma/dw-edma-pcie.c static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
Quoted 7 lines
drivers/dma/dw-edma/dw-edma-pcie.c +7 -0
+     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);
drivers/dma/dw-edma/dw-edma-pcie.c static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
Quoted 4 lines
drivers/dma/dw-edma/dw-edma-pcie.c +4 -0
+
+     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));
drivers/dma/dw-edma/dw-edma-pcie.c static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-pcie.c +3 -0
+     pdata->rd_ch_cnt = min_t(u16, pdata->rd_ch_cnt,
+
+ FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));

Quoted 6 lines

In https://lore.kernel.org/all/20251119224140.8616-1-
[email protected]/
suggest direct use min()
Frank

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

Quoted 72 lines

Quoted 32 lines

drivers/dma/dw-edma/dw-edma-pcie.c +25 -2

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

drivers/dma/dw-edma/dw-edma-pcie.c static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,

Quoted 10 lines

drivers/dma/dw-edma/dw-edma-pcie.c +10 -0

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

Quoted 29 lines

drivers/dma/dw-edma/dw-edma-pcie.c +15 -0

+                     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

Devendra K Verma

author

2026-02-16 10:56 UTC #4 lore raw

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

In reply to 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 <[email protected]>

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

drivers/dma/dw-edma/dw-edma-core.c +34 -1

index b43255f914f3..ef3d79a9f88d 100644
@@ -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;

drivers/dma/dw-edma/dw-edma-core.h +1 -0

index 71894b9e0b15..c8e3d196a549 100644
@@ -86,6 +86,7 @@ struct dw_edma_chan {
 	u8				configured;
 
 	struct dma_slave_config		config;
+	bool				non_ll;
 };
 
 struct dw_edma_irq {

drivers/dma/dw-edma/dw-edma-pcie.c +31 ~~-13~~

110 lines not on this page · raw message

drivers/dma/dw-edma/dw-hdma-v0-core.c +64 -1

77 lines not on this page · raw message

drivers/dma/dw-edma/dw-hdma-v0-regs.h +1 -0

index eab5fd7177e5..7759ba9b4850 100644
@@ -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)

include/linux/dma/edma.h +1 -0

index 3080747689f6..78ce31b049ae 100644
@@ -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 */

Signature · 1 line

2.43.0

Frank Li

2026-02-16 19:45 UTC #5 lore raw

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

Quoted 69 lines · 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 <[email protected]>
---
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(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644

drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan, · line 229

Quoted 7 lines

drivers/dma/dw-edma/dw-edma-core.c +4 -0

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

Quoted 9 lines

drivers/dma/dw-edma/dw-edma-core.c +9 -0

+		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

drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan, · line 248

Quoted 10 lines

drivers/dma/dw-edma/dw-edma-core.c +10 -0

+		 * 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.

Quoted 271 lines

drivers/dma/dw-edma/dw-edma-core.c +11 -1

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

drivers/dma/dw-edma/dw-edma-core.h +1 -0

index 71894b9e0b15..c8e3d196a549 100644
@@ -86,6 +86,7 @@ struct dw_edma_chan {
 	u8				configured;
 
 	struct dma_slave_config		config;
+	bool				non_ll;
 };
 
 struct dw_edma_irq {

drivers/dma/dw-edma/dw-edma-pcie.c +31 ~~-13~~

index 3aefc48f8e0a..94621b0f87df 100644
@@ -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;
 	}

drivers/dma/dw-edma/dw-hdma-v0-core.c +64 -1

index e3f8db4fe909..a1b04fec6310 100644
@@ -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;

drivers/dma/dw-edma/dw-hdma-v0-regs.h +1 -0

index eab5fd7177e5..7759ba9b4850 100644
@@ -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)

include/linux/dma/edma.h +0 -0

index 3080747689f6..78ce31b049ae 100644

include/linux/dma/edma.h struct dw_edma_chip { · line 102

Quoted 4 lines

include/linux/dma/edma.h +1 -0

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

Quoted 6 lines

include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-02-17 11:48 UTC #6 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Frank

Please check my responses inline.

Regards,
Devendra

Quoted 94 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Tuesday, February 17, 2026 1:16 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 55 lines · 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 <[email protected]>
---
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.
Quoted 6 lines
---
 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 +
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct
Quoted 9 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
dma_chan *dchan,
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan, · line 229
Quoted 6 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
                               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) {

Quoted 4 lines

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.

Quoted 15 lines

drivers/dma/dw-edma/dw-edma-core.c +15 -0

+             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.
+              */

Quoted 9 lines

drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan,
Quoted 5 lines
drivers/dma/dw-edma/dw-edma-core.c +5 -0
+             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.

Quoted 300 lines

drivers/dma/dw-edma/dw-edma-core.c dw_edma_device_transfer(struct

Quoted 6 lines

drivers/dma/dw-edma/dw-edma-core.c +2 -0

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

drivers/dma/dw-edma/dw-edma-core.c dw_edma_device_transfer(struct

Quoted 8 lines

drivers/dma/dw-edma/dw-edma-core.c +1 -0

      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)

drivers/dma/dw-edma/dw-edma-core.c dw_edma_device_transfer(struct

Quoted 14 lines

drivers/dma/dw-edma/dw-edma-core.c +7 -0

              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)

drivers/dma/dw-edma/dw-edma-pcie.c static void

Quoted 27 lines

drivers/dma/dw-edma/dw-edma-core.c +1 -1

              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

drivers/dma/dw-edma/dw-edma-core.h +1 -0

@@ -86,6 +86,7 @@ struct dw_edma_chan {
      u8                              configured;
 
      struct dma_slave_config         config;
+     bool                            non_ll;
 };
 
 struct dw_edma_irq {

drivers/dma/dw-edma/dw-edma-pcie.c +0 -0

index 3aefc48f8e0a..94621b0f87df 100644
@@ -295,6 +295,15 @@ static void

dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,

Quoted 21 lines

drivers/dma/dw-edma/dw-edma-pcie.c +8 -1

      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)

drivers/dma/dw-edma/dw-edma-pcie.c static int dw_edma_pcie_probe(struct pci_dev · line 347

Quoted 10 lines

drivers/dma/dw-edma/dw-edma-pcie.c +3 -1

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

drivers/dma/dw-edma/dw-edma-pcie.c static int dw_edma_pcie_probe(struct pci_dev

Quoted 24 lines

drivers/dma/dw-edma/dw-edma-pcie.c +8 -6

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

drivers/dma/dw-edma/dw-edma-pcie.c static int dw_edma_pcie_probe(struct pci_dev

Quoted 17 lines

drivers/dma/dw-edma/dw-edma-pcie.c +1 -0

      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;

drivers/dma/dw-edma/dw-edma-pcie.c +1 -1

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

drivers/dma/dw-edma/dw-edma-pcie.c static int dw_edma_pcie_probe(struct pci_dev

Quoted 10 lines

drivers/dma/dw-edma/dw-edma-pcie.c +2 -1

                      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,

drivers/dma/dw-edma/dw-edma-pcie.c static int dw_edma_pcie_probe(struct pci_dev

Quoted 16 lines

drivers/dma/dw-edma/dw-edma-pcie.c +3 -2

                      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,

drivers/dma/dw-edma/dw-edma-pcie.c static int dw_edma_pcie_probe(struct pci_dev

Quoted 10 lines

drivers/dma/dw-edma/dw-edma-pcie.c +2 -1

                      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,

drivers/dma/dw-edma/dw-hdma-v0-core.c static void dw_hdma_v0_sync_ll_data(struct

Quoted 15 lines

drivers/dma/dw-edma/dw-edma-pcie.c +2 -1

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

drivers/dma/dw-edma/dw-hdma-v0-core.c +0 -0

index e3f8db4fe909..a1b04fec6310 100644
@@ -225,7 +225,7 @@ static void dw_hdma_v0_sync_ll_data(struct

dw_edma_chunk *chunk)

drivers/dma/dw-edma/dw-hdma-v0-core.c static void dw_hdma_v0_core_start(struct

Quoted 10 lines

drivers/dma/dw-edma/dw-hdma-v0-core.c +2 -1

              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)

drivers/dma/dw-edma/dw-hdma-v0-core.c static void dw_hdma_v0_core_start(struct · line 266

Quoted 4 lines

drivers/dma/dw-edma/dw-hdma-v0-core.c +1 -0

      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)

Quoted 81 lines

drivers/dma/dw-edma/dw-hdma-v0-core.c +61 -0

+{
+     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;

drivers/dma/dw-edma/dw-hdma-v0-regs.h +1 -0

index eab5fd7177e5..7759ba9b4850 100644
@@ -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)

include/linux/dma/edma.h index renamed from include/linux/dma/edma.h +0 -0

3080747689f6..78ce31b049ae 100644

include/linux/dma/edma.h struct dw_edma_chip { · line 102

Quoted 4 lines

include/linux/dma/edma.h +1 -0

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

Quoted 6 lines

include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Frank Li

2026-02-17 16:39 UTC #7 lore raw

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

Quoted 107 lines · Devendra

[AMD Official Use Only - AMD Internal Distribution Only]
Hi Frank
Please check my responses inline.
Regards,
Devendra
Quoted 94 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Tuesday, February 17, 2026 1:16 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 55 lines · 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 <[email protected]>
---
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.
Quoted 6 lines
---
 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 +
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct
Quoted 9 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
dma_chan *dchan,
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan, · line 229
Quoted 6 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
                               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) {
Quoted 4 lines
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.

Quoted 9 lines

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.

Quoted 26 lines

Quoted 16 lines

drivers/dma/dw-edma/dw-edma-core.c +15 -0

+             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.
+              */

Quoted 9 lines

drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan,
Quoted 5 lines
drivers/dma/dw-edma/dw-edma-core.c +5 -0
+             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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 7 lines

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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
 

...

Quoted 11 lines

Quoted 11 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 9 lines
include/linux/dma/edma.h index renamed from include/linux/dma/edma.h +0 -0
3080747689f6..78ce31b049ae 100644
include/linux/dma/edma.h +1 -0
@@ -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

Quoted 8 lines

Quoted 8 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-02-18 11:33 UTC #8 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Quoted 9 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Tuesday, February 17, 2026 10:09 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

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

Quoted 119 lines

Quoted 80 lines
Quoted 80 lines · Devendra K Verma
Quoted 55 lines
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 <[email protected]>
---
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.
Quoted 6 lines
---
 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 +
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct
Quoted 9 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
dma_chan *dchan,
Quoted 6 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
                               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) {
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
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
        }

        ...
}

Quoted 2 lines

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.

Quoted 31 lines

Quoted 26 lines

Quoted 16 lines

drivers/dma/dw-edma/dw-edma-core.c +15 -0

+             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.
+              */

Quoted 9 lines

drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan,
Quoted 5 lines
drivers/dma/dw-edma/dw-edma-core.c +5 -0
+             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.

Quoted 4 lines

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.

Quoted 8 lines

This is API's callback, you can't assume caller do all correct things.
Quoted 2 lines
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.

Quoted 19 lines

Quoted 7 lines
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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
 
...
Quoted 11 lines
Quoted 11 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 9 lines
include/linux/dma/edma.h +1 -0
index 3080747689f6..78ce31b049ae 100644
@@ -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)

Quoted 6 lines

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

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Frank Li

2026-02-18 15:49 UTC #9 lore raw

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

Quoted 201 lines · Devendra

[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 9 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Tuesday, February 17, 2026 10:09 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
---[ Snipped some text to reduce mail size ]---
Quoted 119 lines
Quoted 80 lines
Quoted 80 lines · Devendra K Verma
Quoted 55 lines
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 <[email protected]>
---
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.
Quoted 6 lines
---
 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 +
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct
Quoted 9 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
dma_chan *dchan,
Quoted 6 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
                               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) {
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
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
        }

        ...
}
Quoted 2 lines
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.
Quoted 31 lines
Quoted 26 lines
Quoted 16 lines
Quoted 16 lines
drivers/dma/dw-edma/dw-edma-core.c +15 -0
+             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.
+              */
Quoted 9 lines
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan,
Quoted 5 lines
drivers/dma/dw-edma/dw-edma-core.c +5 -0
+             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.
Quoted 4 lines
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.
Quoted 8 lines
This is API's callback, you can't assume caller do all correct things.
Quoted 2 lines
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.

Quoted 5 lines

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.

Quoted 20 lines

Quoted 20 lines
Quoted 8 lines
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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
 
...
Quoted 11 lines
Quoted 11 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 9 lines
include/linux/dma/edma.h +1 -0
index 3080747689f6..78ce31b049ae 100644
@@ -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)

Quoted 8 lines

Quoted 6 lines
?
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

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-02-19 09:55 UTC #10 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Quoted 9 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 18, 2026 9:20 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

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

Quoted 213 lines

Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines · Devendra K Verma
Quoted 33 lines
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 <[email protected]>
---
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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().
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
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().
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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-
Quoted 71 lines
Quoted 60 lines
Quoted 24 lines
Quoted 18 lines
regs.h | 1 +
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct
Quoted 9 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
dma_chan *dchan,
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan, · line 229
Quoted 6 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
                               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) {
Quoted 5 lines
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.
Quoted 3 lines
For the case of EDMA, the behavior is unchanged.
Even if the config->peripheral_config param is set then it would be simply
ignored.
Quoted 8 lines
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
        }

        ...
}
Quoted 2 lines
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 */
}
Quoted 1 line
Using the above, if support needs to be added to EDMA then a check for
correct 'mf'
Quoted 12 lines
in the if() shall be sufficient.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/dma/dw-edma/dw-edma-core.c +9 -0
+             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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct dma_chan *dchan,
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +3 -0
+              * default DMA ops will use the non-LL mode.
+              *
+              * Cases where LL mode is enabled and client wants to use
the
Quoted 24 lines
Quoted 24 lines
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
drivers/dma/dw-edma/dw-edma-core.c +9 -0
+              * 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))
Quoted 8 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 1 line
In the case where chan->dw->chip->non_ll = true, following case may
happen:
Quoted 4 lines
- 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
Quoted 7 lines
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

Quoted 9 lines

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.

Quoted 38 lines

Quoted 22 lines
Quoted 22 lines
Quoted 8 lines
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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
 
...
Quoted 13 lines
Quoted 13 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 10 lines
(quoted diff) +0 -0
b/include/linux/dma/edma.h index 3080747689f6..78ce31b049ae 100644
include/linux/dma/edma.h +1 -0
@@ -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)
Quoted 8 lines
Quoted 6 lines
?
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.

Quoted 8 lines

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.

Quoted 9 lines

Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Frank Li

2026-02-19 17:07 UTC #11 lore raw

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

Quoted 234 lines · Devendra

[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 9 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 18, 2026 9:20 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
---[ Snipped some text to reduce mail size ]---
Quoted 220 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines
Quoted 34 lines · Devendra K Verma
Quoted 33 lines
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 <[email protected]>
---
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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().
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
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().
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
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-
Quoted 71 lines
Quoted 60 lines
Quoted 24 lines
Quoted 18 lines
regs.h | 1 +
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct
Quoted 9 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int dw_edma_device_config(struct
dma_chan *dchan,
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct · line 228
Quoted 6 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
                               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) {
Quoted 5 lines
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.
Quoted 3 lines
For the case of EDMA, the behavior is unchanged.
Even if the config->peripheral_config param is set then it would be simply
ignored.
Quoted 8 lines
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
        }

        ...
}
Quoted 2 lines
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 */
}
Quoted 1 line
Using the above, if support needs to be added to EDMA then a check for
correct 'mf'
Quoted 12 lines
in the if() shall be sufficient.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
drivers/dma/dw-edma/dw-edma-core.c +9 -0
+             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
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c static int dw_edma_device_config(struct · line 240
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +3 -0
+              * default DMA ops will use the non-LL mode.
+              *
+              * Cases where LL mode is enabled and client wants to use
the
Quoted 24 lines
Quoted 24 lines
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
drivers/dma/dw-edma/dw-edma-core.c +9 -0
+              * 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))
Quoted 8 lines
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 1 line
In the case where chan->dw->chip->non_ll = true, following case may
happen:
Quoted 4 lines
- 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
Quoted 7 lines
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)

Quoted 6 lines

Quoted 2 lines
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.

Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 53 lines

Quoted 39 lines
Quoted 23 lines
Quoted 23 lines
Quoted 9 lines
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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
 
...
Quoted 13 lines
Quoted 13 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 10 lines
(quoted diff) +0 -0
b/include/linux/dma/edma.h index 3080747689f6..78ce31b049ae 100644
include/linux/dma/edma.h +1 -0
@@ -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)
Quoted 8 lines
Quoted 6 lines
?
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.
Quoted 8 lines
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.

Quoted 6 lines

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

Quoted 10 lines

Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-02-20 11:48 UTC #12 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Frank
Please check my response inline

Regards,
Devendra

Quoted 9 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Thursday, February 19, 2026 10:38 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

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

Quoted 295 lines

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma
Quoted 1 line · wrote:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
AMD MDB IP supports Linked List (LL) mode as well as non-LL
mode.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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,
Quoted 38 lines
Quoted 38 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
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 <[email protected]>
---
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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().
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Comments follow the 80-column guideline.
Changes in v4
No change
Changes in v3
No change
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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().
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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 ++++++++++++----
--
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
 drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
++++++++++++++++++++++++++- drivers/dma/dw-edma/dw-
hdma-
Quoted 39 lines
Quoted 39 lines
v0-
Quoted 38 lines
Quoted 38 lines
Quoted 26 lines
Quoted 20 lines
regs.h | 1 +
Quoted 10 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int
dw_edma_device_config(struct
dma_chan *dchan,
drivers/dma/dw-edma/dw-edma-core.c
Quoted 7 lines
struct dma_slave_config *config) {
struct dw_edma_chan *chan =
dchan2dw_edma_chan(dchan);
drivers/dma/dw-edma/dw-edma-core.c +4 -0
+     int non_ll = 0;
+
+     chan->non_ll = false;
+     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
Quoted 5 lines
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.
Quoted 3 lines
For the case of EDMA, the behavior is unchanged. Even if the config->peripheral_config param is set then it would be simply
ignored.
Quoted 8 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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.
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
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
        }
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
        ...
}
Add EDMA support no-ll mode is quite easily in future.
This looks reasonable provided that HDMA got the support for this
param.
Quoted 23 lines
Quoted 23 lines
Quoted 9 lines
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'
Quoted 13 lines
in the if() shall be sufficient.
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/dma/dw-edma/dw-edma-core.c +10 -0
+             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
Quoted 7 lines
Quoted 7 lines
the
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
drivers/dma/dw-edma/dw-edma-core.c
Quoted 4 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
+              * default DMA ops will use the non-LL mode.
+              *
+              * Cases where LL mode is enabled and client
+ wants to use
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
+ * non-LL mode then also client can do so via providing
the
Quoted 64 lines
Quoted 64 lines
Quoted 24 lines
Quoted 24 lines
Quoted 13 lines
Quoted 9 lines
drivers/dma/dw-edma/dw-edma-core.c
Quoted 8 lines
drivers/dma/dw-edma/dw-edma-core.c +8 -0
+              * 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))
Quoted 3 lines
if chan->dw->chip->non_ll is true, It should return error if you set non_ll false because no LLP base available.
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
In the case where chan->dw->chip->non_ll = true, following case may
happen:
Quoted 5 lines
- 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
Quoted 8 lines
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
Quoted 5 lines
Quoted 5 lines
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
Quoted 8 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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
Quoted 2 lines
user enables it via peripheral_config params.
- This addition, inadvertently, makes the DMA controller usable, for AMD
(Xilinx) only, when the LLP
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 1 line
Please let me know if this clarifies the doubt.
No API to get mode, only use set and test to know it.

Quoted 8 lines

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.

Quoted 61 lines

Quoted 39 lines
Quoted 39 lines
Quoted 26 lines
Quoted 26 lines
Quoted 9 lines
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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
...
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
(quoted diff) +0 -0
b/include/linux/dma/edma.h index
3080747689f6..78ce31b049ae
100644
include/linux/dma/edma.h +0 -0
@@ -99,6 +99,7 @@ struct dw_edma_chip {
      enum dw_edma_map_format mf;
 
Quoted 5 lines
Quoted 5 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 2 lines
include/linux/dma/edma.h +1 -0
      struct dw_edma          *dw;
+     bool                    non_ll;
Can you check ll_region directly? it should be equal to (ll_region->sz == 0)
?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 1 line
This does not translate to support for non-LL mode. This brings the

Quoted 9 lines

ambiguity.
Quoted 2 lines
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().
Quoted 1 line
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.

Quoted 11 lines

Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Frank Li

2026-02-20 16:03 UTC #13 lore raw

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

Quoted 392 lines · Devendra

[AMD Official Use Only - AMD Internal Distribution Only]
Hi Frank
Please check my response inline
Regards,
Devendra
Quoted 9 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Thursday, February 19, 2026 10:38 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
---[ Snipped some text to reduce mail size ]---
Quoted 295 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma
Quoted 1 line · wrote:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
AMD MDB IP supports Linked List (LL) mode as well as non-LL
mode.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
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,
Quoted 38 lines
Quoted 38 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
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 <[email protected]>
---
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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().
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Comments follow the 80-column guideline.
Changes in v4
No change
Changes in v3
No change
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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().
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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 ++++++++++++----
--
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
 drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
++++++++++++++++++++++++++- drivers/dma/dw-edma/dw-
hdma-
Quoted 39 lines
Quoted 39 lines
v0-
Quoted 38 lines
Quoted 38 lines
Quoted 26 lines
Quoted 20 lines
regs.h | 1 +
Quoted 10 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int
dw_edma_device_config(struct
dma_chan *dchan,
drivers/dma/dw-edma/dw-edma-core.c
Quoted 7 lines
struct dma_slave_config *config) {
struct dw_edma_chan *chan =
dchan2dw_edma_chan(dchan);
drivers/dma/dw-edma/dw-edma-core.c +4 -0
+     int non_ll = 0;
+
+     chan->non_ll = false;
+     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
Quoted 5 lines
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.
Quoted 3 lines
For the case of EDMA, the behavior is unchanged. Even if the config->peripheral_config param is set then it would be simply
ignored.
Quoted 8 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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.
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
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
        }
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
        ...
}
Add EDMA support no-ll mode is quite easily in future.
This looks reasonable provided that HDMA got the support for this
param.
Quoted 23 lines
Quoted 23 lines
Quoted 9 lines
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'
Quoted 13 lines
in the if() shall be sufficient.
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/dma/dw-edma/dw-edma-core.c +10 -0
+             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
Quoted 7 lines
Quoted 7 lines
the
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
drivers/dma/dw-edma/dw-edma-core.c
Quoted 4 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
+              * default DMA ops will use the non-LL mode.
+              *
+              * Cases where LL mode is enabled and client
+ wants to use
the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
+ * non-LL mode then also client can do so via providing
the
Quoted 64 lines
Quoted 64 lines
Quoted 24 lines
Quoted 24 lines
Quoted 13 lines
Quoted 9 lines
drivers/dma/dw-edma/dw-edma-core.c
Quoted 8 lines
drivers/dma/dw-edma/dw-edma-core.c +8 -0
+              * 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))
Quoted 3 lines
if chan->dw->chip->non_ll is true, It should return error if you set non_ll false because no LLP base available.
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
In the case where chan->dw->chip->non_ll = true, following case may
happen:
Quoted 5 lines
- 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
Quoted 8 lines
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
Quoted 5 lines
Quoted 5 lines
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
Quoted 8 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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
Quoted 2 lines
user enables it via peripheral_config params.
- This addition, inadvertently, makes the DMA controller usable, for AMD
(Xilinx) only, when the LLP
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 1 line
Please let me know if this clarifies the doubt.
No API to get mode, only use set and test to know it.
Quoted 8 lines
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.
Quoted 67 lines
Quoted 39 lines
Quoted 39 lines
Quoted 26 lines
Quoted 26 lines
Quoted 9 lines
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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
...
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
(quoted diff) +0 -0
b/include/linux/dma/edma.h index
3080747689f6..78ce31b049ae
100644
include/linux/dma/edma.h +0 -0
@@ -99,6 +99,7 @@ struct dw_edma_chip {
      enum dw_edma_map_format mf;
 
Quoted 5 lines
Quoted 5 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 2 lines
include/linux/dma/edma.h +1 -0
      struct dw_edma          *dw;
+     bool                    non_ll;
Can you check ll_region directly? it should be equal to (ll_region->sz == 0)
?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 8 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 1 line
This does not translate to support for non-LL mode. This brings the
ambiguity.
Quoted 2 lines
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().
Quoted 1 line
I request we shall retain the clarity here.

Quoted 8 lines

Quoted 3 lines
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

Quoted 12 lines

Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-02-23 16:40 UTC #14 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Quoted 447 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 17 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Hi Frank
Please check my response inline
Regards,
Devendra
Quoted 9 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Thursday, February 19, 2026 10:38 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
Quoted 12 lines
---[ Snipped some text to reduce mail size ]---
Quoted 10 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On Mon, Feb 16, 2026 at 04:25:46PM +0530, Devendra K Verma
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
AMD MDB IP supports Linked List (LL) mode as well as non-LL
mode.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
be using the non-LL mode only. This, the default non-LL
mode,
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
is not applicable for Synopsys IP with the current code
addition.
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
- If the default mode is LL-mode, for both AMD
(Xilinx) and
Synosys,
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
and if user wants to use non-LL mode then user can do so
via
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
configuring the peripheral_config param of
dma_slave_config.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Signed-off-by: Devendra K Verma <[email protected]>
---
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
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 31 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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().
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
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().
Quoted 6 lines
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Changes in v1
Changed the function return type for
dw_edma_get_phys_addr().
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Corrected the typo raised in review.
---
 drivers/dma/dw-edma/dw-edma-core.c    | 35
++++++++++++++-
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
 drivers/dma/dw-edma/dw-edma-core.h    |  1 +
 drivers/dma/dw-edma/dw-edma-pcie.c    | 44
++++++++++++----
Quoted 128 lines
Quoted 128 lines
--
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
 drivers/dma/dw-edma/dw-hdma-v0-core.c | 65
++++++++++++++++++++++++++- drivers/dma/dw-edma/dw-
hdma-
Quoted 41 lines
Quoted 41 lines
v0-
Quoted 40 lines
Quoted 40 lines
Quoted 27 lines
Quoted 20 lines
regs.h | 1 +
Quoted 10 lines
 include/linux/dma/edma.h              |  1 +
 6 files changed, 132 insertions(+), 15 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -0
index b43255f914f3..ef3d79a9f88d 100644
@@ -223,6 +223,31 @@ static int
dw_edma_device_config(struct
dma_chan *dchan,
drivers/dma/dw-edma/dw-edma-core.c
Quoted 7 lines
struct dma_slave_config *config) {
struct dw_edma_chan *chan =
dchan2dw_edma_chan(dchan);
drivers/dma/dw-edma/dw-edma-core.c +4 -0
+     int non_ll = 0;
+
+     chan->non_ll = false;
+     if (chan->dw->chip->mf == EDMA_MF_HDMA_NATIVE) {
Quoted 6 lines
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.
Quoted 3 lines
For the case of EDMA, the behavior is unchanged. Even if the config->peripheral_config param is set then it would be simply
ignored.
Quoted 9 lines
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
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
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.
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
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
        }
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
        ...
}
Add EDMA support no-ll mode is quite easily in future.
This looks reasonable provided that HDMA got the support for this
param.
Quoted 23 lines
Quoted 23 lines
Quoted 9 lines
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'
Quoted 13 lines
in the if() shall be sufficient.
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
drivers/dma/dw-edma/dw-edma-core.c +10 -0
+             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
Quoted 8 lines
Quoted 8 lines
the
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
drivers/dma/dw-edma/dw-edma-core.c
Quoted 4 lines
drivers/dma/dw-edma/dw-edma-core.c +4 -0
+              * default DMA ops will use the non-LL mode.
+              *
+              * Cases where LL mode is enabled and
+ client wants to use
the
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
+ * non-LL mode then also client can do
+ so via providing
the
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 9 lines
drivers/dma/dw-edma/dw-edma-core.c
Quoted 8 lines
drivers/dma/dw-edma/dw-edma-core.c +8 -0
+              * 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))
Quoted 3 lines
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.
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
This is API's callback, you can't assume caller do all correct things.
Quoted 2 lines
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.
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 24 lines
Quoted 8 lines
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
In the case where chan->dw->chip->non_ll = true, following case may
happen:
Quoted 5 lines
- 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
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
value is '0', in this case
Quoted 4 lines
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.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
When 'chan->dw->chip->non_ll = true' then this was added to make the chip usable when the LLP base addresses are not
configured.
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 2 lines
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
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
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
Quoted 10 lines
Quoted 10 lines
in
Quoted 8 lines
Quoted 4 lines
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?
Quoted 8 lines
Quoted 8 lines
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.
Quoted 126 lines
Quoted 43 lines
Quoted 6 lines
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.
Quoted 7 lines
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
Quoted 3 lines
user enables it via peripheral_config params.
- This addition, inadvertently, makes the DMA controller usable, for AMD
(Xilinx) only, when the LLP
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 1 line
Please let me know if this clarifies the doubt.
No API to get mode, only use set and test to know it.
Quoted 8 lines
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.
Quoted 72 lines
Quoted 41 lines
Quoted 41 lines
Quoted 26 lines
Quoted 26 lines
Quoted 9 lines
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.
Quoted 3 lines
Quoted 3 lines
drivers/dma/dw-edma/dw-edma-core.c +2 -0
+                     chan->non_ll = true;
+     }
...
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
(quoted diff) +0 -0
b/include/linux/dma/edma.h index
3080747689f6..78ce31b049ae
100644
include/linux/dma/edma.h +0 -0
@@ -99,6 +99,7 @@ struct dw_edma_chip {
      enum dw_edma_map_format mf;
 
Quoted 5 lines
Quoted 5 lines
include/linux/dma/edma.h struct dw_edma_chip { · line 102
Quoted 2 lines
include/linux/dma/edma.h +1 -0
      struct dw_edma          *dw;
+     bool                    non_ll;
Can you check ll_region directly? it should be equal to (ll_region->sz == 0)
?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 7 lines
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.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
This does not translate to support for non-LL mode. This brings the
ambiguity.
Quoted 3 lines
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().
Quoted 1 line
I request we shall retain the clarity here.
Quoted 8 lines
Quoted 3 lines
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

Quoted 7 lines

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

Quoted 12 lines

Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
include/linux/dma/edma.h +0 -1
 };
 
 /* Export to the platform drivers */
--
2.43.0

Frank Li

2026-02-24 22:27 UTC #15 lore raw

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

Quoted 12 lines · Devendra

[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 10 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode

...

Quoted 8 lines

Quoted 8 lines
Quoted 3 lines
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.

Quoted 6 lines

Quoted 2 lines
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

Quoted 16 lines

- Regards,
Devendra
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
};
/* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-02-25 12:06 UTC #16 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Quoted 47 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 25, 2026 3:58 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 12 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 10 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
...
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
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.

Quoted 6 lines

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!

Quoted 16 lines

Quoted 16 lines
- Regards,
Devendra
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
};
/* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-03-02 05:55 UTC #17 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Frank

Could you provide your inputs on this?

Regards,
Dev

Quoted 109 lines

-----Original Message-----
From: Verma, Devendra
Sent: Wednesday, February 25, 2026 5:36 PM
To: 'Frank Li' <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>; Verma, Devendra <[email protected]>
Subject: RE: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
Quoted 47 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 25, 2026 3:58 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 12 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 10 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
...
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
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!
Quoted 16 lines
Quoted 16 lines
- Regards,
Devendra
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
};
/* Export to the platform drivers */
--
2.43.0

Frank Li

2026-03-04 16:56 UTC #18 lore raw

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

In reply to Verma, Devendra

Quoted 64 lines · Devendra

[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 47 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 25, 2026 3:58 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 12 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 10 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
...
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
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.

Quoted 3 lines

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.

Quoted 5 lines

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

Quoted 27 lines

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!
Quoted 16 lines
Quoted 16 lines
- Regards,
Devendra
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
Quoted 6 lines
};
/* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-03-05 12:15 UTC #19 lore raw

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

[Public]

Quoted 79 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, March 4, 2026 10:26 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 64 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 47 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 25, 2026 3:58 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 12 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 10 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
...
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
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.

Quoted 8 lines

Quoted 3 lines
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.

Quoted 15 lines

Quoted 3 lines
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.
Quoted 2 lines
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.

Quoted 6 lines

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

Quoted 28 lines

Quoted 6 lines
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.
Quoted 21 lines
Please let me know your thoughts on this and lets conclude.
Thanks!
Quoted 16 lines
Quoted 16 lines
- Regards,
Devendra
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
};
/* Export to the platform drivers */
--
2.43.0

Frank Li

2026-03-05 16:03 UTC #20 lore raw

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

Quoted 116 lines · Devendra

[Public]
Quoted 79 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, March 4, 2026 10:26 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 64 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 47 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 25, 2026 3:58 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 12 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 10 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
...
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 20 lines
Quoted 3 lines
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.
Quoted 2 lines
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.

Quoted 6 lines

Quoted 1 line
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.

Quoted 7 lines

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.

Quoted 7 lines

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

Quoted 32 lines

Regards,
Devendra
Quoted 28 lines
Quoted 6 lines
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.
Quoted 21 lines
Please let me know your thoughts on this and lets conclude.
Thanks!
Quoted 16 lines
Quoted 16 lines
- Regards,
Devendra
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
};
/* Export to the platform drivers */
--
2.43.0

Verma, Devendra

author

2026-03-06 11:50 UTC #21 lore raw

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

[AMD Official Use Only - AMD Internal Distribution Only]

Quoted 142 lines

-----Original Message-----
From: Frank Li <[email protected]>
Sent: Thursday, March 5, 2026 9:34 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 31 lines · Devendra
[Public]
Quoted 29 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, March 4, 2026 10:26 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 14 lines · Devendra
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 12 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Wednesday, February 25, 2026 3:58 AM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.
Quoted 59 lines
Quoted 50 lines
Quoted 50 lines
Quoted 35 lines · Devendra
Quoted 12 lines
[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 10 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Friday, February 20, 2026 9:33 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
Subject: Re: [PATCH RESEND v10 2/2] dmaengine: dw-edma: Add non-LL mode
...
Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 13 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 10 lines
Quoted 10 lines
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.
Quoted 9 lines
Quoted 5 lines
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.
Quoted 1 line
dw_edma_chan: non_ll = true, it shall mean that individual channel is

Quoted 9 lines

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!

Quoted 14 lines

Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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

Quoted 9 lines

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).
Quoted 2 lines
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?

Quoted 35 lines

Frank
Quoted 33 lines
Regards,
Devendra
Quoted 29 lines
Quoted 7 lines
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.
Quoted 21 lines
Please let me know your thoughts on this and lets conclude.
Thanks!
Quoted 16 lines
Quoted 16 lines
- Regards,
Devendra
Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Frank
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Frank
};
/* Export to the platform drivers */
--
2.43.0

Frank Li

2026-03-06 18:01 UTC #22 lore raw

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

Quoted 16 lines · Devendra

[AMD Official Use Only - AMD Internal Distribution Only]
Quoted 14 lines
-----Original Message-----
From: Frank Li <[email protected]>
Sent: Thursday, March 5, 2026 9:34 PM
To: Verma, Devendra <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; linux- [email protected]; Simek, Michal <[email protected]>
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.

Quoted 5 lines

Quoted 3 lines
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