[PATCH v2 0/3] CPM6 Channel Separation Support

[PATCH v2 0/3] CPM6 Channel Separation Support

[Devendra K Verma]

'Designware Cores PCI Express DM Controller - Reference
Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
the channel separation mechanisms. Basically, the HDMA IP allows
the user to configure the separation between DMA channel
registers and retrieve it via the VSEC capability mentioned
above.
In order to use the VSEC functionality following changes have
been made:

o For Xilinx IP alone, the macros declared are made device
  name agnostic to expand the usage of macros for similar
  functionality.
o Utilize the existing VSEC implementation to retrieve
  the channel separation and translate it to correct size.
o Modify the structs and functions to calculate correct
  DMA channel register base using the channel, direction
  and channel separation selected.

Devendra K Verma (3):
  dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic
  dmaengine: dw-edma: Enable Chan Separation via VSEC
  dmaengine: dw-edma: Add changes to support Channel Separation

 drivers/dma/dw-edma/dw-edma-pcie.c           | 81 ++++++++++++--------
 drivers/dma/dw-edma/dw-hdma-v0-core.c        | 23 +++---
 drivers/dma/dw-edma/dw-hdma-v0-debugfs.c     | 17 ++--
 drivers/dma/dw-edma/dw-hdma-v0-regs.h        | 10 ---
 drivers/pci/controller/dwc/pcie-designware.c |  1 +
 include/linux/dma/edma.h                     |  1 +
 6 files changed, 72 insertions(+), 61 deletions(-)

-- 
2.43.0

[PATCH v2 1/3] dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic

[Devendra K Verma]

Xilinx specific macros for MDB device can be reused for the
Xilinx supported other similar IP such as CPM6.
Renamed the Xilinx specific macros in a way that can be
reused for Xilinx supported upcoming IP, CPM6.
Naming is in accordance with the naming done for Synopsys macros.

Signed-off-by: Devendra K Verma <devverma@amd.com>
---
Changes in v1:
   o No change
---
 drivers/dma/dw-edma/dw-edma-pcie.c | 58 +++++++++++++++---------------
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index 791c46e8ae4c..ec5e057a0f11 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -29,21 +29,21 @@
 #define PCI_DEVICE_ID_XILINX_B054		0xb054
 #define PCI_DEVICE_ID_XILINX_B00F		0xb00f
 
-#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_PCIE_XILINX_VSEC_DMA_ID		0x6
+#define DW_PCIE_XILINX_VSEC_ID			0x20
+#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
+#define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
+#define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
+#define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
+
+#define DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH	0xc
+#define DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW	0x8
+#define DW_PCIE_XILINX_INVALID_ADDR		(~0ULL)
+
+#define DW_PCIE_XILINX_LL_OFF_GAP		0x200000
+#define DW_PCIE_XILINX_LL_SIZE			0x800
+#define DW_PCIE_XILINX_DT_OFF_GAP		0x100000
+#define DW_PCIE_XILINX_DT_SIZE			0x800
 
 #define DW_BLOCK(a, b, c) \
 	{ \
@@ -258,10 +258,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
 	u16 vsec;
 	u64 off;
 
-	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
+	pdata->devmem_phys_off = DW_PCIE_XILINX_INVALID_ADDR;
 
 	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
-					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
+					DW_PCIE_XILINX_VSEC_DMA_ID);
 	if (!vsec)
 		return;
 
@@ -272,18 +272,18 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
 
 	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);
+	map = FIELD_GET(DW_PCIE_XILINX_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);
+	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
 
 	pci_read_config_dword(pdev, vsec + 0xc, &val);
 	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
-			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
+			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
 	pdata->rd_ch_cnt = min(pdata->rd_ch_cnt,
-			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
+			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_RD_CH, val));
 
 	pci_read_config_dword(pdev, vsec + 0x14, &val);
 	off = val;
@@ -293,16 +293,16 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
 	pdata->rg.off = off;
 
 	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
-					DW_PCIE_XILINX_MDB_VSEC_ID);
+					DW_PCIE_XILINX_VSEC_ID);
 	if (!vsec)
 		return;
 
 	pci_read_config_dword(pdev,
-			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
+			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH,
 			      &val);
 	off = val;
 	pci_read_config_dword(pdev,
-			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
+			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW,
 			      &val);
 	off <<= 32;
 	off |= val;
@@ -360,7 +360,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 		 * 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)
+		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_INVALID_ADDR)
 			non_ll = true;
 
 		/*
@@ -370,10 +370,10 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 		 */
 		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);
+						       DW_PCIE_XILINX_LL_OFF_GAP,
+						       DW_PCIE_XILINX_LL_SIZE,
+						       DW_PCIE_XILINX_DT_OFF_GAP,
+						       DW_PCIE_XILINX_DT_SIZE);
 	}
 
 	/* Mapping PCI BAR regions */
-- 
2.43.0

Re: [PATCH v2 1/3] dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic

[sashiko-bot]

> Xilinx specific macros for MDB device can be reused for the
> Xilinx supported other similar IP such as CPM6.
> Renamed the Xilinx specific macros in a way that can be
> reused for Xilinx supported upcoming IP, CPM6.
> Naming is in accordance with the naming done for Synopsys macros.
> 
> Signed-off-by: Devendra K Verma <devverma@amd.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728091744.1086942-1-devverma@amd.com?part=1

Re: [PATCH v2 1/3] dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic

[Frank Li]

On Tue, Jul 28, 2026 at 02:47:42PM +0530, Devendra K Verma wrote:
> Xilinx specific macros for MDB device can be reused for the
> Xilinx supported other similar IP such as CPM6.
> Renamed the Xilinx specific macros in a way that can be
> reused for Xilinx supported upcoming IP, CPM6.
> Naming is in accordance with the naming done for Synopsys macros.
>
> Signed-off-by: Devendra K Verma <devverma@amd.com>
> ---
> Changes in v1:
>    o No change
> ---
>  drivers/dma/dw-edma/dw-edma-pcie.c | 58 +++++++++++++++---------------
>  1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index 791c46e8ae4c..ec5e057a0f11 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> @@ -29,21 +29,21 @@
>  #define PCI_DEVICE_ID_XILINX_B054		0xb054
>  #define PCI_DEVICE_ID_XILINX_B00F		0xb00f
>
> -#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_PCIE_XILINX_VSEC_DMA_ID		0x6
> +#define DW_PCIE_XILINX_VSEC_ID			0x20
> +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> +#define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
> +#define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
> +#define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)

v1, you agree keep use old MDB ?

Frank


> +
> +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH	0xc
> +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW	0x8
> +#define DW_PCIE_XILINX_INVALID_ADDR		(~0ULL)
> +
> +#define DW_PCIE_XILINX_LL_OFF_GAP		0x200000
> +#define DW_PCIE_XILINX_LL_SIZE			0x800
> +#define DW_PCIE_XILINX_DT_OFF_GAP		0x100000
> +#define DW_PCIE_XILINX_DT_SIZE			0x800
>
>  #define DW_BLOCK(a, b, c) \
>  	{ \
> @@ -258,10 +258,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>  	u16 vsec;
>  	u64 off;
>
> -	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
> +	pdata->devmem_phys_off = DW_PCIE_XILINX_INVALID_ADDR;
>
>  	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> -					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
> +					DW_PCIE_XILINX_VSEC_DMA_ID);
>  	if (!vsec)
>  		return;
>
> @@ -272,18 +272,18 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>
>  	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);
> +	map = FIELD_GET(DW_PCIE_XILINX_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);
> +	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>
>  	pci_read_config_dword(pdev, vsec + 0xc, &val);
>  	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
> -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
> +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
>  	pdata->rd_ch_cnt = min(pdata->rd_ch_cnt,
> -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
> +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_RD_CH, val));
>
>  	pci_read_config_dword(pdev, vsec + 0x14, &val);
>  	off = val;
> @@ -293,16 +293,16 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>  	pdata->rg.off = off;
>
>  	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> -					DW_PCIE_XILINX_MDB_VSEC_ID);
> +					DW_PCIE_XILINX_VSEC_ID);
>  	if (!vsec)
>  		return;
>
>  	pci_read_config_dword(pdev,
> -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
> +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH,
>  			      &val);
>  	off = val;
>  	pci_read_config_dword(pdev,
> -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
> +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW,
>  			      &val);
>  	off <<= 32;
>  	off |= val;
> @@ -360,7 +360,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  		 * 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)
> +		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_INVALID_ADDR)
>  			non_ll = true;
>
>  		/*
> @@ -370,10 +370,10 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  		 */
>  		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);
> +						       DW_PCIE_XILINX_LL_OFF_GAP,
> +						       DW_PCIE_XILINX_LL_SIZE,
> +						       DW_PCIE_XILINX_DT_OFF_GAP,
> +						       DW_PCIE_XILINX_DT_SIZE);
>  	}
>
>  	/* Mapping PCI BAR regions */
> --
> 2.43.0
>

Re: [PATCH v2 1/3] dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic

[Verma, Devendra]

On 28-Jul-26 21:01, Frank Li wrote:
> On Tue, Jul 28, 2026 at 02:47:42PM +0530, Devendra K Verma wrote:
>> Xilinx specific macros for MDB device can be reused for the
>> Xilinx supported other similar IP such as CPM6.
>> Renamed the Xilinx specific macros in a way that can be
>> reused for Xilinx supported upcoming IP, CPM6.
>> Naming is in accordance with the naming done for Synopsys macros.
>>
>> Signed-off-by: Devendra K Verma <devverma@amd.com>
>> ---
>> Changes in v1:
>>     o No change
>> ---
>>   drivers/dma/dw-edma/dw-edma-pcie.c | 58 +++++++++++++++---------------
>>   1 file changed, 29 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
>> index 791c46e8ae4c..ec5e057a0f11 100644
>> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
>> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
>> @@ -29,21 +29,21 @@
>>   #define PCI_DEVICE_ID_XILINX_B054		0xb054
>>   #define PCI_DEVICE_ID_XILINX_B00F		0xb00f
>>
>> -#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_PCIE_XILINX_VSEC_DMA_ID		0x6
>> +#define DW_PCIE_XILINX_VSEC_ID			0x20
>> +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>> +#define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
>> +#define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
>> +#define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
> 
> v1, you agree keep use old MDB ?
> 
> Frank
> 

I followed the suggestion you provided at the given link at the end.
Talking of Xilinx based devices, the channel separation is fixed for MDB
but not for CPM6. So, I have have renamed the specific functionality
specific to CPM6 in 2/3 of the same patch series.

This one cleans up the MDB references and makes the functionality 
generic for all the Xilinx devices.

Suggestion: https://lore.kernel.org/all/amI09ZcfhX4SEPIH@SMW015318/

CPM6 specific declaration:
https://lore.kernel.org/all/20260728091744.1086942-3-devverma@amd.com/

- Devendra

> 
>> +
>> +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH	0xc
>> +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW	0x8
>> +#define DW_PCIE_XILINX_INVALID_ADDR		(~0ULL)
>> +
>> +#define DW_PCIE_XILINX_LL_OFF_GAP		0x200000
>> +#define DW_PCIE_XILINX_LL_SIZE			0x800
>> +#define DW_PCIE_XILINX_DT_OFF_GAP		0x100000
>> +#define DW_PCIE_XILINX_DT_SIZE			0x800
>>
>>   #define DW_BLOCK(a, b, c) \
>>   	{ \
>> @@ -258,10 +258,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>   	u16 vsec;
>>   	u64 off;
>>
>> -	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
>> +	pdata->devmem_phys_off = DW_PCIE_XILINX_INVALID_ADDR;
>>
>>   	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
>> -					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
>> +					DW_PCIE_XILINX_VSEC_DMA_ID);
>>   	if (!vsec)
>>   		return;
>>
>> @@ -272,18 +272,18 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>
>>   	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);
>> +	map = FIELD_GET(DW_PCIE_XILINX_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);
>> +	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>>
>>   	pci_read_config_dword(pdev, vsec + 0xc, &val);
>>   	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>> -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
>> +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
>>   	pdata->rd_ch_cnt = min(pdata->rd_ch_cnt,
>> -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
>> +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_RD_CH, val));
>>
>>   	pci_read_config_dword(pdev, vsec + 0x14, &val);
>>   	off = val;
>> @@ -293,16 +293,16 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>   	pdata->rg.off = off;
>>
>>   	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
>> -					DW_PCIE_XILINX_MDB_VSEC_ID);
>> +					DW_PCIE_XILINX_VSEC_ID);
>>   	if (!vsec)
>>   		return;
>>
>>   	pci_read_config_dword(pdev,
>> -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
>> +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH,
>>   			      &val);
>>   	off = val;
>>   	pci_read_config_dword(pdev,
>> -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
>> +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW,
>>   			      &val);
>>   	off <<= 32;
>>   	off |= val;
>> @@ -360,7 +360,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>   		 * 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)
>> +		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_INVALID_ADDR)
>>   			non_ll = true;
>>
>>   		/*
>> @@ -370,10 +370,10 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>   		 */
>>   		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);
>> +						       DW_PCIE_XILINX_LL_OFF_GAP,
>> +						       DW_PCIE_XILINX_LL_SIZE,
>> +						       DW_PCIE_XILINX_DT_OFF_GAP,
>> +						       DW_PCIE_XILINX_DT_SIZE);
>>   	}
>>
>>   	/* Mapping PCI BAR regions */
>> --
>> 2.43.0
>>

Re: [PATCH v2 1/3] dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic

[Frank Li]

On Fri, Jul 31, 2026 at 09:54:01PM +0530, Verma, Devendra wrote:
>
>
> On 28-Jul-26 21:01, Frank Li wrote:
> > On Tue, Jul 28, 2026 at 02:47:42PM +0530, Devendra K Verma wrote:
> > > Xilinx specific macros for MDB device can be reused for the
> > > Xilinx supported other similar IP such as CPM6.
> > > Renamed the Xilinx specific macros in a way that can be
> > > reused for Xilinx supported upcoming IP, CPM6.
> > > Naming is in accordance with the naming done for Synopsys macros.
> > >
> > > Signed-off-by: Devendra K Verma <devverma@amd.com>
> > > ---
> > > Changes in v1:
> > >     o No change
> > > ---
> > >   drivers/dma/dw-edma/dw-edma-pcie.c | 58 +++++++++++++++---------------
> > >   1 file changed, 29 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > index 791c46e8ae4c..ec5e057a0f11 100644
> > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > @@ -29,21 +29,21 @@
> > >   #define PCI_DEVICE_ID_XILINX_B054		0xb054
> > >   #define PCI_DEVICE_ID_XILINX_B00F		0xb00f
> > >
> > > -#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_PCIE_XILINX_VSEC_DMA_ID		0x6
> > > +#define DW_PCIE_XILINX_VSEC_ID			0x20
> > > +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > > +#define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
> > > +#define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
> > > +#define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
> >
> > v1, you agree keep use old MDB ?
> >
> > Frank
> >
>
> I followed the suggestion you provided at the given link at the end.
> Talking of Xilinx based devices, the channel separation is fixed for MDB
> but not for CPM6. So, I have have renamed the specific functionality
> specific to CPM6 in 2/3 of the same patch series.
>
> This one cleans up the MDB references and makes the functionality generic
> for all the Xilinx devices.
>
> Suggestion: https://lore.kernel.org/all/amI09ZcfhX4SEPIH@SMW015318/

Maybe I have not said cleanly

Actually you only need add one macro to for CPM6, other use MDB macro can
work well.

#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP                GENMASK(18, 16)

These rename are totally unnecessary.  It is quite popular that new chip
reuse old chip's register name.

We rename it utils we really can't handle these without rename.

Frank

>
> CPM6 specific declaration:
> https://lore.kernel.org/all/20260728091744.1086942-3-devverma@amd.com/
>
> - Devendra
>
> >
> > > +
> > > +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH	0xc
> > > +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW	0x8
> > > +#define DW_PCIE_XILINX_INVALID_ADDR		(~0ULL)
> > > +
> > > +#define DW_PCIE_XILINX_LL_OFF_GAP		0x200000
> > > +#define DW_PCIE_XILINX_LL_SIZE			0x800
> > > +#define DW_PCIE_XILINX_DT_OFF_GAP		0x100000
> > > +#define DW_PCIE_XILINX_DT_SIZE			0x800
> > >
> > >   #define DW_BLOCK(a, b, c) \
> > >   	{ \
> > > @@ -258,10 +258,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > >   	u16 vsec;
> > >   	u64 off;
> > >
> > > -	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
> > > +	pdata->devmem_phys_off = DW_PCIE_XILINX_INVALID_ADDR;
> > >
> > >   	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> > > -					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
> > > +					DW_PCIE_XILINX_VSEC_DMA_ID);
> > >   	if (!vsec)
> > >   		return;
> > >
> > > @@ -272,18 +272,18 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > >
> > >   	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);
> > > +	map = FIELD_GET(DW_PCIE_XILINX_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);
> > > +	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
> > >
> > >   	pci_read_config_dword(pdev, vsec + 0xc, &val);
> > >   	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
> > > -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
> > > +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
> > >   	pdata->rd_ch_cnt = min(pdata->rd_ch_cnt,
> > > -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
> > > +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_RD_CH, val));
> > >
> > >   	pci_read_config_dword(pdev, vsec + 0x14, &val);
> > >   	off = val;
> > > @@ -293,16 +293,16 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > >   	pdata->rg.off = off;
> > >
> > >   	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> > > -					DW_PCIE_XILINX_MDB_VSEC_ID);
> > > +					DW_PCIE_XILINX_VSEC_ID);
> > >   	if (!vsec)
> > >   		return;
> > >
> > >   	pci_read_config_dword(pdev,
> > > -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
> > > +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH,
> > >   			      &val);
> > >   	off = val;
> > >   	pci_read_config_dword(pdev,
> > > -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
> > > +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW,
> > >   			      &val);
> > >   	off <<= 32;
> > >   	off |= val;
> > > @@ -360,7 +360,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> > >   		 * 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)
> > > +		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_INVALID_ADDR)
> > >   			non_ll = true;
> > >
> > >   		/*
> > > @@ -370,10 +370,10 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> > >   		 */
> > >   		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);
> > > +						       DW_PCIE_XILINX_LL_OFF_GAP,
> > > +						       DW_PCIE_XILINX_LL_SIZE,
> > > +						       DW_PCIE_XILINX_DT_OFF_GAP,
> > > +						       DW_PCIE_XILINX_DT_SIZE);
> > >   	}
> > >
> > >   	/* Mapping PCI BAR regions */
> > > --
> > > 2.43.0
> > >
>

Re: [PATCH v2 1/3] dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic

[Verma, Devendra]

On 01-Aug-26 00:50, Frank Li wrote:
> On Fri, Jul 31, 2026 at 09:54:01PM +0530, Verma, Devendra wrote:
>>
>>
>> On 28-Jul-26 21:01, Frank Li wrote:
>>> On Tue, Jul 28, 2026 at 02:47:42PM +0530, Devendra K Verma wrote:
>>>> Xilinx specific macros for MDB device can be reused for the
>>>> Xilinx supported other similar IP such as CPM6.
>>>> Renamed the Xilinx specific macros in a way that can be
>>>> reused for Xilinx supported upcoming IP, CPM6.
>>>> Naming is in accordance with the naming done for Synopsys macros.
>>>>
>>>> Signed-off-by: Devendra K Verma <devverma@amd.com>
>>>> ---
>>>> Changes in v1:
>>>>      o No change
>>>> ---
>>>>    drivers/dma/dw-edma/dw-edma-pcie.c | 58 +++++++++++++++---------------
>>>>    1 file changed, 29 insertions(+), 29 deletions(-)
>>>>
>>>> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> index 791c46e8ae4c..ec5e057a0f11 100644
>>>> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> @@ -29,21 +29,21 @@
>>>>    #define PCI_DEVICE_ID_XILINX_B054		0xb054
>>>>    #define PCI_DEVICE_ID_XILINX_B00F		0xb00f
>>>>
>>>> -#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_PCIE_XILINX_VSEC_DMA_ID		0x6
>>>> +#define DW_PCIE_XILINX_VSEC_ID			0x20
>>>> +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>>>> +#define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
>>>> +#define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
>>>> +#define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
>>>
>>> v1, you agree keep use old MDB ?
>>>
>>> Frank
>>>
>>
>> I followed the suggestion you provided at the given link at the end.
>> Talking of Xilinx based devices, the channel separation is fixed for MDB
>> but not for CPM6. So, I have have renamed the specific functionality
>> specific to CPM6 in 2/3 of the same patch series.
>>
>> This one cleans up the MDB references and makes the functionality generic
>> for all the Xilinx devices.
>>
>> Suggestion: https://lore.kernel.org/all/amI09ZcfhX4SEPIH@SMW015318/
> 
> Maybe I have not said cleanly
> 
> Actually you only need add one macro to for CPM6, other use MDB macro can
> work well.
> 
> #define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP                GENMASK(18, 16)
> 
> These rename are totally unnecessary.  It is quite popular that new chip
> reuse old chip's register name.
> 
> We rename it utils we really can't handle these without rename.

You have pointed out the issue in the last line. For the upcoming
support we anticipated that it would be messy to use the MDB related
stuff for CPM6 and that's why wanted to clean it before introducing
functionality for CPM6.

The MDB works, no denying, but mixing the two creates confusion and
requires the understanding of MDB first and CPM6. For that reason
the clean approach taken is:
- Add the generic functionality supported by MDB and CPM6 under the
   name Xilinx
- Add the MDB and CPM6 specific functionality with their own
   associated names, keeping it clean.

- Devendra>
> Frank
> 
>>
>> CPM6 specific declaration:
>> https://lore.kernel.org/all/20260728091744.1086942-3-devverma@amd.com/
>>
>> - Devendra
>>
>>>
>>>> +
>>>> +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH	0xc
>>>> +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW	0x8
>>>> +#define DW_PCIE_XILINX_INVALID_ADDR		(~0ULL)
>>>> +
>>>> +#define DW_PCIE_XILINX_LL_OFF_GAP		0x200000
>>>> +#define DW_PCIE_XILINX_LL_SIZE			0x800
>>>> +#define DW_PCIE_XILINX_DT_OFF_GAP		0x100000
>>>> +#define DW_PCIE_XILINX_DT_SIZE			0x800
>>>>
>>>>    #define DW_BLOCK(a, b, c) \
>>>>    	{ \
>>>> @@ -258,10 +258,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>>>    	u16 vsec;
>>>>    	u64 off;
>>>>
>>>> -	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
>>>> +	pdata->devmem_phys_off = DW_PCIE_XILINX_INVALID_ADDR;
>>>>
>>>>    	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
>>>> -					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
>>>> +					DW_PCIE_XILINX_VSEC_DMA_ID);
>>>>    	if (!vsec)
>>>>    		return;
>>>>
>>>> @@ -272,18 +272,18 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>>>
>>>>    	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);
>>>> +	map = FIELD_GET(DW_PCIE_XILINX_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);
>>>> +	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>>>>
>>>>    	pci_read_config_dword(pdev, vsec + 0xc, &val);
>>>>    	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>>>> -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
>>>> +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
>>>>    	pdata->rd_ch_cnt = min(pdata->rd_ch_cnt,
>>>> -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
>>>> +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_RD_CH, val));
>>>>
>>>>    	pci_read_config_dword(pdev, vsec + 0x14, &val);
>>>>    	off = val;
>>>> @@ -293,16 +293,16 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>>>    	pdata->rg.off = off;
>>>>
>>>>    	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
>>>> -					DW_PCIE_XILINX_MDB_VSEC_ID);
>>>> +					DW_PCIE_XILINX_VSEC_ID);
>>>>    	if (!vsec)
>>>>    		return;
>>>>
>>>>    	pci_read_config_dword(pdev,
>>>> -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
>>>> +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH,
>>>>    			      &val);
>>>>    	off = val;
>>>>    	pci_read_config_dword(pdev,
>>>> -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
>>>> +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW,
>>>>    			      &val);
>>>>    	off <<= 32;
>>>>    	off |= val;
>>>> @@ -360,7 +360,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>>>    		 * 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)
>>>> +		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_INVALID_ADDR)
>>>>    			non_ll = true;
>>>>
>>>>    		/*
>>>> @@ -370,10 +370,10 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>>>    		 */
>>>>    		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);
>>>> +						       DW_PCIE_XILINX_LL_OFF_GAP,
>>>> +						       DW_PCIE_XILINX_LL_SIZE,
>>>> +						       DW_PCIE_XILINX_DT_OFF_GAP,
>>>> +						       DW_PCIE_XILINX_DT_SIZE);
>>>>    	}
>>>>
>>>>    	/* Mapping PCI BAR regions */
>>>> --
>>>> 2.43.0
>>>>
>>

Re: [PATCH v2 1/3] dmaengine: dw-edma: Make Xilinx Macros Dev Name Agnostic

[Frank Li]

On Mon, Aug 03, 2026 at 05:45:14PM +0530, Verma, Devendra wrote:
>
> On 01-Aug-26 00:50, Frank Li wrote:
> > On Fri, Jul 31, 2026 at 09:54:01PM +0530, Verma, Devendra wrote:
> > >
> > >
> > > On 28-Jul-26 21:01, Frank Li wrote:
> > > > On Tue, Jul 28, 2026 at 02:47:42PM +0530, Devendra K Verma wrote:
> > > > > Xilinx specific macros for MDB device can be reused for the
> > > > > Xilinx supported other similar IP such as CPM6.
> > > > > Renamed the Xilinx specific macros in a way that can be
> > > > > reused for Xilinx supported upcoming IP, CPM6.
> > > > > Naming is in accordance with the naming done for Synopsys macros.
> > > > >
> > > > > Signed-off-by: Devendra K Verma <devverma@amd.com>
> > > > > ---
> > > > > Changes in v1:
> > > > >      o No change
> > > > > ---
> > > > >    drivers/dma/dw-edma/dw-edma-pcie.c | 58 +++++++++++++++---------------
> > > > >    1 file changed, 29 insertions(+), 29 deletions(-)
> > > > >
> > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > index 791c46e8ae4c..ec5e057a0f11 100644
> > > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > @@ -29,21 +29,21 @@
> > > > >    #define PCI_DEVICE_ID_XILINX_B054		0xb054
> > > > >    #define PCI_DEVICE_ID_XILINX_B00F		0xb00f
> > > > >
> > > > > -#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_PCIE_XILINX_VSEC_DMA_ID		0x6
> > > > > +#define DW_PCIE_XILINX_VSEC_ID			0x20
> > > > > +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > > > > +#define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
> > > > > +#define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
> > > > > +#define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
> > > >
> > > > v1, you agree keep use old MDB ?
> > > >
> > > > Frank
> > > >
> > >
> > > I followed the suggestion you provided at the given link at the end.
> > > Talking of Xilinx based devices, the channel separation is fixed for MDB
> > > but not for CPM6. So, I have have renamed the specific functionality
> > > specific to CPM6 in 2/3 of the same patch series.
> > >
> > > This one cleans up the MDB references and makes the functionality generic
> > > for all the Xilinx devices.
> > >
> > > Suggestion: https://lore.kernel.org/all/amI09ZcfhX4SEPIH@SMW015318/
> >
> > Maybe I have not said cleanly
> >
> > Actually you only need add one macro to for CPM6, other use MDB macro can
> > work well.
> >
> > #define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP                GENMASK(18, 16)
> >
> > These rename are totally unnecessary.  It is quite popular that new chip
> > reuse old chip's register name.
> >
> > We rename it utils we really can't handle these without rename.
>
> You have pointed out the issue in the last line. For the upcoming
> support we anticipated that it would be messy to use the MDB related
> stuff for CPM6 and that's why wanted to clean it before introducing
> functionality for CPM6.

Do it only when have to do that. Now only add one macro
DW_PCIE_XILINX_CPM6_VSEC_CH_SEP to support CPM6.

The prefix "DW_PCIE_XILINX_MDB" and "DW_PCIE_XILINX_VSEC" have not bring
much information,

The most important part following part after it.

Frank

>
> The MDB works, no denying, but mixing the two creates confusion and
> requires the understanding of MDB first and CPM6. For that reason
> the clean approach taken is:
> - Add the generic functionality supported by MDB and CPM6 under the
>   name Xilinx
> - Add the MDB and CPM6 specific functionality with their own
>   associated names, keeping it clean.
>
> - Devendra>
> > Frank
> >
> > >
> > > CPM6 specific declaration:
> > > https://lore.kernel.org/all/20260728091744.1086942-3-devverma@amd.com/
> > >
> > > - Devendra
> > >
> > > >
> > > > > +
> > > > > +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH	0xc
> > > > > +#define DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW	0x8
> > > > > +#define DW_PCIE_XILINX_INVALID_ADDR		(~0ULL)
> > > > > +
> > > > > +#define DW_PCIE_XILINX_LL_OFF_GAP		0x200000
> > > > > +#define DW_PCIE_XILINX_LL_SIZE			0x800
> > > > > +#define DW_PCIE_XILINX_DT_OFF_GAP		0x100000
> > > > > +#define DW_PCIE_XILINX_DT_SIZE			0x800
> > > > >
> > > > >    #define DW_BLOCK(a, b, c) \
> > > > >    	{ \
> > > > > @@ -258,10 +258,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > > > >    	u16 vsec;
> > > > >    	u64 off;
> > > > >
> > > > > -	pdata->devmem_phys_off = DW_PCIE_XILINX_MDB_INVALID_ADDR;
> > > > > +	pdata->devmem_phys_off = DW_PCIE_XILINX_INVALID_ADDR;
> > > > >
> > > > >    	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> > > > > -					DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
> > > > > +					DW_PCIE_XILINX_VSEC_DMA_ID);
> > > > >    	if (!vsec)
> > > > >    		return;
> > > > >
> > > > > @@ -272,18 +272,18 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > > > >
> > > > >    	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);
> > > > > +	map = FIELD_GET(DW_PCIE_XILINX_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);
> > > > > +	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
> > > > >
> > > > >    	pci_read_config_dword(pdev, vsec + 0xc, &val);
> > > > >    	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
> > > > > -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_WR_CH, val));
> > > > > +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
> > > > >    	pdata->rd_ch_cnt = min(pdata->rd_ch_cnt,
> > > > > -			       FIELD_GET(DW_PCIE_XILINX_MDB_VSEC_DMA_RD_CH, val));
> > > > > +			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_RD_CH, val));
> > > > >
> > > > >    	pci_read_config_dword(pdev, vsec + 0x14, &val);
> > > > >    	off = val;
> > > > > @@ -293,16 +293,16 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > > > >    	pdata->rg.off = off;
> > > > >
> > > > >    	vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
> > > > > -					DW_PCIE_XILINX_MDB_VSEC_ID);
> > > > > +					DW_PCIE_XILINX_VSEC_ID);
> > > > >    	if (!vsec)
> > > > >    		return;
> > > > >
> > > > >    	pci_read_config_dword(pdev,
> > > > > -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_HIGH,
> > > > > +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_HIGH,
> > > > >    			      &val);
> > > > >    	off = val;
> > > > >    	pci_read_config_dword(pdev,
> > > > > -			      vsec + DW_PCIE_XILINX_MDB_DEVMEM_OFF_REG_LOW,
> > > > > +			      vsec + DW_PCIE_XILINX_DEVMEM_OFF_REG_LOW,
> > > > >    			      &val);
> > > > >    	off <<= 32;
> > > > >    	off |= val;
> > > > > @@ -360,7 +360,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> > > > >    		 * 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)
> > > > > +		if (vsec_data->devmem_phys_off == DW_PCIE_XILINX_INVALID_ADDR)
> > > > >    			non_ll = true;
> > > > >
> > > > >    		/*
> > > > > @@ -370,10 +370,10 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> > > > >    		 */
> > > > >    		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);
> > > > > +						       DW_PCIE_XILINX_LL_OFF_GAP,
> > > > > +						       DW_PCIE_XILINX_LL_SIZE,
> > > > > +						       DW_PCIE_XILINX_DT_OFF_GAP,
> > > > > +						       DW_PCIE_XILINX_DT_SIZE);
> > > > >    	}
> > > > >
> > > > >    	/* Mapping PCI BAR regions */
> > > > > --
> > > > > 2.43.0
> > > > >
> > >
>

[PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Devendra K Verma]

As per, 'Designware Cores PCI Express DM Controller - Reference
Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
the channel separation mechanisms. Basically, the HDMA IP allows
the user to configure the separation between DMA channel
registers and retrieve it via the VSEC capability mentioned
above.

HDMA IP supports the channel register space separation from
256B to 32KB. Default supported size is 256B.

Signed-off-by: Devendra K Verma <devverma@amd.com>
---
Changes in v1:
   o Modified dw_edma_get_ch_sep_sz() as per review comment.
     The function now supports ch_sep_sz up to 32KB.
   o Updated to description to reflect the supported channel
     separation sizes.
   o Introduced the CPM6 specific macro for VSEC cap.
---
 drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index ec5e057a0f11..d0f209082878 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -31,8 +31,11 @@
 
 #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
 #define DW_PCIE_XILINX_VSEC_ID			0x20
-#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
 #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
+#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
+/* AMD CPM6 (Xilinx) supported cap */
+#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
+
 #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
 #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
 
@@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
 	u16				wr_ch_cnt;
 	u16				rd_ch_cnt;
 	u64				devmem_phys_off;
+	u32				ch_sep_sz;
 };
 
 static const struct dw_edma_pcie_data snps_edda_data = {
@@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
 };
 
 static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
-	/* MDB registers location */
+	/* CPM6 registers location */
 	.rg.bar				= BAR_0,
 	.rg.off				= SZ_4K,	/*  4 Kbytes */
 	.rg.sz				= SZ_8K,	/*  8 Kbytes */
@@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
 	return pci_irq_vector(to_pci_dev(dev), nr);
 }
 
+static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
+{
+	if (ch_sep_val > 0 && ch_sep_val <= 7)
+		return 256 << ch_sep_val;
+	return 256;
+}
+
 static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
 {
 	struct pci_dev *pdev = to_pci_dev(dev);
@@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
 	pdata->mf = map;
 	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
 
+	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
+		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
+								   val));
+
 	pci_read_config_dword(pdev, vsec + 0xc, &val);
 	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
 			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
@@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
 	struct device *dev = &pdev->dev;
 	struct dw_edma_chip *chip;
+	bool non_ll = false;
 	int err, nr_irqs;
 	int i, mask;
-	bool non_ll = false;
 
 	if (!pdata)
 		return -ENODEV;
-- 
2.43.0

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] The claimed 'Channel Separation' feature is completely unused and dead code, failing to pass the parsed separation size to the core DMA driver and causing hardware register offset mismatches on non-default configurations.
- [Medium] The `ch_sep_sz` field defaults to 0 for non-XILINX_B00F devices, violating the 256B default size specification.

Pre-existing issues:
- [High] Double free risk of IRQ vectors due to mixing managed `pcim_enable_device()` with manual `pci_free_irq_vectors()`.
--

--- Patch [2]: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC ---
commit c9662ac63af55f746e4aad35cf3b04bea4688738
Author: Devendra K Verma <devverma@amd.com>

dmaengine: dw-edma: Enable Chan Separation via VSEC

As per, 'Designware Cores PCI Express DM Controller - Reference
Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
the channel separation mechanisms. Basically, the HDMA IP allows
the user to configure the separation between DMA channel
registers and retrieve it via the VSEC capability mentioned
above.

> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index ec5e057a0f11b..d0f209082878d 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c

[ ... ]

> @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
>  	u16				wr_ch_cnt;
>  	u16				rd_ch_cnt;
>  	u64				devmem_phys_off;
> +	u32				ch_sep_sz;

[Severity: Medium]
Does this new field need to be initialized in the existing static
configuration structures?

For example, snps_edda_data and xilinx_mdb_data are not updated in this
patch to set ch_sep_sz. Because they are static structs, ch_sep_sz will
default to 0 for non-XILINX_B00F devices.

If ch_sep_sz is passed to the core driver, would a 0-byte separation cause
all channels to overlap in memory, violating the 256B default size
specification?

>  };
>  
>  static const struct dw_edma_pcie_data snps_edda_data = {

[ ... ]

> @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>  	pdata->mf = map;
>  	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>  
> +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
> +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
> +								   val));
> +

[Severity: High]
Is the parsed channel separation size actually used by the core driver?

It looks like ch_sep_sz is populated in vsec_data here, but is never
passed to the core DMA driver in dw_edma_pcie_probe():

drivers/dma/dw-edma/dw-edma-pcie.c:dw_edma_pcie_probe() {
    ...
    chip->mf = vsec_data->mf;
    chip->nr_irqs = nr_irqs;
    chip->ops = &dw_edma_pcie_plat_ops;
    chip->cfg_non_ll = non_ll;
    chip->ll_wr_cnt = vsec_data->wr_ch_cnt;
    ...
}

Additionally, does the core driver support this dynamic separation? Looking at
__dw_ch_regs() in dw-hdma-v0-core.c, the channel register offsets appear to be
calculated using fixed C structure array indexing:

    if (dir == EDMA_DIR_WRITE)
        return &(__dw_regs(dw)->ch[ch].wr);
    else
        return &(__dw_regs(dw)->ch[ch].rd);

If a 32KB separation is configured, wouldn't the core driver still calculate
MMIO offsets assuming the hardcoded structure layout, potentially reading or
writing incorrect PCI memory on non-default configurations?

>  	pci_read_config_dword(pdev, vsec + 0xc, &val);

[ ... ]

> @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
>  	struct device *dev = &pdev->dev;
>  	struct dw_edma_chip *chip;
> +	bool non_ll = false;
>  	int err, nr_irqs;
>  	int i, mask;
> -	bool non_ll = false;
>  

[Severity: High]
This is a pre-existing issue, but I noticed a potential double free of the
IRQ vectors related to the device probing.

When pcim_enable_device() is used, IRQ allocations via
pci_alloc_irq_vectors() are managed by devres and automatically freed.

However, looking at the remove path in dw_edma_pcie_remove():

    /* Freeing IRQs */
    pci_free_irq_vectors(pdev);

Does calling pci_free_irq_vectors() manually conflict with the devres cleanup
registered automatically by pcim_enable_device(), leading to a double free
when the driver is unbound or fails to probe?

>  	if (!pdata)
>  		return -ENODEV;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728091744.1086942-1-devverma@amd.com?part=2

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Frank Li]

On Tue, Jul 28, 2026 at 02:47:43PM +0530, Devendra K Verma wrote:
> As per, 'Designware Cores PCI Express DM Controller - Reference
> Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
> the channel separation mechanisms. Basically, the HDMA IP allows
> the user to configure the separation between DMA channel
> registers and retrieve it via the VSEC capability mentioned
> above.
>
> HDMA IP supports the channel register space separation from
> 256B to 32KB. Default supported size is 256B.
>
> Signed-off-by: Devendra K Verma <devverma@amd.com>
> ---
> Changes in v1:
>    o Modified dw_edma_get_ch_sep_sz() as per review comment.
>      The function now supports ch_sep_sz up to 32KB.
>    o Updated to description to reflect the supported channel
>      separation sizes.
>    o Introduced the CPM6 specific macro for VSEC cap.
> ---
>  drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index ec5e057a0f11..d0f209082878 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> @@ -31,8 +31,11 @@
>
>  #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
>  #define DW_PCIE_XILINX_VSEC_ID			0x20
> -#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>  #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
> +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> +/* AMD CPM6 (Xilinx) supported cap */
> +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
> +
>  #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
>  #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
>
> @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
>  	u16				wr_ch_cnt;
>  	u16				rd_ch_cnt;
>  	u64				devmem_phys_off;
> +	u32				ch_sep_sz;

ch_space_sz?

>  };
>
>  static const struct dw_edma_pcie_data snps_edda_data = {
> @@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
>  };
>
>  static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
> -	/* MDB registers location */
> +	/* CPM6 registers location */
>  	.rg.bar				= BAR_0,
>  	.rg.off				= SZ_4K,	/*  4 Kbytes */
>  	.rg.sz				= SZ_8K,	/*  8 Kbytes */
> @@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
>  	return pci_irq_vector(to_pci_dev(dev), nr);
>  }
>
> +static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
> +{
> +	if (ch_sep_val > 0 && ch_sep_val <= 7)
> +		return 256 << ch_sep_val;
> +	return 256;
> +}
> +
>  static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
>  {
>  	struct pci_dev *pdev = to_pci_dev(dev);
> @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>  	pdata->mf = map;
>  	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>
> +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
> +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
> +								   val));
> +
>  	pci_read_config_dword(pdev, vsec + 0xc, &val);
>  	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>  			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
> @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
>  	struct device *dev = &pdev->dev;
>  	struct dw_edma_chip *chip;
> +	bool non_ll = false;
>  	int err, nr_irqs;
>  	int i, mask;
> -	bool non_ll = false;

unnecesary change

Frank

>
>  	if (!pdata)
>  		return -ENODEV;
> --
> 2.43.0
>

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Verma, Devendra]

On 28-Jul-26 21:03, Frank Li wrote:
> On Tue, Jul 28, 2026 at 02:47:43PM +0530, Devendra K Verma wrote:
>> As per, 'Designware Cores PCI Express DM Controller - Reference
>> Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
>> the channel separation mechanisms. Basically, the HDMA IP allows
>> the user to configure the separation between DMA channel
>> registers and retrieve it via the VSEC capability mentioned
>> above.
>>
>> HDMA IP supports the channel register space separation from
>> 256B to 32KB. Default supported size is 256B.
>>
>> Signed-off-by: Devendra K Verma <devverma@amd.com>
>> ---
>> Changes in v1:
>>     o Modified dw_edma_get_ch_sep_sz() as per review comment.
>>       The function now supports ch_sep_sz up to 32KB.
>>     o Updated to description to reflect the supported channel
>>       separation sizes.
>>     o Introduced the CPM6 specific macro for VSEC cap.
>> ---
>>   drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
>>   1 file changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
>> index ec5e057a0f11..d0f209082878 100644
>> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
>> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
>> @@ -31,8 +31,11 @@
>>
>>   #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
>>   #define DW_PCIE_XILINX_VSEC_ID			0x20
>> -#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>>   #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
>> +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>> +/* AMD CPM6 (Xilinx) supported cap */
>> +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
>> +
>>   #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
>>   #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
>>
>> @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
>>   	u16				wr_ch_cnt;
>>   	u16				rd_ch_cnt;
>>   	u64				devmem_phys_off;
>> +	u32				ch_sep_sz;
> 
> ch_space_sz?

In the document, Designware Cores PCI Express controller Reference
Manual, it widely referred as channel separation and ch_sep
has been used so in order to keep the relevance with the document,
I chose it to be ch_sep_sz. The other name used is chaddr_space but
it is not used widely as the ch_sep.
With your suggestion, it can be infered to be same but relevance with
the document may not be established.

In the past, a similar discussion we had for choosing the non_ll
naming and chose this as it mentioned and has relevance with the
document.

Reference
https://lore.kernel.org/all/20251223162842.GA4022246@bhelgaas/

> 
>>   };
>>
>>   static const struct dw_edma_pcie_data snps_edda_data = {
>> @@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
>>   };
>>
>>   static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
>> -	/* MDB registers location */
>> +	/* CPM6 registers location */
>>   	.rg.bar				= BAR_0,
>>   	.rg.off				= SZ_4K,	/*  4 Kbytes */
>>   	.rg.sz				= SZ_8K,	/*  8 Kbytes */
>> @@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
>>   	return pci_irq_vector(to_pci_dev(dev), nr);
>>   }
>>
>> +static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
>> +{
>> +	if (ch_sep_val > 0 && ch_sep_val <= 7)
>> +		return 256 << ch_sep_val;
>> +	return 256;
>> +}
>> +
>>   static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
>>   {
>>   	struct pci_dev *pdev = to_pci_dev(dev);
>> @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>   	pdata->mf = map;
>>   	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>>
>> +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
>> +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
>> +								   val));
>> +
>>   	pci_read_config_dword(pdev, vsec + 0xc, &val);
>>   	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>>   			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
>> @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>   	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
>>   	struct device *dev = &pdev->dev;
>>   	struct dw_edma_chip *chip;
>> +	bool non_ll = false;
>>   	int err, nr_irqs;
>>   	int i, mask;
>> -	bool non_ll = false;
> 
> unnecesary change
> 
> Frank

Yes, it is an unncessary change. It was introduced by me in some patch
series and wanted to maintain the revers x-mas order that's why posted
it. The declration order looks in the patch after this change.
Please suggest is it OK to include changes like this or it is kind of
extra scrutiny for the reviewers? I will make the change accordingly
in next patch.


> 
>>
>>   	if (!pdata)
>>   		return -ENODEV;
>> --
>> 2.43.0
>>

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Frank Li]

On Fri, Jul 31, 2026 at 04:22:22PM +0530, Verma, Devendra wrote:
>
>
> On 28-Jul-26 21:03, Frank Li wrote:
> > On Tue, Jul 28, 2026 at 02:47:43PM +0530, Devendra K Verma wrote:
> > > As per, 'Designware Cores PCI Express DM Controller - Reference
> > > Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
> > > the channel separation mechanisms. Basically, the HDMA IP allows
> > > the user to configure the separation between DMA channel
> > > registers and retrieve it via the VSEC capability mentioned
> > > above.
> > >
> > > HDMA IP supports the channel register space separation from
> > > 256B to 32KB. Default supported size is 256B.
> > >
> > > Signed-off-by: Devendra K Verma <devverma@amd.com>
> > > ---
> > > Changes in v1:
> > >     o Modified dw_edma_get_ch_sep_sz() as per review comment.
> > >       The function now supports ch_sep_sz up to 32KB.
> > >     o Updated to description to reflect the supported channel
> > >       separation sizes.
> > >     o Introduced the CPM6 specific macro for VSEC cap.
> > > ---
> > >   drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
> > >   1 file changed, 18 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > index ec5e057a0f11..d0f209082878 100644
> > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > @@ -31,8 +31,11 @@
> > >
> > >   #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
> > >   #define DW_PCIE_XILINX_VSEC_ID			0x20
> > > -#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > >   #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
> > > +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > > +/* AMD CPM6 (Xilinx) supported cap */
> > > +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
> > > +
> > >   #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
> > >   #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
> > >
> > > @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
> > >   	u16				wr_ch_cnt;
> > >   	u16				rd_ch_cnt;
> > >   	u64				devmem_phys_off;
> > > +	u32				ch_sep_sz;
> >
> > ch_space_sz?
>
> In the document, Designware Cores PCI Express controller Reference
> Manual, it widely referred as channel separation and ch_sep

which version? I only find "Register Wire Channel seperation" at 6.21a
Feb 2025.

Frank

> has been used so in order to keep the relevance with the document,
> I chose it to be ch_sep_sz. The other name used is chaddr_space but
> it is not used widely as the ch_sep.
> With your suggestion, it can be infered to be same but relevance with
> the document may not be established.
>
> In the past, a similar discussion we had for choosing the non_ll
> naming and chose this as it mentioned and has relevance with the
> document.
>
> Reference
> https://lore.kernel.org/all/20251223162842.GA4022246@bhelgaas/
>
> >
> > >   };
> > >
> > >   static const struct dw_edma_pcie_data snps_edda_data = {
> > > @@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
> > >   };
> > >
> > >   static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
> > > -	/* MDB registers location */
> > > +	/* CPM6 registers location */
> > >   	.rg.bar				= BAR_0,
> > >   	.rg.off				= SZ_4K,	/*  4 Kbytes */
> > >   	.rg.sz				= SZ_8K,	/*  8 Kbytes */
> > > @@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
> > >   	return pci_irq_vector(to_pci_dev(dev), nr);
> > >   }
> > >
> > > +static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
> > > +{
> > > +	if (ch_sep_val > 0 && ch_sep_val <= 7)
> > > +		return 256 << ch_sep_val;
> > > +	return 256;
> > > +}
> > > +
> > >   static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
> > >   {
> > >   	struct pci_dev *pdev = to_pci_dev(dev);
> > > @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > >   	pdata->mf = map;
> > >   	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
> > >
> > > +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
> > > +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
> > > +								   val));
> > > +
> > >   	pci_read_config_dword(pdev, vsec + 0xc, &val);
> > >   	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
> > >   			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
> > > @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> > >   	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
> > >   	struct device *dev = &pdev->dev;
> > >   	struct dw_edma_chip *chip;
> > > +	bool non_ll = false;
> > >   	int err, nr_irqs;
> > >   	int i, mask;
> > > -	bool non_ll = false;
> >
> > unnecesary change
> >
> > Frank
>
> Yes, it is an unncessary change. It was introduced by me in some patch
> series and wanted to maintain the revers x-mas order that's why posted
> it. The declration order looks in the patch after this change.
> Please suggest is it OK to include changes like this or it is kind of
> extra scrutiny for the reviewers? I will make the change accordingly
> in next patch.
>
>
> >
> > >
> > >   	if (!pdata)
> > >   		return -ENODEV;
> > > --
> > > 2.43.0
> > >
>

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Verma, Devendra]

On 31-Jul-26 21:04, Frank Li wrote:
> On Fri, Jul 31, 2026 at 04:22:22PM +0530, Verma, Devendra wrote:
>>
>>
>> On 28-Jul-26 21:03, Frank Li wrote:
>>> On Tue, Jul 28, 2026 at 02:47:43PM +0530, Devendra K Verma wrote:
>>>> As per, 'Designware Cores PCI Express DM Controller - Reference
>>>> Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
>>>> the channel separation mechanisms. Basically, the HDMA IP allows
>>>> the user to configure the separation between DMA channel
>>>> registers and retrieve it via the VSEC capability mentioned
>>>> above.
>>>>
>>>> HDMA IP supports the channel register space separation from
>>>> 256B to 32KB. Default supported size is 256B.
>>>>
>>>> Signed-off-by: Devendra K Verma <devverma@amd.com>
>>>> ---
>>>> Changes in v1:
>>>>      o Modified dw_edma_get_ch_sep_sz() as per review comment.
>>>>        The function now supports ch_sep_sz up to 32KB.
>>>>      o Updated to description to reflect the supported channel
>>>>        separation sizes.
>>>>      o Introduced the CPM6 specific macro for VSEC cap.
>>>> ---
>>>>    drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
>>>>    1 file changed, 18 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> index ec5e057a0f11..d0f209082878 100644
>>>> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>> @@ -31,8 +31,11 @@
>>>>
>>>>    #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
>>>>    #define DW_PCIE_XILINX_VSEC_ID			0x20
>>>> -#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>>>>    #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
>>>> +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>>>> +/* AMD CPM6 (Xilinx) supported cap */
>>>> +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
>>>> +
>>>>    #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
>>>>    #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
>>>>
>>>> @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
>>>>    	u16				wr_ch_cnt;
>>>>    	u16				rd_ch_cnt;
>>>>    	u64				devmem_phys_off;
>>>> +	u32				ch_sep_sz;
>>>
>>> ch_space_sz?
>>
>> In the document, Designware Cores PCI Express controller Reference
>> Manual, it widely referred as channel separation and ch_sep
> 
> which version? I only find "Register Wire Channel seperation" at 6.21a
> Feb 2025.
> 
> Frank

We have the reference from RM - 6.00a June 2022, following sections:
- Table 1-4
- Sec 3.2.34.3, Table 3-276 (VSECDMA_DEVICE_INFORMATION)
refer to channel separation and describe for HDMA

-Devendra

> 
>> has been used so in order to keep the relevance with the document,
>> I chose it to be ch_sep_sz. The other name used is chaddr_space but
>> it is not used widely as the ch_sep.
>> With your suggestion, it can be infered to be same but relevance with
>> the document may not be established.
>>
>> In the past, a similar discussion we had for choosing the non_ll
>> naming and chose this as it mentioned and has relevance with the
>> document.
>>
>> Reference
>> https://lore.kernel.org/all/20251223162842.GA4022246@bhelgaas/
>>
>>>
>>>>    };
>>>>
>>>>    static const struct dw_edma_pcie_data snps_edda_data = {
>>>> @@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
>>>>    };
>>>>
>>>>    static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
>>>> -	/* MDB registers location */
>>>> +	/* CPM6 registers location */
>>>>    	.rg.bar				= BAR_0,
>>>>    	.rg.off				= SZ_4K,	/*  4 Kbytes */
>>>>    	.rg.sz				= SZ_8K,	/*  8 Kbytes */
>>>> @@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
>>>>    	return pci_irq_vector(to_pci_dev(dev), nr);
>>>>    }
>>>>
>>>> +static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
>>>> +{
>>>> +	if (ch_sep_val > 0 && ch_sep_val <= 7)
>>>> +		return 256 << ch_sep_val;
>>>> +	return 256;
>>>> +}
>>>> +
>>>>    static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
>>>>    {
>>>>    	struct pci_dev *pdev = to_pci_dev(dev);
>>>> @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>>>    	pdata->mf = map;
>>>>    	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>>>>
>>>> +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
>>>> +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
>>>> +								   val));
>>>> +
>>>>    	pci_read_config_dword(pdev, vsec + 0xc, &val);
>>>>    	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>>>>    			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
>>>> @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>>>    	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
>>>>    	struct device *dev = &pdev->dev;
>>>>    	struct dw_edma_chip *chip;
>>>> +	bool non_ll = false;
>>>>    	int err, nr_irqs;
>>>>    	int i, mask;
>>>> -	bool non_ll = false;
>>>
>>> unnecesary change
>>>
>>> Frank
>>
>> Yes, it is an unncessary change. It was introduced by me in some patch
>> series and wanted to maintain the revers x-mas order that's why posted
>> it. The declration order looks in the patch after this change.
>> Please suggest is it OK to include changes like this or it is kind of
>> extra scrutiny for the reviewers? I will make the change accordingly
>> in next patch.
>>
>>
>>>
>>>>
>>>>    	if (!pdata)
>>>>    		return -ENODEV;
>>>> --
>>>> 2.43.0
>>>>
>>

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Frank Li]

On Fri, Jul 31, 2026 at 10:03:10PM +0530, Verma, Devendra wrote:
> On 31-Jul-26 21:04, Frank Li wrote:
> > On Fri, Jul 31, 2026 at 04:22:22PM +0530, Verma, Devendra wrote:
> > >
> > >
> > > On 28-Jul-26 21:03, Frank Li wrote:
> > > > On Tue, Jul 28, 2026 at 02:47:43PM +0530, Devendra K Verma wrote:
> > > > > As per, 'Designware Cores PCI Express DM Controller - Reference
> > > > > Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
> > > > > the channel separation mechanisms. Basically, the HDMA IP allows
> > > > > the user to configure the separation between DMA channel
> > > > > registers and retrieve it via the VSEC capability mentioned
> > > > > above.
> > > > >
> > > > > HDMA IP supports the channel register space separation from
> > > > > 256B to 32KB. Default supported size is 256B.
> > > > >
> > > > > Signed-off-by: Devendra K Verma <devverma@amd.com>
> > > > > ---
> > > > > Changes in v1:
> > > > >      o Modified dw_edma_get_ch_sep_sz() as per review comment.
> > > > >        The function now supports ch_sep_sz up to 32KB.
> > > > >      o Updated to description to reflect the supported channel
> > > > >        separation sizes.
> > > > >      o Introduced the CPM6 specific macro for VSEC cap.
> > > > > ---
> > > > >    drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
> > > > >    1 file changed, 18 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > index ec5e057a0f11..d0f209082878 100644
> > > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > @@ -31,8 +31,11 @@
> > > > >
> > > > >    #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
> > > > >    #define DW_PCIE_XILINX_VSEC_ID			0x20
> > > > > -#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > > > >    #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
> > > > > +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > > > > +/* AMD CPM6 (Xilinx) supported cap */
> > > > > +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
> > > > > +
> > > > >    #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
> > > > >    #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
> > > > >
> > > > > @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
> > > > >    	u16				wr_ch_cnt;
> > > > >    	u16				rd_ch_cnt;
> > > > >    	u64				devmem_phys_off;
> > > > > +	u32				ch_sep_sz;
> > > >
> > > > ch_space_sz?
> > >
> > > In the document, Designware Cores PCI Express controller Reference
> > > Manual, it widely referred as channel separation and ch_sep
> >
> > which version? I only find "Register Wire Channel seperation" at 6.21a
> > Feb 2025.
> >
> > Frank
>
> We have the reference from RM - 6.00a June 2022, following sections:
> - Table 1-4
> - Sec 3.2.34.3, Table 3-276 (VSECDMA_DEVICE_INFORMATION)
> refer to channel separation and describe for HDMA

But this is not register value, the register MACRO defination should follow
spec.

"Channel Separation: Address distance between read and write channels."

helper function dw_edma_get_ch_sep_sz() convert register value to this
field.

The field should use software easy understand/generic term, so reader
can know what's that easily without check spec. Driver need do some
abstract, instead direct copy from hardware.

Frank


>
> -Devendra
>
> >
> > > has been used so in order to keep the relevance with the document,
> > > I chose it to be ch_sep_sz. The other name used is chaddr_space but
> > > it is not used widely as the ch_sep.
> > > With your suggestion, it can be infered to be same but relevance with
> > > the document may not be established.
> > >
> > > In the past, a similar discussion we had for choosing the non_ll
> > > naming and chose this as it mentioned and has relevance with the
> > > document.
> > >
> > > Reference
> > > https://lore.kernel.org/all/20251223162842.GA4022246@bhelgaas/
> > >
> > > >
> > > > >    };
> > > > >
> > > > >    static const struct dw_edma_pcie_data snps_edda_data = {
> > > > > @@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
> > > > >    };
> > > > >
> > > > >    static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
> > > > > -	/* MDB registers location */
> > > > > +	/* CPM6 registers location */
> > > > >    	.rg.bar				= BAR_0,
> > > > >    	.rg.off				= SZ_4K,	/*  4 Kbytes */
> > > > >    	.rg.sz				= SZ_8K,	/*  8 Kbytes */
> > > > > @@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
> > > > >    	return pci_irq_vector(to_pci_dev(dev), nr);
> > > > >    }
> > > > >
> > > > > +static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
> > > > > +{
> > > > > +	if (ch_sep_val > 0 && ch_sep_val <= 7)
> > > > > +		return 256 << ch_sep_val;
> > > > > +	return 256;
> > > > > +}
> > > > > +
> > > > >    static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
> > > > >    {
> > > > >    	struct pci_dev *pdev = to_pci_dev(dev);
> > > > > @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > > > >    	pdata->mf = map;
> > > > >    	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
> > > > >
> > > > > +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
> > > > > +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
> > > > > +								   val));
> > > > > +
> > > > >    	pci_read_config_dword(pdev, vsec + 0xc, &val);
> > > > >    	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
> > > > >    			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
> > > > > @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> > > > >    	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
> > > > >    	struct device *dev = &pdev->dev;
> > > > >    	struct dw_edma_chip *chip;
> > > > > +	bool non_ll = false;
> > > > >    	int err, nr_irqs;
> > > > >    	int i, mask;
> > > > > -	bool non_ll = false;
> > > >
> > > > unnecesary change
> > > >
> > > > Frank
> > >
> > > Yes, it is an unncessary change. It was introduced by me in some patch
> > > series and wanted to maintain the revers x-mas order that's why posted
> > > it. The declration order looks in the patch after this change.
> > > Please suggest is it OK to include changes like this or it is kind of
> > > extra scrutiny for the reviewers? I will make the change accordingly
> > > in next patch.
> > >
> > >
> > > >
> > > > >
> > > > >    	if (!pdata)
> > > > >    		return -ENODEV;
> > > > > --
> > > > > 2.43.0
> > > > >
> > >
>

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Verma, Devendra]

On 01-Aug-26 00:35, Frank Li wrote:
> On Fri, Jul 31, 2026 at 10:03:10PM +0530, Verma, Devendra wrote:
>> On 31-Jul-26 21:04, Frank Li wrote:
>>> On Fri, Jul 31, 2026 at 04:22:22PM +0530, Verma, Devendra wrote:
>>>>
>>>>
>>>> On 28-Jul-26 21:03, Frank Li wrote:
>>>>> On Tue, Jul 28, 2026 at 02:47:43PM +0530, Devendra K Verma wrote:
>>>>>> As per, 'Designware Cores PCI Express DM Controller - Reference
>>>>>> Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
>>>>>> the channel separation mechanisms. Basically, the HDMA IP allows
>>>>>> the user to configure the separation between DMA channel
>>>>>> registers and retrieve it via the VSEC capability mentioned
>>>>>> above.
>>>>>>
>>>>>> HDMA IP supports the channel register space separation from
>>>>>> 256B to 32KB. Default supported size is 256B.
>>>>>>
>>>>>> Signed-off-by: Devendra K Verma <devverma@amd.com>
>>>>>> ---
>>>>>> Changes in v1:
>>>>>>       o Modified dw_edma_get_ch_sep_sz() as per review comment.
>>>>>>         The function now supports ch_sep_sz up to 32KB.
>>>>>>       o Updated to description to reflect the supported channel
>>>>>>         separation sizes.
>>>>>>       o Introduced the CPM6 specific macro for VSEC cap.
>>>>>> ---
>>>>>>     drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
>>>>>>     1 file changed, 18 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>>>> index ec5e057a0f11..d0f209082878 100644
>>>>>> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
>>>>>> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
>>>>>> @@ -31,8 +31,11 @@
>>>>>>
>>>>>>     #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
>>>>>>     #define DW_PCIE_XILINX_VSEC_ID			0x20
>>>>>> -#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>>>>>>     #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
>>>>>> +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
>>>>>> +/* AMD CPM6 (Xilinx) supported cap */
>>>>>> +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
>>>>>> +
>>>>>>     #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
>>>>>>     #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
>>>>>>
>>>>>> @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
>>>>>>     	u16				wr_ch_cnt;
>>>>>>     	u16				rd_ch_cnt;
>>>>>>     	u64				devmem_phys_off;
>>>>>> +	u32				ch_sep_sz;
>>>>>
>>>>> ch_space_sz?
>>>>
>>>> In the document, Designware Cores PCI Express controller Reference
>>>> Manual, it widely referred as channel separation and ch_sep
>>>
>>> which version? I only find "Register Wire Channel seperation" at 6.21a
>>> Feb 2025.
>>>
>>> Frank
>>
>> We have the reference from RM - 6.00a June 2022, following sections:
>> - Table 1-4
>> - Sec 3.2.34.3, Table 3-276 (VSECDMA_DEVICE_INFORMATION)
>> refer to channel separation and describe for HDMA
> 
> But this is not register value, the register MACRO defination should follow
> spec.
> 
> "Channel Separation: Address distance between read and write channels."
> 
> helper function dw_edma_get_ch_sep_sz() convert register value to this
> field.
> 
> The field should use software easy understand/generic term, so reader
> can know what's that easily without check spec. Driver need do some
> abstract, instead direct copy from hardware.
> 
> Frank
> 

The other macros defined also follow the similar format as mentioned in 
the RM. I did not deviate from the rule and used the variable which is 
both understood in software and hardware context alike.
Please follow the discussion below.

> 
>>
>> -Devendra
>>
>>>
>>>> has been used so in order to keep the relevance with the document,
>>>> I chose it to be ch_sep_sz. The other name used is chaddr_space but
>>>> it is not used widely as the ch_sep.
>>>> With your suggestion, it can be infered to be same but relevance with
>>>> the document may not be established.
>>>>
>>>> In the past, a similar discussion we had for choosing the non_ll
>>>> naming and chose this as it mentioned and has relevance with the
>>>> document.
>>>>
>>>> Reference
>>>> https://lore.kernel.org/all/20251223162842.GA4022246@bhelgaas/
>>>>

Also, as pointed out in this thread, it was a learning how naming
shall be convenient and relevant to the concept being implemented
and that's where the idea of naming the variable close to software
and hardware was taken up. It kind of helps in relating with the
RM data.

-Devendra

>>>>>
>>>>>>     };
>>>>>>
>>>>>>     static const struct dw_edma_pcie_data snps_edda_data = {
>>>>>> @@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
>>>>>>     };
>>>>>>
>>>>>>     static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
>>>>>> -	/* MDB registers location */
>>>>>> +	/* CPM6 registers location */
>>>>>>     	.rg.bar				= BAR_0,
>>>>>>     	.rg.off				= SZ_4K,	/*  4 Kbytes */
>>>>>>     	.rg.sz				= SZ_8K,	/*  8 Kbytes */
>>>>>> @@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
>>>>>>     	return pci_irq_vector(to_pci_dev(dev), nr);
>>>>>>     }
>>>>>>
>>>>>> +static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
>>>>>> +{
>>>>>> +	if (ch_sep_val > 0 && ch_sep_val <= 7)
>>>>>> +		return 256 << ch_sep_val;
>>>>>> +	return 256;
>>>>>> +}
>>>>>> +
>>>>>>     static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
>>>>>>     {
>>>>>>     	struct pci_dev *pdev = to_pci_dev(dev);
>>>>>> @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
>>>>>>     	pdata->mf = map;
>>>>>>     	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
>>>>>>
>>>>>> +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
>>>>>> +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
>>>>>> +								   val));
>>>>>> +
>>>>>>     	pci_read_config_dword(pdev, vsec + 0xc, &val);
>>>>>>     	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
>>>>>>     			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
>>>>>> @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>>>>>>     	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
>>>>>>     	struct device *dev = &pdev->dev;
>>>>>>     	struct dw_edma_chip *chip;
>>>>>> +	bool non_ll = false;
>>>>>>     	int err, nr_irqs;
>>>>>>     	int i, mask;
>>>>>> -	bool non_ll = false;
>>>>>
>>>>> unnecesary change
>>>>>
>>>>> Frank
>>>>
>>>> Yes, it is an unncessary change. It was introduced by me in some patch
>>>> series and wanted to maintain the revers x-mas order that's why posted
>>>> it. The declration order looks in the patch after this change.
>>>> Please suggest is it OK to include changes like this or it is kind of
>>>> extra scrutiny for the reviewers? I will make the change accordingly
>>>> in next patch.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>     	if (!pdata)
>>>>>>     		return -ENODEV;
>>>>>> --
>>>>>> 2.43.0
>>>>>>
>>>>
>>

Re: [PATCH v2 2/3] dmaengine: dw-edma: Enable Chan Separation via VSEC

[Frank Li]

On Mon, Aug 03, 2026 at 06:01:39PM +0530, Verma, Devendra wrote:
> On 01-Aug-26 00:35, Frank Li wrote:
> > On Fri, Jul 31, 2026 at 10:03:10PM +0530, Verma, Devendra wrote:
> > > On 31-Jul-26 21:04, Frank Li wrote:
> > > > On Fri, Jul 31, 2026 at 04:22:22PM +0530, Verma, Devendra wrote:
> > > > >
> > > > >
> > > > > On 28-Jul-26 21:03, Frank Li wrote:
> > > > > > On Tue, Jul 28, 2026 at 02:47:43PM +0530, Devendra K Verma wrote:
> > > > > > > As per, 'Designware Cores PCI Express DM Controller - Reference
> > > > > > > Manual', section 3.2.34.3, VSEC for DEVICE INFORMATION supports
> > > > > > > the channel separation mechanisms. Basically, the HDMA IP allows
> > > > > > > the user to configure the separation between DMA channel
> > > > > > > registers and retrieve it via the VSEC capability mentioned
> > > > > > > above.
> > > > > > >
> > > > > > > HDMA IP supports the channel register space separation from
> > > > > > > 256B to 32KB. Default supported size is 256B.
> > > > > > >
> > > > > > > Signed-off-by: Devendra K Verma <devverma@amd.com>
> > > > > > > ---
> > > > > > > Changes in v1:
> > > > > > >       o Modified dw_edma_get_ch_sep_sz() as per review comment.
> > > > > > >         The function now supports ch_sep_sz up to 32KB.
> > > > > > >       o Updated to description to reflect the supported channel
> > > > > > >         separation sizes.
> > > > > > >       o Introduced the CPM6 specific macro for VSEC cap.
> > > > > > > ---
> > > > > > >     drivers/dma/dw-edma/dw-edma-pcie.c | 21 ++++++++++++++++++---
> > > > > > >     1 file changed, 18 insertions(+), 3 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > > > index ec5e057a0f11..d0f209082878 100644
> > > > > > > --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > > > +++ b/drivers/dma/dw-edma/dw-edma-pcie.c
> > > > > > > @@ -31,8 +31,11 @@
> > > > > > >
> > > > > > >     #define DW_PCIE_XILINX_VSEC_DMA_ID		0x6
> > > > > > >     #define DW_PCIE_XILINX_VSEC_ID			0x20
> > > > > > > -#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > > > > > >     #define DW_PCIE_XILINX_VSEC_DMA_MAP		GENMASK(2, 0)
> > > > > > > +#define DW_PCIE_XILINX_VSEC_DMA_BAR		GENMASK(10, 8)
> > > > > > > +/* AMD CPM6 (Xilinx) supported cap */
> > > > > > > +#define DW_PCIE_XILINX_CPM6_VSEC_CH_SEP		GENMASK(18, 16)
> > > > > > > +
> > > > > > >     #define DW_PCIE_XILINX_VSEC_DMA_WR_CH		GENMASK(9, 0)
> > > > > > >     #define DW_PCIE_XILINX_VSEC_DMA_RD_CH		GENMASK(25, 16)
> > > > > > >
> > > > > > > @@ -73,6 +76,7 @@ struct dw_edma_pcie_data {
> > > > > > >     	u16				wr_ch_cnt;
> > > > > > >     	u16				rd_ch_cnt;
> > > > > > >     	u64				devmem_phys_off;
> > > > > > > +	u32				ch_sep_sz;
> > > > > >
> > > > > > ch_space_sz?
> > > > >
> > > > > In the document, Designware Cores PCI Express controller Reference
> > > > > Manual, it widely referred as channel separation and ch_sep
> > > >
> > > > which version? I only find "Register Wire Channel seperation" at 6.21a
> > > > Feb 2025.
> > > >
> > > > Frank
> > >
> > > We have the reference from RM - 6.00a June 2022, following sections:
> > > - Table 1-4
> > > - Sec 3.2.34.3, Table 3-276 (VSECDMA_DEVICE_INFORMATION)
> > > refer to channel separation and describe for HDMA
> >
> > But this is not register value, the register MACRO defination should follow
> > spec.
> >
> > "Channel Separation: Address distance between read and write channels."
> >
> > helper function dw_edma_get_ch_sep_sz() convert register value to this
> > field.
> >
> > The field should use software easy understand/generic term, so reader
> > can know what's that easily without check spec. Driver need do some
> > abstract, instead direct copy from hardware.
> >
> > Frank
> >
>
> The other macros defined also follow the similar format as mentioned in the
> RM. I did not deviate from the rule and used the variable which is both
> understood in software and hardware context alike.
> Please follow the discussion below.
>
> >
> > >
> > > -Devendra
> > >
> > > >
> > > > > has been used so in order to keep the relevance with the document,
> > > > > I chose it to be ch_sep_sz. The other name used is chaddr_space but
> > > > > it is not used widely as the ch_sep.
> > > > > With your suggestion, it can be infered to be same but relevance with
> > > > > the document may not be established.
> > > > >
> > > > > In the past, a similar discussion we had for choosing the non_ll
> > > > > naming and chose this as it mentioned and has relevance with the
> > > > > document.
> > > > >
> > > > > Reference
> > > > > https://lore.kernel.org/all/20251223162842.GA4022246@bhelgaas/
> > > > >
>
> Also, as pointed out in this thread, it was a learning how naming
> shall be convenient and relevant to the concept being implemented
> and that's where the idea of naming the variable close to software
> and hardware was taken up. It kind of helps in relating with the
> RM data.

The term "channel space size" (ch_space_sz) is more commonly used in kernel
drivers. It is widely seen across various DMA engine drivers and is
generally easier for software developers to understand. In contrast,
ch_sep_sz appears to be more specific to your hardware implementation.

The other existing fields are self-documenting, clean, and easy to
understand.

Additionally, this change introduces a conversion from the register value
through an algorithm, even though the calculation itself is relatively
simple.

dw_edma_pcie_data is not only used for your hardware.

You register name already align RM data, which is already enough.

Frank
>
> -Devendra
>
> > > > > >
> > > > > > >     };
> > > > > > >
> > > > > > >     static const struct dw_edma_pcie_data snps_edda_data = {
> > > > > > > @@ -127,7 +131,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
> > > > > > >     };
> > > > > > >
> > > > > > >     static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
> > > > > > > -	/* MDB registers location */
> > > > > > > +	/* CPM6 registers location */
> > > > > > >     	.rg.bar				= BAR_0,
> > > > > > >     	.rg.off				= SZ_4K,	/*  4 Kbytes */
> > > > > > >     	.rg.sz				= SZ_8K,	/*  8 Kbytes */
> > > > > > > @@ -189,6 +193,13 @@ static int dw_edma_pcie_irq_vector(struct device *dev, unsigned int nr)
> > > > > > >     	return pci_irq_vector(to_pci_dev(dev), nr);
> > > > > > >     }
> > > > > > >
> > > > > > > +static u32 dw_edma_get_ch_sep_sz(u32 ch_sep_val)
> > > > > > > +{
> > > > > > > +	if (ch_sep_val > 0 && ch_sep_val <= 7)
> > > > > > > +		return 256 << ch_sep_val;
> > > > > > > +	return 256;
> > > > > > > +}
> > > > > > > +
> > > > > > >     static u64 dw_edma_pcie_address(struct device *dev, phys_addr_t cpu_addr)
> > > > > > >     {
> > > > > > >     	struct pci_dev *pdev = to_pci_dev(dev);
> > > > > > > @@ -279,6 +290,10 @@ static void dw_edma_pcie_get_xilinx_dma_data(struct pci_dev *pdev,
> > > > > > >     	pdata->mf = map;
> > > > > > >     	pdata->rg.bar = FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_BAR, val);
> > > > > > >
> > > > > > > +	if (pdev->device == PCI_DEVICE_ID_XILINX_B00F)
> > > > > > > +		pdata->ch_sep_sz = dw_edma_get_ch_sep_sz(FIELD_GET(DW_PCIE_XILINX_CPM6_VSEC_CH_SEP,
> > > > > > > +								   val));
> > > > > > > +
> > > > > > >     	pci_read_config_dword(pdev, vsec + 0xc, &val);
> > > > > > >     	pdata->wr_ch_cnt = min(pdata->wr_ch_cnt,
> > > > > > >     			       FIELD_GET(DW_PCIE_XILINX_VSEC_DMA_WR_CH, val));
> > > > > > > @@ -324,9 +339,9 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
> > > > > > >     	struct dw_edma_pcie_data *pdata = (void *)pid->driver_data;
> > > > > > >     	struct device *dev = &pdev->dev;
> > > > > > >     	struct dw_edma_chip *chip;
> > > > > > > +	bool non_ll = false;
> > > > > > >     	int err, nr_irqs;
> > > > > > >     	int i, mask;
> > > > > > > -	bool non_ll = false;
> > > > > >
> > > > > > unnecesary change
> > > > > >
> > > > > > Frank
> > > > >
> > > > > Yes, it is an unncessary change. It was introduced by me in some patch
> > > > > series and wanted to maintain the revers x-mas order that's why posted
> > > > > it. The declration order looks in the patch after this change.
> > > > > Please suggest is it OK to include changes like this or it is kind of
> > > > > extra scrutiny for the reviewers? I will make the change accordingly
> > > > > in next patch.
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > >     	if (!pdata)
> > > > > > >     		return -ENODEV;
> > > > > > > --
> > > > > > > 2.43.0
> > > > > > >
> > > > >
> > >
>

[PATCH v2 3/3] dmaengine: dw-edma: Add changes to support Channel Separation

[Devendra K Verma]

HDMA supports configurable DMA channel register space
separation which ranges from 256B to 32KB. Current implementation
supports 256B as default for DMA channel register space.
CPM6 supports the selection of channel register space via VSEC.
The default value for channel register space for CPM6 is 512B.

Updated the functions and methods to calculate the DMA channel
registers base address as per the selected channel separation
available as part of 'ch_sep_sz'. Removed the unused function
__dw_regs() and structs, namely dw_hdma_v0_ch and dw_hdma_v0_regs.

Signed-off-by: Devendra K Verma <devverma@amd.com>
---
Changes in v1:
   o Updated the description as per the review comment
   o Updated ch_sep_sz for EPC driver.
---
 drivers/dma/dw-edma/dw-edma-pcie.c           |  4 ++++
 drivers/dma/dw-edma/dw-hdma-v0-core.c        | 23 ++++++++++++--------
 drivers/dma/dw-edma/dw-hdma-v0-debugfs.c     | 17 +++++----------
 drivers/dma/dw-edma/dw-hdma-v0-regs.h        | 10 ---------
 drivers/pci/controller/dwc/pcie-designware.c |  1 +
 include/linux/dma/edma.h                     |  1 +
 6 files changed, 26 insertions(+), 30 deletions(-)

diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
index d0f209082878..f2a9ae8d0f3c 100644
--- a/drivers/dma/dw-edma/dw-edma-pcie.c
+++ b/drivers/dma/dw-edma/dw-edma-pcie.c
@@ -115,6 +115,7 @@ static const struct dw_edma_pcie_data snps_edda_data = {
 	.irqs				= 1,
 	.wr_ch_cnt			= 2,
 	.rd_ch_cnt			= 2,
+	.ch_sep_sz			= 256,
 };
 
 static const struct dw_edma_pcie_data xilinx_mdb_data = {
@@ -128,6 +129,7 @@ static const struct dw_edma_pcie_data xilinx_mdb_data = {
 	.irqs				= 1,
 	.wr_ch_cnt			= 8,
 	.rd_ch_cnt			= 8,
+	.ch_sep_sz			= 256,
 };
 
 static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
@@ -141,6 +143,7 @@ static const struct dw_edma_pcie_data xilinx_cpm6_dma_data = {
 	.irqs				= 1,
 	.wr_ch_cnt			= 8,
 	.rd_ch_cnt			= 8,
+	.ch_sep_sz			= 512,
 };
 
 static void dw_edma_set_chan_region_offset(struct dw_edma_pcie_data *pdata,
@@ -437,6 +440,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
 	chip->nr_irqs = nr_irqs;
 	chip->ops = &dw_edma_pcie_plat_ops;
 	chip->cfg_non_ll = non_ll;
+	chip->ch_sep_sz = vsec_data->ch_sep_sz;
 
 	chip->ll_wr_cnt = vsec_data->wr_ch_cnt;
 	chip->ll_rd_cnt = vsec_data->rd_ch_cnt;
diff --git a/drivers/dma/dw-edma/dw-hdma-v0-core.c b/drivers/dma/dw-edma/dw-hdma-v0-core.c
index 632abb8b481c..3f27a93c4d8c 100644
--- a/drivers/dma/dw-edma/dw-hdma-v0-core.c
+++ b/drivers/dma/dw-edma/dw-hdma-v0-core.c
@@ -23,18 +23,23 @@ enum dw_hdma_control {
 	DW_HDMA_V0_LLE					= BIT(9),
 };
 
-static inline struct dw_hdma_v0_regs __iomem *__dw_regs(struct dw_edma *dw)
-{
-	return dw->chip->reg_base;
-}
-
 static inline struct dw_hdma_v0_ch_regs __iomem *
 __dw_ch_regs(struct dw_edma *dw, enum dw_edma_dir dir, u16 ch)
 {
-	if (dir == EDMA_DIR_WRITE)
-		return &(__dw_regs(dw)->ch[ch].wr);
-	else
-		return &(__dw_regs(dw)->ch[ch].rd);
+	u32 ch_base;
+
+	/*
+	 * For Write, the channel register index starts at
+	 * wr_base(ch_idx) = (2 * ch_idx) * ch_sep_sz
+	 *
+	 * For Read channel,
+	 * rd_base(ch_idx) = (2 * ch_idx + 1) * ch_sep_sz
+	 */
+	ch_base = 2 * ch;
+	if (dir == EDMA_DIR_READ)
+		ch_base += 1;
+
+	return dw->chip->reg_base + (ch_base * dw->chip->ch_sep_sz);
 }
 
 #define SET_CH_32(dw, dir, ch, name, value) \
diff --git a/drivers/dma/dw-edma/dw-hdma-v0-debugfs.c b/drivers/dma/dw-edma/dw-hdma-v0-debugfs.c
index dcdc57fe976c..33128685bbd9 100644
--- a/drivers/dma/dw-edma/dw-hdma-v0-debugfs.c
+++ b/drivers/dma/dw-edma/dw-hdma-v0-debugfs.c
@@ -13,22 +13,17 @@
 #include "dw-hdma-v0-regs.h"
 #include "dw-edma-core.h"
 
-#define REGS_ADDR(dw, name)						       \
-	({								       \
-		struct dw_hdma_v0_regs __iomem *__regs = (dw)->chip->reg_base; \
-									       \
-		(void __iomem *)&__regs->name;				       \
-	})
-
 #define REGS_CH_ADDR(dw, name, _dir, _ch)				       \
 	({								       \
-		struct dw_hdma_v0_ch_regs __iomem *__ch_regs;		       \
+		struct dw_hdma_v0_ch_regs __iomem *__ch_regs;                  \
+		off_t __off = (dw)->chip->ch_sep_sz;			       \
 									       \
-		if (_dir == EDMA_DIR_READ)				       \
-			__ch_regs = REGS_ADDR(dw, ch[_ch].rd);		       \
+		if ((_dir) == EDMA_DIR_READ)				       \
+			__off *= (2 * (_ch) + 1);			       \
 		else							       \
-			__ch_regs = REGS_ADDR(dw, ch[_ch].wr);		       \
+			__off *= (2 * (_ch));				       \
 									       \
+		__ch_regs = ((dw)->chip->reg_base + __off);		       \
 		(void __iomem *)&__ch_regs->name;			       \
 	})
 
diff --git a/drivers/dma/dw-edma/dw-hdma-v0-regs.h b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
index 7759ba9b4850..2475b8d96133 100644
--- a/drivers/dma/dw-edma/dw-hdma-v0-regs.h
+++ b/drivers/dma/dw-edma/dw-hdma-v0-regs.h
@@ -84,16 +84,6 @@ struct dw_hdma_v0_ch_regs {
 		};
 	} msi_abort;
 	u32 msi_msgdata;			/* 0x00a8 */
-	u32 padding_2[21];			/* 0x00ac..0x00fc */
-} __packed;
-
-struct dw_hdma_v0_ch {
-	struct dw_hdma_v0_ch_regs wr;		/* 0x0000 */
-	struct dw_hdma_v0_ch_regs rd;		/* 0x0100 */
-} __packed;
-
-struct dw_hdma_v0_regs {
-	struct dw_hdma_v0_ch ch[HDMA_V0_MAX_NR_CH];	/* 0x0000..0x0fa8 */
 } __packed;
 
 struct dw_hdma_v0_lli {
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index ec4722ed9303..7cc268797832 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -1049,6 +1049,7 @@ static void dw_pcie_edma_init_data(struct dw_pcie *pci)
 		pci->edma.ops = &dw_pcie_edma_ops;
 
 	pci->edma.flags |= DW_EDMA_CHIP_LOCAL;
+	pci->edma.ch_sep_sz = 256;
 }
 
 static int dw_pcie_edma_find_mf(struct dw_pcie *pci)
diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
index 1fafd5b0e315..a6c5728f03d3 100644
--- a/include/linux/dma/edma.h
+++ b/include/linux/dma/edma.h
@@ -104,6 +104,7 @@ struct dw_edma_chip {
 
 	struct dw_edma		*dw;
 	bool			cfg_non_ll;
+	u32			ch_sep_sz;
 };
 
 /* Export to the platform drivers */
-- 
2.43.0

Re: [PATCH v2 3/3] dmaengine: dw-edma: Add changes to support Channel Separation

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] eDMA/HDMA register base address missing capability offset
--

--- Patch [3]: [PATCH v2 3/3] dmaengine: dw-edma: Add changes to support Channel Separation ---
commit d8b9ebd109653d1219284d3ab6408816a9dc7745
Author: Devendra K Verma <devverma@amd.com>

dmaengine: dw-edma: Add changes to support Channel Separation

This commit updates the driver to support configurable DMA channel register
space separation. It modifies channel register base address calculations to
use a dynamic separation size instead of a fixed layout, and removes unused
legacy register layout structures.

> diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c b/drivers/dma/dw-edma/dw-edma-pcie.c
> index d0f209082878d..f2a9ae8d0f3c4 100644
> --- a/drivers/dma/dw-edma/dw-edma-pcie.c
> +++ b/drivers/dma/dw-edma/dw-edma-pcie.c

[ ... ]

> @@ -437,6 +440,7 @@ static int dw_edma_pcie_probe(struct pci_dev *pdev,
>  	chip->nr_irqs = nr_irqs;
>  	chip->ops = &dw_edma_pcie_plat_ops;
>  	chip->cfg_non_ll = non_ll;
> +	chip->ch_sep_sz = vsec_data->ch_sep_sz;
>  
>  	chip->ll_wr_cnt = vsec_data->wr_ch_cnt;
>  	chip->ll_rd_cnt = vsec_data->rd_ch_cnt;

[Severity: High]
This is a pre-existing issue, but does dw_edma_pcie_probe() assign the wrong
MMIO base offset to chip->reg_base?

Just below this hunk in dw_edma_pcie_probe(), the code assigns:

    chip->reg_base = pcim_iomap_table(pdev)[vsec_data->rg.bar];
    if (!chip->reg_base)
        return -ENOMEM;

It appears the vsec_data->rg.off capability offset is never added to this base
address. Without adding the offset, won't all subsequent eDMA/HDMA register
accesses target the wrong MMIO locations (offset 0 of the BAR instead of the
specified offset like 4KB), potentially triggering bus faults or preventing
the DMA hardware from initializing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260728091744.1086942-1-devverma@amd.com?part=3