[PATCH 0/8] dma: mmp_pdma: Add SpacemiT K1 SoC support with 64-bit addressing

[PATCH 0/8] dma: mmp_pdma: Add SpacemiT K1 SoC support with 64-bit addressing

[Guodong Xu]

This series extends the existing MMP PDMA driver to support SpacemiT PDMA
controllers with 64-bit addressing capabilities, as used in the K1 SoC.

The SpacemiT K1 SoC contains a PDMA controller that is largely compatible
with the existing Marvell MMP PDMA, but adds support for 64-bit physical
addressing through Long Physical Address Extension (LPAE) mode. This
requires programming additional high address registers (DDADRH, DSADRH,
DTADRH) and enabling the DCSR_LPAEEN control bit.

The implementation maintains full backward compatibility with existing
32-bit Marvell platforms while adding the necessary infrastructure for
64-bit address handling through a flexible configuration-based approach.

Key features added:
- 64-bit DMA address support via LPAE mode
- Platform-specific operation abstractions (mmp_pdma_ops)
- Optional clock and reset controller support for modern SoCs
- Device tree integration for SpacemiT K1 SoC and Banana Pi F3 board

Testing:
This patchset has been tested on SpacemiT K1-based Banana Pi F3 hardware
to ensure the PDMA controller operates correctly with 64-bit addressing.
Existing functionality on 32-bit platforms remains unchanged.

This patchset is based on [spacemit/for-next]
  base: https://github.com/spacemit-com/linux for-next
Plus the reset controller driver, posted by Alex Elder (v10):
https://lore.kernel.org/all/20250513215345.3631593-1-elder@riscstar.com/

Guodong Xu (8):
  dt-bindings: dma: marvell,mmp-dma: Add SpacemiT PDMA compatibility
  dma: mmp_pdma: Add optional clock support
  dma: mmp_pdma: Add optional reset controller support
  dma: mmp_pdma: Add SpacemiT PDMA support with 64-bit addressing
  riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC
  riscv: dts: spacemit: Enable PDMA0 controller on Banana Pi F3
  dma: Kconfig: MMP_PDMA: Add support for ARCH_SPACEMIT
  riscv: defconfig: Enable MMP_PDMA support for SpacemiT K1 SoC

 .../bindings/dma/marvell,mmp-dma.yaml         |  17 ++
 .../boot/dts/spacemit/k1-bananapi-f3.dts      |   4 +
 arch/riscv/boot/dts/spacemit/k1.dtsi          | 234 ++++++++--------
 arch/riscv/configs/defconfig                  |   3 +-
 drivers/dma/Kconfig                           |   2 +-
 drivers/dma/mmp_pdma.c                        | 249 +++++++++++++++---
 6 files changed, 370 insertions(+), 139 deletions(-)

-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT PDMA compatibility

[Guodong Xu]

Add "spacemit,pdma-1.0" compatible string to support SpacemiT PDMA
controller in the Marvell MMP DMA device tree bindings. This enables:

- Support for SpacemiT PDMA controller configuration
- New optional properties for platform-specific integration:
  * clocks: Clock controller for the DMA
  * resets: Reset controller for the DMA

Also, add explicit #dma-cells property definition to avoid
"make dtbs_check W=3" warnings about unevaluated properties.

The #dma-cells property is defined as 2 cells to maintain compatibility
with existing ARM device trees. The first cell specifies the DMA request
line number, while the second cell is currently unused by the driver but
required for backward compatibility with PXA device tree files.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 .../bindings/dma/marvell,mmp-dma.yaml           | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
index d447d5207be0..e117a81414bd 100644
--- a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
@@ -18,6 +18,7 @@ properties:
       - marvell,pdma-1.0
       - marvell,adma-1.0
       - marvell,pxa910-squ
+      - spacemit,pdma-1.0
 
   reg:
     maxItems: 1
@@ -32,6 +33,21 @@ properties:
       A phandle to the SRAM pool
     $ref: /schemas/types.yaml#/definitions/phandle
 
+  clocks:
+    description: Clock for the controller
+    maxItems: 1
+
+  resets:
+    description: Reset controller for the DMA controller
+    maxItems: 1
+
+  '#dma-cells':
+    const: 2
+    description:
+      The first cell contains the DMA request number for the peripheral
+      device. The second cell is currently unused but must be present for
+      backward compatibility.
+
   '#dma-channels':
     deprecated: true
 
@@ -52,6 +68,7 @@ allOf:
           contains:
             enum:
               - marvell,pdma-1.0
+              - spacemit,pdma-1.0
     then:
       properties:
         asram: false
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 2/8] dma: mmp_pdma: Add optional clock support

[Guodong Xu]

Add support for retrieving and enabling an optional clock using
devm_clk_get_optional_enabled() during mmp_pdma_probe().

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 drivers/dma/mmp_pdma.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index a95d31103d30..4a6dbf558237 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -15,6 +15,7 @@
 #include <linux/device.h>
 #include <linux/platform_data/mmp_dma.h>
 #include <linux/dmapool.h>
+#include <linux/clk.h>
 #include <linux/of_dma.h>
 #include <linux/of.h>
 
@@ -1019,6 +1020,7 @@ static int mmp_pdma_probe(struct platform_device *op)
 {
 	struct mmp_pdma_device *pdev;
 	struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
+	struct clk *clk;
 	int i, ret, irq = 0;
 	int dma_channels = 0, irq_num = 0;
 	const enum dma_slave_buswidth widths =
@@ -1037,6 +1039,10 @@ static int mmp_pdma_probe(struct platform_device *op)
 	if (IS_ERR(pdev->base))
 		return PTR_ERR(pdev->base);
 
+	clk = devm_clk_get_optional_enabled(pdev->dev, NULL);
+	if (IS_ERR(clk))
+		return PTR_ERR(clk);
+
 	if (pdev->dev->of_node) {
 		/* Parse new and deprecated dma-channels properties */
 		if (of_property_read_u32(pdev->dev->of_node, "dma-channels",
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 3/8] dma: mmp_pdma: Add optional reset controller support

[Guodong Xu]

Add support for hardware reset control in the MMP PDMA driver using the
devm_reset_control_get_optional_exclusive_deasserted() API.

The reset controller is retrieved without a specific reset name,
allowing platforms to define a single default reset line for the
PDMA controller.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 drivers/dma/mmp_pdma.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index 4a6dbf558237..fe627efeaff0 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -16,6 +16,7 @@
 #include <linux/platform_data/mmp_dma.h>
 #include <linux/dmapool.h>
 #include <linux/clk.h>
+#include <linux/reset.h>
 #include <linux/of_dma.h>
 #include <linux/of.h>
 
@@ -1021,6 +1022,7 @@ static int mmp_pdma_probe(struct platform_device *op)
 	struct mmp_pdma_device *pdev;
 	struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
 	struct clk *clk;
+	struct reset_control *rst;
 	int i, ret, irq = 0;
 	int dma_channels = 0, irq_num = 0;
 	const enum dma_slave_buswidth widths =
@@ -1043,6 +1045,11 @@ static int mmp_pdma_probe(struct platform_device *op)
 	if (IS_ERR(clk))
 		return PTR_ERR(clk);
 
+	rst = devm_reset_control_get_optional_exclusive_deasserted(pdev->dev,
+								   NULL);
+	if (IS_ERR(rst))
+		return PTR_ERR(rst);
+
 	if (pdev->dev->of_node) {
 		/* Parse new and deprecated dma-channels properties */
 		if (of_property_read_u32(pdev->dev->of_node, "dma-channels",
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 4/8] dma: mmp_pdma: Add SpacemiT PDMA support with 64-bit addressing

[Guodong Xu]

Extend the MMP PDMA driver to support SpacemiT PDMA controllers with
64-bit physical addressing capabilities, as used in the K1 SoC. This
change introduces a flexible architecture that maintains compatibility
with existing 32-bit Marvell platforms while adding 64-bit support.

Key changes:
- Add struct mmp_pdma_config to abstract platform-specific behaviors
- Implement 64-bit address support through:
  * New high address registers (DDADRH, DSADRH, DTADRH)
  * DCSR_LPAEEN bit for Long Physical Address Extension mode
  * Helper functions for 32/64-bit address handling
- Add "spacemit,pdma-1.0" compatible string with associated config
- Extend descriptor structure to support 64-bit addresses
- Refactor address handling code to be platform-agnostic
- Add proper DMA mask configuration for both 32-bit and 64-bit modes

The implementation uses a configuration-based approach to keeps all
platform-specific code isolated in config structures. It maintains clean
separation between 32-bit and 64-bit code paths, provides consistent
API for both addressing modes and preserves backward compatibility.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 drivers/dma/mmp_pdma.c | 236 +++++++++++++++++++++++++++++++++++------
 1 file changed, 205 insertions(+), 31 deletions(-)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index fe627efeaff0..57313754b611 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -25,9 +25,12 @@
 #define DCSR		0x0000
 #define DALGN		0x00a0
 #define DINT		0x00f0
-#define DDADR		0x0200
+#define DDADR(n)	(0x0200 + ((n) << 4))
 #define DSADR(n)	(0x0204 + ((n) << 4))
 #define DTADR(n)	(0x0208 + ((n) << 4))
+#define DDADRH(n)	(0x0300 + ((n) << 4))
+#define DSADRH(n)	(0x0304 + ((n) << 4))
+#define DTADRH(n)	(0x0308 + ((n) << 4))
 #define DCMD		0x020c
 
 #define DCSR_RUN	BIT(31)	/* Run Bit (read / write) */
@@ -44,6 +47,7 @@
 #define DCSR_EORSTOPEN	BIT(26)	/* STOP on an EOR */
 #define DCSR_SETCMPST	BIT(25)	/* Set Descriptor Compare Status */
 #define DCSR_CLRCMPST	BIT(24)	/* Clear Descriptor Compare Status */
+#define DCSR_LPAEEN	BIT(21)	/* Long Physical Address Extension Enable */
 #define DCSR_CMPST	BIT(10)	/* The Descriptor Compare Status */
 #define DCSR_EORINTR	BIT(9)	/* The end of Receive */
 
@@ -76,6 +80,16 @@ struct mmp_pdma_desc_hw {
 	u32 dsadr;	/* DSADR value for the current transfer */
 	u32 dtadr;	/* DTADR value for the current transfer */
 	u32 dcmd;	/* DCMD value for the current transfer */
+	/*
+	 * The following 32-bit words are only used in the 64-bit, ie.
+	 * LPAE (Long Physical Address Extension) mode.
+	 * They are used to specify the high 32 bits of the descriptor's
+	 * addresses.
+	 */
+	u32 ddadrh;	/* High 32-bit of DDADR */
+	u32 dsadrh;	/* High 32-bit of DSADR */
+	u32 dtadrh;	/* High 32-bit of DTADR */
+	u32 rsvd;	/* reserved */
 } __aligned(32);
 
 struct mmp_pdma_desc_sw {
@@ -120,12 +134,36 @@ struct mmp_pdma_phy {
 	struct mmp_pdma_chan *vchan;
 };
 
+/**
+ * struct mmp_pdma_ops - Operations for the MMP PDMA controller
+ * @set_desc:   Function to program descriptor addresses into DDADR/DDADRH
+ *              channel registers
+ * @addr_split: Function to split DMA address into 32-bit low/high parts
+ *              for hardware programming
+ * @addr_join:  Function to combine 32-bit low/high values into 64-bit
+ *              for software processing
+ * @reg_read64: Function to read and combine two 32-bit registers into
+ *              64-bit value
+ * @run_bits:   Control bits in DCSR register for channel start/stop
+ * @dma_mask:   DMA addressing capability of controller. 0 to use OF/platform
+ *              settings, or explicit mask like DMA_BIT_MASK(32/64)
+ */
+struct mmp_pdma_ops {
+	void (*set_desc)(struct mmp_pdma_phy *phy, dma_addr_t addr);
+	void (*addr_split)(u32 *lower, u32 *upper, dma_addr_t addr);
+	u64 (*addr_join)(u32 lower, u32 upper);
+	u64 (*reg_read64)(void __iomem *base, u32 low_offset, u32 high_offset);
+	u32 run_bits;
+	u64 dma_mask;
+};
+
 struct mmp_pdma_device {
 	int				dma_channels;
 	void __iomem			*base;
 	struct device			*dev;
 	struct dma_device		device;
 	struct mmp_pdma_phy		*phy;
+	const struct mmp_pdma_ops	*config;
 	spinlock_t phy_lock; /* protect alloc/free phy channels */
 };
 
@@ -138,24 +176,89 @@ struct mmp_pdma_device {
 #define to_mmp_pdma_dev(dmadev)					\
 	container_of(dmadev, struct mmp_pdma_device, device)
 
-static int mmp_pdma_config_write(struct dma_chan *dchan,
-			   struct dma_slave_config *cfg,
-			   enum dma_transfer_direction direction);
+/* For 32-bit version */
+static void addr_split_32(u32 *lower, u32 *upper __maybe_unused,
+			  dma_addr_t addr)
+{
+	*lower = addr;
+}
+
+static void set_desc_32(struct mmp_pdma_phy *phy, dma_addr_t addr)
+{
+	writel(addr, phy->base + DDADR(phy->idx));
+}
+
+static u64 addr_join_32(u32 lower, u32 upper __maybe_unused)
+{
+	return lower;
+}
 
-static void set_desc(struct mmp_pdma_phy *phy, dma_addr_t addr)
+static u64 reg_read64_32(void __iomem *base, u32 low_offset,
+			 u32 high_offset __maybe_unused)
 {
-	u32 reg = (phy->idx << 4) + DDADR;
+	return readl(base + low_offset);
+}
 
-	writel(addr, phy->base + reg);
+/* For 64-bit version */
+static void addr_split_64(u32 *lower, u32 *upper, dma_addr_t addr)
+{
+	*lower = lower_32_bits(addr);
+	*upper = upper_32_bits(addr);
+}
+
+static void set_desc_64(struct mmp_pdma_phy *phy, dma_addr_t addr)
+{
+	writel(lower_32_bits(addr), phy->base + DDADR(phy->idx));
+	writel(upper_32_bits(addr), phy->base + DDADRH(phy->idx));
+}
+
+static u64 addr_join_64(u32 lower, u32 upper)
+{
+	return ((u64)upper << 32) | lower;
+}
+
+static u64 reg_read64_64(void __iomem *base, u32 low_offset,
+			 u32 high_offset)
+{
+	return addr_join_64(readl(base + low_offset),
+			    readl(base + high_offset));
 }
 
+/* Helper functions */
+static inline void pdma_desc_set_addr(struct mmp_pdma_device *pdev,
+				      u32 *addr_low, u32 *addr_high,
+				      dma_addr_t addr)
+{
+	pdev->config->addr_split(addr_low, addr_high, addr);
+}
+
+static inline u64 pdma_read_addr(struct mmp_pdma_phy *phy,
+				 struct mmp_pdma_device *pdev,
+				 u32 reg_low, u32 reg_high)
+{
+	return pdev->config->reg_read64(phy->base, reg_low, reg_high);
+}
+
+static inline u64 pdma_desc_addr(struct mmp_pdma_device *pdev,
+				 u32 addr_low, u32 addr_high)
+{
+	return pdev->config->addr_join(addr_low, addr_high);
+}
+
+static int mmp_pdma_config_write(struct dma_chan *dchan,
+				 struct dma_slave_config *cfg,
+				 enum dma_transfer_direction direction);
+
 static void enable_chan(struct mmp_pdma_phy *phy)
 {
 	u32 reg, dalgn;
+	struct mmp_pdma_device *pdev;
 
 	if (!phy->vchan)
 		return;
 
+	pdev = to_mmp_pdma_dev(phy->vchan->chan.device);
+
 	reg = DRCMR(phy->vchan->drcmr);
 	writel(DRCMR_MAPVLD | phy->idx, phy->base + reg);
 
@@ -167,18 +270,29 @@ static void enable_chan(struct mmp_pdma_phy *phy)
 	writel(dalgn, phy->base + DALGN);
 
 	reg = (phy->idx << 2) + DCSR;
-	writel(readl(phy->base + reg) | DCSR_RUN, phy->base + reg);
+	writel(readl(phy->base + reg) | pdev->config->run_bits,
+	       phy->base + reg);
 }
 
 static void disable_chan(struct mmp_pdma_phy *phy)
 {
-	u32 reg;
+	u32 reg, dcsr;
 
 	if (!phy)
 		return;
 
 	reg = (phy->idx << 2) + DCSR;
-	writel(readl(phy->base + reg) & ~DCSR_RUN, phy->base + reg);
+	dcsr = readl(phy->base + reg);
+
+	if (phy->vchan) {
+		struct mmp_pdma_device *pdev;
+
+		pdev = to_mmp_pdma_dev(phy->vchan->chan.device);
+		writel(dcsr & ~pdev->config->run_bits, phy->base + reg);
+	} else {
+		/* If no vchan, just clear the RUN bit */
+		writel(dcsr & ~DCSR_RUN, phy->base + reg);
+	}
 }
 
 static int clear_chan_irq(struct mmp_pdma_phy *phy)
@@ -297,6 +411,7 @@ static void mmp_pdma_free_phy(struct mmp_pdma_chan *pchan)
 static void start_pending_queue(struct mmp_pdma_chan *chan)
 {
 	struct mmp_pdma_desc_sw *desc;
+	struct mmp_pdma_device *pdev = to_mmp_pdma_dev(chan->chan.device);
 
 	/* still in running, irq will start the pending list */
 	if (!chan->idle) {
@@ -331,7 +446,7 @@ static void start_pending_queue(struct mmp_pdma_chan *chan)
 	 * Program the descriptor's address into the DMA controller,
 	 * then start the DMA transaction
 	 */
-	set_desc(chan->phy, desc->async_tx.phys);
+	pdev->config->set_desc(chan->phy, desc->async_tx.phys);
 	enable_chan(chan->phy);
 	chan->idle = false;
 }
@@ -447,6 +562,7 @@ mmp_pdma_prep_memcpy(struct dma_chan *dchan,
 		     size_t len, unsigned long flags)
 {
 	struct mmp_pdma_chan *chan;
+	struct mmp_pdma_device *pdev = to_mmp_pdma_dev(dchan->device);
 	struct mmp_pdma_desc_sw *first = NULL, *prev = NULL, *new;
 	size_t copy = 0;
 
@@ -478,13 +594,17 @@ mmp_pdma_prep_memcpy(struct dma_chan *dchan,
 			chan->byte_align = true;
 
 		new->desc.dcmd = chan->dcmd | (DCMD_LENGTH & copy);
-		new->desc.dsadr = dma_src;
-		new->desc.dtadr = dma_dst;
+		pdma_desc_set_addr(pdev, &new->desc.dsadr, &new->desc.dsadrh,
+					 dma_src);
+		pdma_desc_set_addr(pdev, &new->desc.dtadr, &new->desc.dtadrh,
+					 dma_dst);
 
 		if (!first)
 			first = new;
 		else
-			prev->desc.ddadr = new->async_tx.phys;
+			pdma_desc_set_addr(pdev, &prev->desc.ddadr,
+						 &prev->desc.ddadrh,
+						 new->async_tx.phys);
 
 		new->async_tx.cookie = 0;
 		async_tx_ack(&new->async_tx);
@@ -528,6 +648,7 @@ mmp_pdma_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
 		       unsigned long flags, void *context)
 {
 	struct mmp_pdma_chan *chan = to_mmp_pdma_chan(dchan);
+	struct mmp_pdma_device *pdev = to_mmp_pdma_dev(dchan->device);
 	struct mmp_pdma_desc_sw *first = NULL, *prev = NULL, *new = NULL;
 	size_t len, avail;
 	struct scatterlist *sg;
@@ -559,17 +680,23 @@ mmp_pdma_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
 
 			new->desc.dcmd = chan->dcmd | (DCMD_LENGTH & len);
 			if (dir == DMA_MEM_TO_DEV) {
-				new->desc.dsadr = addr;
+				pdma_desc_set_addr(pdev, &new->desc.dsadr,
+							 &new->desc.dsadrh,
+							 addr);
 				new->desc.dtadr = chan->dev_addr;
 			} else {
 				new->desc.dsadr = chan->dev_addr;
-				new->desc.dtadr = addr;
+				pdma_desc_set_addr(pdev, &new->desc.dtadr,
+							 &new->desc.dtadrh,
+							 addr);
 			}
 
 			if (!first)
 				first = new;
 			else
-				prev->desc.ddadr = new->async_tx.phys;
+				pdma_desc_set_addr(pdev, &prev->desc.ddadr,
+							 &prev->desc.ddadrh,
+							 new->async_tx.phys);
 
 			new->async_tx.cookie = 0;
 			async_tx_ack(&new->async_tx);
@@ -609,6 +736,7 @@ mmp_pdma_prep_dma_cyclic(struct dma_chan *dchan,
 			 unsigned long flags)
 {
 	struct mmp_pdma_chan *chan;
+	struct mmp_pdma_device *pdev = to_mmp_pdma_dev(dchan->device);
 	struct mmp_pdma_desc_sw *first = NULL, *prev = NULL, *new;
 	dma_addr_t dma_src, dma_dst;
 
@@ -651,13 +779,17 @@ mmp_pdma_prep_dma_cyclic(struct dma_chan *dchan,
 
 		new->desc.dcmd = (chan->dcmd | DCMD_ENDIRQEN |
 				  (DCMD_LENGTH & period_len));
-		new->desc.dsadr = dma_src;
-		new->desc.dtadr = dma_dst;
+		pdma_desc_set_addr(pdev, &new->desc.dsadr, &new->desc.dsadrh,
+					 dma_src);
+		pdma_desc_set_addr(pdev, &new->desc.dtadr, &new->desc.dtadrh,
+					 dma_dst);
 
 		if (!first)
 			first = new;
 		else
-			prev->desc.ddadr = new->async_tx.phys;
+			pdma_desc_set_addr(pdev, &prev->desc.ddadr,
+						 &prev->desc.ddadrh,
+						 new->async_tx.phys);
 
 		new->async_tx.cookie = 0;
 		async_tx_ack(&new->async_tx);
@@ -678,7 +810,8 @@ mmp_pdma_prep_dma_cyclic(struct dma_chan *dchan,
 	first->async_tx.cookie = -EBUSY;
 
 	/* make the cyclic link */
-	new->desc.ddadr = first->async_tx.phys;
+	pdma_desc_set_addr(pdev, &new->desc.ddadr, &new->desc.ddadrh,
+				 first->async_tx.phys);
 	chan->cyclic_first = first;
 
 	return &first->async_tx;
@@ -764,7 +897,9 @@ static unsigned int mmp_pdma_residue(struct mmp_pdma_chan *chan,
 				     dma_cookie_t cookie)
 {
 	struct mmp_pdma_desc_sw *sw;
-	u32 curr, residue = 0;
+	struct mmp_pdma_device *pdev = to_mmp_pdma_dev(chan->chan.device);
+	u64 curr;
+	u32 residue = 0;
 	bool passed = false;
 	bool cyclic = chan->cyclic_first != NULL;
 
@@ -776,17 +911,24 @@ static unsigned int mmp_pdma_residue(struct mmp_pdma_chan *chan,
 		return 0;
 
 	if (chan->dir == DMA_DEV_TO_MEM)
-		curr = readl(chan->phy->base + DTADR(chan->phy->idx));
+		curr = pdma_read_addr(chan->phy, pdev,
+				      DTADR(chan->phy->idx),
+				      DTADRH(chan->phy->idx));
 	else
-		curr = readl(chan->phy->base + DSADR(chan->phy->idx));
+		curr = pdma_read_addr(chan->phy, pdev,
+				      DSADR(chan->phy->idx),
+				      DSADRH(chan->phy->idx));
 
 	list_for_each_entry(sw, &chan->chain_running, node) {
-		u32 start, end, len;
+		u64 start, end;
+		u32 len;
 
 		if (chan->dir == DMA_DEV_TO_MEM)
-			start = sw->desc.dtadr;
+			start = pdma_desc_addr(pdev, sw->desc.dtadr,
+						     sw->desc.dtadrh);
 		else
-			start = sw->desc.dsadr;
+			start = pdma_desc_addr(pdev, sw->desc.dsadr,
+						     sw->desc.dsadrh);
 
 		len = sw->desc.dcmd & DCMD_LENGTH;
 		end = start + len;
@@ -802,7 +944,7 @@ static unsigned int mmp_pdma_residue(struct mmp_pdma_chan *chan,
 		if (passed) {
 			residue += len;
 		} else if (curr >= start && curr <= end) {
-			residue += end - curr;
+			residue += (u32)(end - curr);
 			passed = true;
 		}
 
@@ -996,9 +1138,34 @@ static int mmp_pdma_chan_init(struct mmp_pdma_device *pdev, int idx, int irq)
 	return 0;
 }
 
+static const struct mmp_pdma_ops marvell_pdma_v1_config = {
+	.set_desc = set_desc_32,
+	.addr_split = addr_split_32,
+	.addr_join = addr_join_32,
+	.reg_read64 = reg_read64_32,
+	.run_bits = (DCSR_RUN),
+	.dma_mask = 0,			/* let OF/platform set DMA mask */
+};
+
+static const struct mmp_pdma_ops spacemit_k1_pdma_v1_config = {
+	.set_desc = set_desc_64,
+	.addr_split = addr_split_64,
+	.addr_join = addr_join_64,
+	.reg_read64 = reg_read64_64,
+	.run_bits = (DCSR_RUN | DCSR_LPAEEN),
+	.dma_mask = DMA_BIT_MASK(64),	/* force 64-bit DMA addr capability */
+};
+
 static const struct of_device_id mmp_pdma_dt_ids[] = {
-	{ .compatible = "marvell,pdma-1.0", },
-	{}
+	{
+		.compatible = "marvell,pdma-1.0",
+		.data = &marvell_pdma_v1_config
+	}, {
+		.compatible = "spacemit,pdma-1.0",
+		.data = &spacemit_k1_pdma_v1_config
+	}, {
+		/* sentinel */
+	}
 };
 MODULE_DEVICE_TABLE(of, mmp_pdma_dt_ids);
 
@@ -1050,6 +1217,10 @@ static int mmp_pdma_probe(struct platform_device *op)
 	if (IS_ERR(rst))
 		return PTR_ERR(rst);
 
+	pdev->config = of_device_get_match_data(&op->dev);
+	if (!pdev->config)
+		return -ENODEV;
+
 	if (pdev->dev->of_node) {
 		/* Parse new and deprecated dma-channels properties */
 		if (of_property_read_u32(pdev->dev->of_node, "dma-channels",
@@ -1111,7 +1282,10 @@ static int mmp_pdma_probe(struct platform_device *op)
 	pdev->device.directions = BIT(DMA_MEM_TO_DEV) | BIT(DMA_DEV_TO_MEM);
 	pdev->device.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
 
-	if (pdev->dev->coherent_dma_mask)
+	/* Set DMA mask based on config, or OF/platform */
+	if (pdev->config->dma_mask)
+		dma_set_mask(pdev->dev, pdev->config->dma_mask);
+	else if (pdev->dev->coherent_dma_mask)
 		dma_set_mask(pdev->dev, pdev->dev->coherent_dma_mask);
 	else
 		dma_set_mask(pdev->dev, DMA_BIT_MASK(64));
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 5/8] riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC

[Guodong Xu]

Reorganize the K1 SoC device tree to better reflect the hardware topology
by introducing a dedicated dma_bus node that groups devices sharing
the same address translation scheme. This change aligns with the actual
hardware organization where devices are physically connected to different
bus segments with different address translation characteristics.

The changes include:
- New dma_bus node with:
  * DMA address translation ranges:
    - First range:  0x0_00000000 -> 0x0_00000000 (size: 2GB)
    - Second range: 0x1_00000000 -> 0x1_80000000 (size: 12GB)
  * All UART devices moved under this bus to reflect their shared address
    translation domain

- New PDMA controller node under dma_bus with:
  * Base address and interrupt configuration
  * Clock and reset controls
  * 16 DMA channels
  * Required DMA cell properties

The PDMA node is marked as disabled by default, allowing board-specific
device trees to enable it as needed.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 arch/riscv/boot/dts/spacemit/k1.dtsi | 234 +++++++++++++++------------
 1 file changed, 128 insertions(+), 106 deletions(-)

diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index dead05a3c816..557feac860de 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -369,112 +369,13 @@ syscon_apbc: system-controller@d4015000 {
 			#reset-cells = <1>;
 		};
 
-		uart0: serial@d4017000 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017000 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART0>,
-				 <&syscon_apbc CLK_UART0_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <42>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart2: serial@d4017100 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017100 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART2>,
-				 <&syscon_apbc CLK_UART2_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <44>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart3: serial@d4017200 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017200 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART3>,
-				 <&syscon_apbc CLK_UART3_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <45>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart4: serial@d4017300 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017300 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART4>,
-				 <&syscon_apbc CLK_UART4_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <46>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart5: serial@d4017400 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017400 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART5>,
-				 <&syscon_apbc CLK_UART5_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <47>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart6: serial@d4017500 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017500 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART6>,
-				 <&syscon_apbc CLK_UART6_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <48>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart7: serial@d4017600 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017600 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART7>,
-				 <&syscon_apbc CLK_UART7_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <49>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart8: serial@d4017700 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017700 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART8>,
-				 <&syscon_apbc CLK_UART8_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <50>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
-		};
-
-		uart9: serial@d4017800 {
-			compatible = "spacemit,k1-uart", "intel,xscale-uart";
-			reg = <0x0 0xd4017800 0x0 0x100>;
-			clocks = <&syscon_apbc CLK_UART9>,
-				 <&syscon_apbc CLK_UART9_BUS>;
-			clock-names = "core", "bus";
-			interrupts = <51>;
-			reg-shift = <2>;
-			reg-io-width = <4>;
-			status = "disabled";
+		dma_bus: bus@4 {
+			compatible = "simple-bus";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
+				     <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
+			ranges;
 		};
 
 		gpio: gpio@d4019000 {
@@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
 		};
 	};
 };
+
+&dma_bus {
+	pdma0: dma-controller@d4000000 {
+		compatible = "spacemit,pdma-1.0";
+		reg = <0x0 0xd4000000 0x0 0x4000>;
+		interrupts = <72>;
+		clocks = <&syscon_apmu CLK_DMA>;
+		resets = <&syscon_apmu RESET_DMA>;
+		#dma-cells= <2>;
+		#dma-channels = <16>;
+		status = "disabled";
+	};
+
+	uart0: serial@d4017000 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017000 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART0>,
+			 <&syscon_apbc CLK_UART0_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <42>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart2: serial@d4017100 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017100 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART2>,
+			 <&syscon_apbc CLK_UART2_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <44>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart3: serial@d4017200 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017200 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART3>,
+			 <&syscon_apbc CLK_UART3_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <45>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart4: serial@d4017300 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017300 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART4>,
+			 <&syscon_apbc CLK_UART4_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <46>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart5: serial@d4017400 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017400 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART5>,
+			 <&syscon_apbc CLK_UART5_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <47>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart6: serial@d4017500 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017500 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART6>,
+			 <&syscon_apbc CLK_UART6_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <48>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart7: serial@d4017600 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017600 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART7>,
+			 <&syscon_apbc CLK_UART7_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <49>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart8: serial@d4017700 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017700 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART8>,
+			 <&syscon_apbc CLK_UART8_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <50>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+
+	uart9: serial@d4017800 {
+		compatible = "spacemit,k1-uart", "intel,xscale-uart";
+		reg = <0x0 0xd4017800 0x0 0x100>;
+		clocks = <&syscon_apbc CLK_UART9>,
+			 <&syscon_apbc CLK_UART9_BUS>;
+		clock-names = "core", "bus";
+		interrupts = <51>;
+		reg-shift = <2>;
+		reg-io-width = <4>;
+		status = "disabled";
+	};
+}; /* &dma_bus */
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 6/8] riscv: dts: spacemit: Enable PDMA0 controller on Banana Pi F3

[Guodong Xu]

Enable the Peripheral DMA controller (PDMA0) on the SpacemiT K1-based
Banana Pi F3 board by setting its status to "okay". This board-specific
configuration activates the PDMA controller defined in the SoC's base
device tree.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 2363f0e65724..115222c065ab 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -45,3 +45,7 @@ &uart0 {
 	pinctrl-0 = <&uart0_2_cfg>;
 	status = "okay";
 };
+
+&pdma0 {
+	status = "okay";
+};
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 7/8] dma: Kconfig: MMP_PDMA: Add support for ARCH_SPACEMIT

[Guodong Xu]

Extend the MMP_PDMA driver to support the SpacemiT architecture
by adding ARCH_SPACEMIT as a dependency in Kconfig.

This allows the driver to be built for SpacemiT-based platforms
alongside existing ARCH_MMP and ARCH_PXA architectures.

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index db87dd2a07f7..fff70f66c773 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -451,7 +451,7 @@ config MILBEAUT_XDMAC
 
 config MMP_PDMA
 	tristate "MMP PDMA support"
-	depends on ARCH_MMP || ARCH_PXA || COMPILE_TEST
+	depends on ARCH_MMP || ARCH_PXA || ARCH_SPACEMIT || COMPILE_TEST
 	select DMA_ENGINE
 	help
 	  Support the MMP PDMA engine for PXA and MMP platform.
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH 8/8] riscv: defconfig: Enable MMP_PDMA support for SpacemiT K1 SoC

[Guodong Xu]

Enable CONFIG_MMP_PDMA in the riscv defconfig for SpacemiT K1 SoC boards
like the BananaPI-F3 (BPI-F3) and the Sipeed LicheePi 3A.

According to make savedefconfig, the position of CONFIG_DWMAC_THEAD=m
should be in another place. It was updated in this patch.

CONFIG_DWMAC_THEAD was initially introduced into riscv defconfig in
commit 0207244ea0e7 ("riscv: defconfig: enable pinctrl and dwmac support
for TH1520")

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
 arch/riscv/configs/defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 517cc4c99efc..83d0366194ba 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -134,6 +134,7 @@ CONFIG_MACB=y
 CONFIG_E1000E=y
 CONFIG_R8169=y
 CONFIG_STMMAC_ETH=m
+CONFIG_DWMAC_THEAD=m
 CONFIG_MICREL_PHY=y
 CONFIG_MICROSEMI_PHY=y
 CONFIG_MOTORCOMM_PHY=y
@@ -240,7 +241,7 @@ CONFIG_RTC_DRV_SUN6I=y
 CONFIG_DMADEVICES=y
 CONFIG_DMA_SUN6I=m
 CONFIG_DW_AXI_DMAC=y
-CONFIG_DWMAC_THEAD=m
+CONFIG_MMP_PDMA=m
 CONFIG_VIRTIO_PCI=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_INPUT=y
-- 
2.43.0


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 8/8] riscv: defconfig: Enable MMP_PDMA support for SpacemiT K1 SoC

[Yixun Lan]

Hi Guodong,

On 20:57 Wed 11 Jun     , Guodong Xu wrote:
> Enable CONFIG_MMP_PDMA in the riscv defconfig for SpacemiT K1 SoC boards
> like the BananaPI-F3 (BPI-F3) and the Sipeed LicheePi 3A.
> 
> According to make savedefconfig, the position of CONFIG_DWMAC_THEAD=m
> should be in another place. It was updated in this patch.
I don't really like those unrelated changes brought into this patch,
either having an independent patch to fix "make savedefconfig" issue,
then enable PDMA in follow-up patch, or just ignore it?

> 
> CONFIG_DWMAC_THEAD was initially introduced into riscv defconfig in
> commit 0207244ea0e7 ("riscv: defconfig: enable pinctrl and dwmac support
> for TH1520")
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  arch/riscv/configs/defconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index 517cc4c99efc..83d0366194ba 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -134,6 +134,7 @@ CONFIG_MACB=y
>  CONFIG_E1000E=y
>  CONFIG_R8169=y
>  CONFIG_STMMAC_ETH=m
> +CONFIG_DWMAC_THEAD=m
>  CONFIG_MICREL_PHY=y
>  CONFIG_MICROSEMI_PHY=y
>  CONFIG_MOTORCOMM_PHY=y
> @@ -240,7 +241,7 @@ CONFIG_RTC_DRV_SUN6I=y
>  CONFIG_DMADEVICES=y
>  CONFIG_DMA_SUN6I=m
>  CONFIG_DW_AXI_DMAC=y
> -CONFIG_DWMAC_THEAD=m
> +CONFIG_MMP_PDMA=m
>  CONFIG_VIRTIO_PCI=y
>  CONFIG_VIRTIO_BALLOON=y
>  CONFIG_VIRTIO_INPUT=y
> -- 
> 2.43.0
> 

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 7/8] dma: Kconfig: MMP_PDMA: Add support for ARCH_SPACEMIT

[Yixun Lan]

Hi Guodong,
  I'd suggest moving this patch after 4/8, as both of them should go
via DMA susbystem tree, or simply squash them?

On 20:57 Wed 11 Jun     , Guodong Xu wrote:
> Extend the MMP_PDMA driver to support the SpacemiT architecture
> by adding ARCH_SPACEMIT as a dependency in Kconfig.
> 
> This allows the driver to be built for SpacemiT-based platforms
> alongside existing ARCH_MMP and ARCH_PXA architectures.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  drivers/dma/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index db87dd2a07f7..fff70f66c773 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -451,7 +451,7 @@ config MILBEAUT_XDMAC
>  
>  config MMP_PDMA
>  	tristate "MMP PDMA support"
> -	depends on ARCH_MMP || ARCH_PXA || COMPILE_TEST
> +	depends on ARCH_MMP || ARCH_PXA || ARCH_SPACEMIT || COMPILE_TEST
>  	select DMA_ENGINE
>  	help
>  	  Support the MMP PDMA engine for PXA and MMP platform.
> -- 
> 2.43.0
> 
> 

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 6/8] riscv: dts: spacemit: Enable PDMA0 controller on Banana Pi F3

[Yixun Lan]

Hi Guodong,

On 20:57 Wed 11 Jun     , Guodong Xu wrote:
> Enable the Peripheral DMA controller (PDMA0) on the SpacemiT K1-based
> Banana Pi F3 board by setting its status to "okay". This board-specific
> configuration activates the PDMA controller defined in the SoC's base
> device tree.
> 
  Although this series is actively developed under Bananapi-f3 board
but it should work fine with jupiter board, so I'd suggest to enable
it too, thanks

> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> index 2363f0e65724..115222c065ab 100644
> --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> @@ -45,3 +45,7 @@ &uart0 {
>  	pinctrl-0 = <&uart0_2_cfg>;
>  	status = "okay";
>  };
> +
> +&pdma0 {
> +	status = "okay";
> +};
> -- 
> 2.43.0
> 
> 

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 6/8] riscv: dts: spacemit: Enable PDMA0 controller on Banana Pi F3

[Guodong Xu]

On Wed, Jun 11, 2025 at 9:58 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Guodong,
>
> On 20:57 Wed 11 Jun     , Guodong Xu wrote:
> > Enable the Peripheral DMA controller (PDMA0) on the SpacemiT K1-based
> > Banana Pi F3 board by setting its status to "okay". This board-specific
> > configuration activates the PDMA controller defined in the SoC's base
> > device tree.
> >
>   Although this series is actively developed under Bananapi-f3 board
> but it should work fine with jupiter board, so I'd suggest to enable
> it too, thanks
>

I'd be glad to include the Jupiter board as well. Since I don't have Jupiter
hardware for testing, could someone with access verify it works before I
add it to the series?

-Guodong

> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > index 2363f0e65724..115222c065ab 100644
> > --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > @@ -45,3 +45,7 @@ &uart0 {
> >       pinctrl-0 = <&uart0_2_cfg>;
> >       status = "okay";
> >  };
> > +
> > +&pdma0 {
> > +     status = "okay";
> > +};
> > --
> > 2.43.0
> >
> >
>
> --
> Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 7/8] dma: Kconfig: MMP_PDMA: Add support for ARCH_SPACEMIT

[Guodong Xu]

On Wed, Jun 11, 2025 at 9:51 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Guodong,
>   I'd suggest moving this patch after 4/8, as both of them should go
> via DMA susbystem tree, or simply squash them?
>

Thanks for your advice. Agree. It makes sense.
I will arrange them.

-Guodong

> On 20:57 Wed 11 Jun     , Guodong Xu wrote:
> > Extend the MMP_PDMA driver to support the SpacemiT architecture
> > by adding ARCH_SPACEMIT as a dependency in Kconfig.
> >
> > This allows the driver to be built for SpacemiT-based platforms
> > alongside existing ARCH_MMP and ARCH_PXA architectures.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  drivers/dma/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index db87dd2a07f7..fff70f66c773 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -451,7 +451,7 @@ config MILBEAUT_XDMAC
> >
> >  config MMP_PDMA
> >       tristate "MMP PDMA support"
> > -     depends on ARCH_MMP || ARCH_PXA || COMPILE_TEST
> > +     depends on ARCH_MMP || ARCH_PXA || ARCH_SPACEMIT || COMPILE_TEST
> >       select DMA_ENGINE
> >       help
> >         Support the MMP PDMA engine for PXA and MMP platform.
> > --
> > 2.43.0
> >
> >
>
> --
> Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 6/8] riscv: dts: spacemit: Enable PDMA0 controller on Banana Pi F3

[Yixun Lan]

Hi Guodong,

On 22:32 Wed 11 Jun     , Guodong Xu wrote:
> On Wed, Jun 11, 2025 at 9:58 PM Yixun Lan <dlan@gentoo.org> wrote:
> >
> > Hi Guodong,
> >
> > On 20:57 Wed 11 Jun     , Guodong Xu wrote:
> > > Enable the Peripheral DMA controller (PDMA0) on the SpacemiT K1-based
> > > Banana Pi F3 board by setting its status to "okay". This board-specific
> > > configuration activates the PDMA controller defined in the SoC's base
> > > device tree.
> > >
> >   Although this series is actively developed under Bananapi-f3 board
> > but it should work fine with jupiter board, so I'd suggest to enable
> > it too, thanks
> >
> 
> I'd be glad to include the Jupiter board as well. Since I don't have Jupiter
> hardware for testing, could someone with access verify it works before I
> add it to the series?
> 
Do you have any suggestion how to test? like if any test cases there?

I would assume it work fine on jupiter since it's a SoC level feature?
instead of board specific..

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT PDMA compatibility

[Conor Dooley]

[-- Attachment #1.1: Type: text/plain, Size: 2548 bytes --]

On Wed, Jun 11, 2025 at 08:57:16PM +0800, Guodong Xu wrote:
> Add "spacemit,pdma-1.0" compatible string to support SpacemiT PDMA
> controller in the Marvell MMP DMA device tree bindings. This enables:
> 
> - Support for SpacemiT PDMA controller configuration
> - New optional properties for platform-specific integration:
>   * clocks: Clock controller for the DMA
>   * resets: Reset controller for the DMA
> 
> Also, add explicit #dma-cells property definition to avoid
> "make dtbs_check W=3" warnings about unevaluated properties.
> 
> The #dma-cells property is defined as 2 cells to maintain compatibility
> with existing ARM device trees. The first cell specifies the DMA request
> line number, while the second cell is currently unused by the driver but
> required for backward compatibility with PXA device tree files.
> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  .../bindings/dma/marvell,mmp-dma.yaml           | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> index d447d5207be0..e117a81414bd 100644
> --- a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> +++ b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> @@ -18,6 +18,7 @@ properties:
>        - marvell,pdma-1.0
>        - marvell,adma-1.0
>        - marvell,pxa910-squ
> +      - spacemit,pdma-1.0

You need a soc-specific compatible here.

>  
>    reg:
>      maxItems: 1
> @@ -32,6 +33,21 @@ properties:
>        A phandle to the SRAM pool
>      $ref: /schemas/types.yaml#/definitions/phandle
>  
> +  clocks:
> +    description: Clock for the controller
> +    maxItems: 1
> +
> +  resets:
> +    description: Reset controller for the DMA controller
> +    maxItems: 1
> +
> +  '#dma-cells':
> +    const: 2
> +    description:
> +      The first cell contains the DMA request number for the peripheral
> +      device. The second cell is currently unused but must be present for
> +      backward compatibility.

These properties are only valid for your new device, right?
If so, please restrict them to only the spacemit platform.

> +
>    '#dma-channels':
>      deprecated: true
>  
> @@ -52,6 +68,7 @@ allOf:
>            contains:
>              enum:
>                - marvell,pdma-1.0
> +              - spacemit,pdma-1.0
>      then:
>        properties:
>          asram: false
> -- 
> 2.43.0
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT PDMA compatibility

[Yixun Lan]

On 17:27 Wed 11 Jun     , Conor Dooley wrote:
> On Wed, Jun 11, 2025 at 08:57:16PM +0800, Guodong Xu wrote:
> > Add "spacemit,pdma-1.0" compatible string to support SpacemiT PDMA
> > controller in the Marvell MMP DMA device tree bindings. This enables:
> > 
> > - Support for SpacemiT PDMA controller configuration
> > - New optional properties for platform-specific integration:
> >   * clocks: Clock controller for the DMA
> >   * resets: Reset controller for the DMA
> > 
> > Also, add explicit #dma-cells property definition to avoid
> > "make dtbs_check W=3" warnings about unevaluated properties.
> > 
> > The #dma-cells property is defined as 2 cells to maintain compatibility
> > with existing ARM device trees. The first cell specifies the DMA request
> > line number, while the second cell is currently unused by the driver but
> > required for backward compatibility with PXA device tree files.
> > 
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  .../bindings/dma/marvell,mmp-dma.yaml           | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > index d447d5207be0..e117a81414bd 100644
> > --- a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > +++ b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > @@ -18,6 +18,7 @@ properties:
> >        - marvell,pdma-1.0
> >        - marvell,adma-1.0
> >        - marvell,pxa910-squ
> > +      - spacemit,pdma-1.0
> 
> You need a soc-specific compatible here.
> 
is the version number (1.0 here) actually documented anywhere?

otherwise I'd suggest using "spacemit,k1-pdma" which follow the convention
which already done for spacemit in other components..

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT PDMA compatibility

[Guodong Xu]

On Thu, Jun 12, 2025 at 12:27 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Wed, Jun 11, 2025 at 08:57:16PM +0800, Guodong Xu wrote:
> > Add "spacemit,pdma-1.0" compatible string to support SpacemiT PDMA
> > controller in the Marvell MMP DMA device tree bindings. This enables:
> >
> > - Support for SpacemiT PDMA controller configuration
> > - New optional properties for platform-specific integration:
> >   * clocks: Clock controller for the DMA
> >   * resets: Reset controller for the DMA
> >
> > Also, add explicit #dma-cells property definition to avoid
> > "make dtbs_check W=3" warnings about unevaluated properties.
> >
> > The #dma-cells property is defined as 2 cells to maintain compatibility
> > with existing ARM device trees. The first cell specifies the DMA request
> > line number, while the second cell is currently unused by the driver but
> > required for backward compatibility with PXA device tree files.
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  .../bindings/dma/marvell,mmp-dma.yaml           | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > index d447d5207be0..e117a81414bd 100644
> > --- a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > +++ b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > @@ -18,6 +18,7 @@ properties:
> >        - marvell,pdma-1.0
> >        - marvell,adma-1.0
> >        - marvell,pxa910-squ
> > +      - spacemit,pdma-1.0
>
> You need a soc-specific compatible here.
>
> >
> >    reg:
> >      maxItems: 1
> > @@ -32,6 +33,21 @@ properties:
> >        A phandle to the SRAM pool
> >      $ref: /schemas/types.yaml#/definitions/phandle
> >
> > +  clocks:
> > +    description: Clock for the controller
> > +    maxItems: 1
> > +
> > +  resets:
> > +    description: Reset controller for the DMA controller
> > +    maxItems: 1
> > +
> > +  '#dma-cells':
> > +    const: 2
> > +    description:
> > +      The first cell contains the DMA request number for the peripheral
> > +      device. The second cell is currently unused but must be present for
> > +      backward compatibility.
>
> These properties are only valid for your new device, right?
> If so, please restrict them to only the spacemit platform.
>

For clocks and resets, yes that's correct, only for spacemit k1. I'll add
conditional constraints to restrict them to the spacemit platform.

Regarding #dma-cells, it's used by other platforms too. You are right that
it requires clarification. I should have been more careful in my initial
analysis.

After reviewing the in-tree device trees and driver code, here's what I found:

For PDMA controllers:
Both "marvell,pdma-1.0" and the spacemit pdma use #dma-cells = <2>;
Handled by drivers/dma/mmp_pdma.c with _xlate() callback

For ADMA/audio controllers:
"marvell,adma-1.0" uses #dma-cells = <1>

"marvell,pxa910-squ" is not found in any in-tree device trees, but based
on the original TXT binding [1], both adma and pxa910-squ are "Marvell
Two Channel DMA Controller used specifically for audio", and the shared
driver code (drivers/dma/mmp_tdma.c) also shows it should use
#dma-cells = <1>.

So, I'll add conditional constraints in the allOf section.
For "marvell,pdma-1.0" and spacemit pdma, #dma-cells must be 2;
For "marvell,adma-1.0" and "marvell,pxa910-squ", #dma-cells must be 1.
Also, as said, I will restrict clocks and resets to spacemit only.

Thank you again for catching this. Let me know what you think.

Link: https://lore.kernel.org/all/20240131-pxa-dma-yaml-v2-2-9611d0af0edc@skole.hr/
[1]

-Guodong


> > +
> >    '#dma-channels':
> >      deprecated: true
> >
> > @@ -52,6 +68,7 @@ allOf:
> >            contains:
> >              enum:
> >                - marvell,pdma-1.0
> > +              - spacemit,pdma-1.0
> >      then:
> >        properties:
> >          asram: false
> > --
> > 2.43.0
> >

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 1/8] dt-bindings: dma: marvell,mmp-dma: Add SpacemiT PDMA compatibility

[Guodong Xu]

On Thu, Jun 12, 2025 at 8:03 AM Yixun Lan <dlan@gentoo.org> wrote:
>
> On 17:27 Wed 11 Jun     , Conor Dooley wrote:
> > On Wed, Jun 11, 2025 at 08:57:16PM +0800, Guodong Xu wrote:
> > > Add "spacemit,pdma-1.0" compatible string to support SpacemiT PDMA
> > > controller in the Marvell MMP DMA device tree bindings. This enables:
> > >
> > > - Support for SpacemiT PDMA controller configuration
> > > - New optional properties for platform-specific integration:
> > >   * clocks: Clock controller for the DMA
> > >   * resets: Reset controller for the DMA
> > >
> > > Also, add explicit #dma-cells property definition to avoid
> > > "make dtbs_check W=3" warnings about unevaluated properties.
> > >
> > > The #dma-cells property is defined as 2 cells to maintain compatibility
> > > with existing ARM device trees. The first cell specifies the DMA request
> > > line number, while the second cell is currently unused by the driver but
> > > required for backward compatibility with PXA device tree files.
> > >
> > > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > > ---
> > >  .../bindings/dma/marvell,mmp-dma.yaml           | 17 +++++++++++++++++
> > >  1 file changed, 17 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > > index d447d5207be0..e117a81414bd 100644
> > > --- a/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > > +++ b/Documentation/devicetree/bindings/dma/marvell,mmp-dma.yaml
> > > @@ -18,6 +18,7 @@ properties:
> > >        - marvell,pdma-1.0
> > >        - marvell,adma-1.0
> > >        - marvell,pxa910-squ
> > > +      - spacemit,pdma-1.0
> >
> > You need a soc-specific compatible here.
> >
> is the version number (1.0 here) actually documented anywhere?
>
> otherwise I'd suggest using "spacemit,k1-pdma" which follow the convention
> which already done for spacemit in other components..
>

Thanks Conor and Yixun. I will take this compatible string
"spacemit,k1-pdma".

-Guodong

> --
> Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 6/8] riscv: dts: spacemit: Enable PDMA0 controller on Banana Pi F3

[Guodong Xu]

On Wed, Jun 11, 2025 at 11:02 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Guodong,
>
> On 22:32 Wed 11 Jun     , Guodong Xu wrote:
> > On Wed, Jun 11, 2025 at 9:58 PM Yixun Lan <dlan@gentoo.org> wrote:
> > >
> > > Hi Guodong,
> > >
> > > On 20:57 Wed 11 Jun     , Guodong Xu wrote:
> > > > Enable the Peripheral DMA controller (PDMA0) on the SpacemiT K1-based
> > > > Banana Pi F3 board by setting its status to "okay". This board-specific
> > > > configuration activates the PDMA controller defined in the SoC's base
> > > > device tree.
> > > >
> > >   Although this series is actively developed under Bananapi-f3 board
> > > but it should work fine with jupiter board, so I'd suggest to enable
> > > it too, thanks
> > >
> >
> > I'd be glad to include the Jupiter board as well. Since I don't have Jupiter
> > hardware for testing, could someone with access verify it works before I
> > add it to the series?
> >
> Do you have any suggestion how to test? like if any test cases there?
>

I am using the dmatest (CONFIG_DMATEST) for memory-to-memory
and using spi3 to test device-to-memory / memory-to-device.

> I would assume it work fine on jupiter since it's a SoC level feature?
> instead of board specific..
>

Yeah, that's a SoC level device. I would say a boot test and some
basic mem-to-mem test should be enough.

-Guodong

> --
> Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 5/8] riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC

[Vivian Wang]

Hi Guodong,

On 6/11/25 20:57, Guodong Xu wrote:
> <snip>
>
> -			status = "disabled";
> +		dma_bus: bus@4 {
> +			compatible = "simple-bus";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> +				     <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> +			ranges;
>  		};

Can the addition of dma_bus and movement of nodes under it be extracted
into a separate patch, and ideally, taken up by Yixun Lan without going
through dmaengine? Not specifically "dram_range4", but all of these
translations affects many devices on the SoC, including ethernet and
USB3. See:

https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/

(I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
none, but ideally we should fix this.)

DMA address translation does not depend on PDMA. It would be best if we
get all the possible dma-ranges buses handled in one place, instead of
everyone moving nodes around.

@Ze Huang: This affects your "MBUS" changes as well. Please take a look,
thanks.

>  
>  		gpio: gpio@d4019000 {
> @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
>  		};
>  	};
>  };
> +
> +&dma_bus {
>
> <snip>


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 5/8] riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC

[Yixun Lan]

Hi Vivian, Guodong,

On 11:06 Fri 13 Jun     , Vivian Wang wrote:
> Hi Guodong,
> 
> On 6/11/25 20:57, Guodong Xu wrote:
> > <snip>
> >
> > -			status = "disabled";
> > +		dma_bus: bus@4 {
> > +			compatible = "simple-bus";
> > +			#address-cells = <2>;
> > +			#size-cells = <2>;
> > +			dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > +				     <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > +			ranges;
> >  		};
> 
> Can the addition of dma_bus and movement of nodes under it be extracted
> into a separate patch, and ideally, taken up by Yixun Lan without going
> through dmaengine? Not specifically "dram_range4", but all of these
> translations affects many devices on the SoC, including ethernet and
> USB3. See:
Right, we've had an offline discussion, and agreed on this - have *bus
patches separated and let other patches depend on it.

But seems Guodong failed to do this or just sent out an old version
of the PDMA patch?

> 
> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
> 
> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> none, but ideally we should fix this.)
> 
> DMA address translation does not depend on PDMA. It would be best if we
> get all the possible dma-ranges buses handled in one place, instead of
> everyone moving nodes around.
> 
I agree

> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> thanks.
> 
> >  
> >  		gpio: gpio@d4019000 {
> > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> >  		};
> >  	};
> >  };
> > +
> > +&dma_bus {
> >
> > <snip>
> 

-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 5/8] riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC

[Ze Huang]

On Fri, Jun 13, 2025 at 11:06:43AM +0800, Vivian Wang wrote:
> Hi Guodong,
> 
> On 6/11/25 20:57, Guodong Xu wrote:
> > <snip>
> >
> > -			status = "disabled";
> > +		dma_bus: bus@4 {
> > +			compatible = "simple-bus";
> > +			#address-cells = <2>;
> > +			#size-cells = <2>;
> > +			dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > +				     <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > +			ranges;
> >  		};
> 
> Can the addition of dma_bus and movement of nodes under it be extracted
> into a separate patch, and ideally, taken up by Yixun Lan without going
> through dmaengine? Not specifically "dram_range4", but all of these
> translations affects many devices on the SoC, including ethernet and
> USB3. See:
> 
> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
> 
> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> none, but ideally we should fix this.)
> 
> DMA address translation does not depend on PDMA. It would be best if we
> get all the possible dma-ranges buses handled in one place, instead of
> everyone moving nodes around.

Agree

> 
> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> thanks.

Thanks for reminding. I would drop MBUS and follow the "dma_bus" approach.

> 
> >  
> >  		gpio: gpio@d4019000 {
> > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> >  		};
> >  	};
> >  };
> > +
> > +&dma_bus {
> >
> > <snip>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 5/8] riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC

[Guodong Xu]

On Fri, Jun 13, 2025 at 11:07 AM Vivian Wang <uwu@dram.page> wrote:
>
> Hi Guodong,
>
> On 6/11/25 20:57, Guodong Xu wrote:
> > <snip>
> >
> > -                     status = "disabled";
> > +             dma_bus: bus@4 {
> > +                     compatible = "simple-bus";
> > +                     #address-cells = <2>;
> > +                     #size-cells = <2>;
> > +                     dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > +                                  <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > +                     ranges;
> >               };
>
> Can the addition of dma_bus and movement of nodes under it be extracted
> into a separate patch, and ideally, taken up by Yixun Lan without going
> through dmaengine? Not specifically "dram_range4", but all of these
> translations affects many devices on the SoC, including ethernet and

It was not my intention to add all the separate memory mapping buses into
one patch. I'd prefer to add them when there is at least one user.
The k1.dtsi at this moment, as I checked, has no real user beside the
so-called "dram_range4" in downstream vendor kernel (ie. dma_bus in this
patch). And that is what I did: grouping devices which share the same
dma address mapping as pdma0 into one single separated bus.

The other buses, even if I add them, would be empty.

What the SpacemiT team agreed upon so far, is the naming of these separated
buses. I listed them here for future reference purposes.

If needed, I can send that in a RFC patchset, of course; or as a normal
PATCH, if Yixun is ok with that. However, please note, that would mean more
merging dependencies: PDMA dts, ethernet dts, usb dts, will have to depend
on this base 'buses' PATCH.

Again, I prefer we add our own 'bus' when there is a need.

+       soc {
+               storage_bus: bus@0 {
+                       /* USB, SDH storage controllers */
+                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>;
+               };
+
+               multimedia_bus: bus@1 {
+                       /* VPU, GPU, DPU */
+                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+                                    <0x0 0x80000000 0x1 0x00000000
0x3 0x80000000>;
+               };
+
+               pcie_bus: bus@2 {
+                       /* PCIe controllers */
+                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+                                    <0x0 0xb8000000 0x1 0x38000000
0x3 0x48000000>;
+               };
+
+               camera_bus: bus@3 {
+                       /* ISP, CSI, imaging devices */
+                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+                                    <0x0 0x80000000 0x1 0x00000000
0x1 0x80000000>;
+               };
+
+               dma_bus: bus@4 {
+                       /* DMA controller, and users */
+                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+                                    <0x1 0x00000000 0x1 0x80000000
0x3 0x00000000>;
+               };
+
+               network_bus: bus@5 {
+                       /* Ethernet, Crypto, JPU */
+                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
0x0 0x80000000>,
+                                    <0x0 0x80000000 0x1 0x00000000
0x0 0x80000000>;
+               };
+
+       }; /* soc */

> USB3. See:
>
> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
>
> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> none, but ideally we should fix this.)

So, as you are submitting the first node(s) under network_bus: bus@5, you
should have this added into your patchset, instead of sending out with none.

The same logic goes to USB too, Ze Huang was in the same offline call, and
I would prefer that we move in a coordinated way.

>
> DMA address translation does not depend on PDMA. It would be best if we
> get all the possible dma-ranges buses handled in one place, instead of
> everyone moving nodes around.

No, you should do it in your patchset, when you add the eth0 and eth1 nodes,
they will be the first in, as I said, "network_bus". I don't expect
any 'moving nodes around'.

>
> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> thanks.
>
> >
> >               gpio: gpio@d4019000 {
> > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> >               };
> >       };
> >  };
> > +
> > +&dma_bus {
> >
> > <snip>
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 5/8] riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC

[Guodong Xu]

Hi, Yixun

On Fri, Jun 13, 2025 at 9:22 PM Yixun Lan <dlan@gentoo.org> wrote:
>
> Hi Vivian, Guodong,
>
> On 11:06 Fri 13 Jun     , Vivian Wang wrote:
> > Hi Guodong,
> >
> > On 6/11/25 20:57, Guodong Xu wrote:
> > > <snip>
> > >
> > > -                   status = "disabled";
> > > +           dma_bus: bus@4 {
> > > +                   compatible = "simple-bus";
> > > +                   #address-cells = <2>;
> > > +                   #size-cells = <2>;
> > > +                   dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
> > > +                                <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
> > > +                   ranges;
> > >             };
> >
> > Can the addition of dma_bus and movement of nodes under it be extracted
> > into a separate patch, and ideally, taken up by Yixun Lan without going
> > through dmaengine? Not specifically "dram_range4", but all of these
> > translations affects many devices on the SoC, including ethernet and
> > USB3. See:
> Right, we've had an offline discussion, and agreed on this - have *bus
> patches separated and let other patches depend on it.
>
> But seems Guodong failed to do this or just sent out an old version
> of the PDMA patch?

Hi, Yixun

I realized that there is some sort of discrepancy between our understanding
from the offline discussion. With the information I put in the other email
earlier today, do you still think we should submit one patch which
covers all 6 seperated memory mapping buses for k1.dtsi?

Let me know what do you think. Thank you.

BR,
Guodong

>
> >
> > https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/
> > https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/
> >
> > (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
> > none, but ideally we should fix this.)
> >
> > DMA address translation does not depend on PDMA. It would be best if we
> > get all the possible dma-ranges buses handled in one place, instead of
> > everyone moving nodes around.
> >
> I agree
>
> > @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
> > thanks.
> >
> > >
> > >             gpio: gpio@d4019000 {
> > > @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
> > >             };
> > >     };
> > >  };
> > > +
> > > +&dma_bus {
> > >
> > > <snip>
> >
>
> --
> Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 5/8] riscv: dts: spacemit: Add dma bus and PDMA node for K1 SoC

[Vivian Wang]

[Resent to get rid of HTML. This is my last try.]

On 6/14/25 10:53, Guodong Xu wrote:
> On Fri, Jun 13, 2025 at 11:07 AM Vivian Wang<uwu@dram.page> wrote:
>> Hi Guodong,
>>
>> On 6/11/25 20:57, Guodong Xu wrote:
>>> <snip>
>>>
>>> -                     status = "disabled";
>>> +             dma_bus: bus@4 {
>>> +                     compatible = "simple-bus";
>>> +                     #address-cells = <2>;
>>> +                     #size-cells = <2>;
>>> +                     dma-ranges = <0x0 0x00000000 0x0 0x00000000 
>>> 0x0 0x80000000>,
>>> +                                  <0x1 0x00000000 0x1 0x80000000 
>>> 0x3 0x00000000>;
>>> +                     ranges;
>>>                };
>> Can the addition of dma_bus and movement of nodes under it be extracted
>> into a separate patch, and ideally, taken up by Yixun Lan without going
>> through dmaengine? Not specifically "dram_range4", but all of these
>> translations affects many devices on the SoC, including ethernet and
> It was not my intention to add all the separate memory mapping buses into
> one patch. I'd prefer to add them when there is at least one user.
> The k1.dtsi at this moment, as I checked, has no real user beside the
> so-called "dram_range4" in downstream vendor kernel (ie. dma_bus in this
> patch). And that is what I did: grouping devices which share the same
> dma address mapping as pdma0 into one single separated bus.
>
> The other buses, even if I add them, would be empty.
>
> What the SpacemiT team agreed upon so far, is the naming of these 
> separated
> buses. I listed them here for future reference purposes.
>
> If needed, I can send that in a RFC patchset, of course; or as a normal
> PATCH, if Yixun is ok with that. However, please note, that would mean 
> more
> merging dependencies: PDMA dts, ethernet dts, usb dts, will have to 
> depend
> on this base 'buses' PATCH.
>
> Again, I prefer we add our own 'bus' when there is a need.
>
> +       soc {
> +               storage_bus: bus@0 {
> +                       /* USB, SDH storage controllers */
> +                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>;
> +               };
> +
> +               multimedia_bus: bus@1 {
> +                       /* VPU, GPU, DPU */
> +                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> +                                    <0x0 0x80000000 0x1 0x00000000
> 0x3 0x80000000>;
> +               };
> +
> +               pcie_bus: bus@2 {
> +                       /* PCIe controllers */
> +                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> +                                    <0x0 0xb8000000 0x1 0x38000000
> 0x3 0x48000000>;
> +               };
> +
> +               camera_bus: bus@3 {
> +                       /* ISP, CSI, imaging devices */
> +                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> +                                    <0x0 0x80000000 0x1 0x00000000
> 0x1 0x80000000>;
> +               };
> +
> +               dma_bus: bus@4 {
> +                       /* DMA controller, and users */
> +                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> +                                    <0x1 0x00000000 0x1 0x80000000
> 0x3 0x00000000>;
> +               };
> +
> +               network_bus: bus@5 {
> +                       /* Ethernet, Crypto, JPU */
> +                       dma-ranges = <0x0 0x00000000 0x0 0x00000000
> 0x0 0x80000000>,
> +                                    <0x0 0x80000000 0x1 0x00000000
> 0x0 0x80000000>;
> +               };
> +
> +       }; /* soc */

Ah, I didn't know the names were already decided.

However, I still think we should at least separate the patch into two in 
the same series, one adding the bus node and handling existing nodes, 
and another adding the new node under it. This way, say someone starts 
working on Crypto, they can simply depends on the first bus patch 
without having to pull in the new node.

I still prefer having a canonical buses patch though.

If we're going to agree here on what the buses should look, I also have 
two nitpicks, just so we get this sorted: Firstly, I think storage_bus 
should be removed. Anything using storage_bus is already handled by 
simply using 32-bit-only DMA, which is the default anyway. @Ze Huang: 
Your USB controller falls under it, what do you think?

Also, as suggested the node names must not have a made up unit address. 
"bus@1" is inappropriate because they have no reg. The simple-bus schema 
allows the node name to have a prefix like "foo-bus" [1] [2], so it 
should be like:

/* DMA controller, and users */
dma_bus: dma-bus {
     compatible = "simple-bus";
     ranges;
     #address-cells = <2>;
     #size-cells = <2>;
     dma-ranges = <0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>,
              <0x1 0x00000000 0x1 0x80000000 0x3 0x00000000>;
};

(Pardon the formatting; I don't know if the tabs survived Thunderbird.)

[1]:https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/simple-bus.yaml 

[2]:https://github.com/devicetree-org/dt-schema/commit/bab67075926b8bdc4093edbb9888aaa5bd8befd5 


Well, that is the reason I wanted the bus things to be its own patch: I 
think the DT maintainers should review these once and for all, not six 
separate times as the drivers come in.

>> USB3. See:
>>
>> https://lore.kernel.org/all/20250526-b4-k1-dwc3-v3-v4-2-63e4e525e5cb@whut.edu.cn/ 
>>
>> https://lore.kernel.org/all/20250613-net-k1-emac-v1-0-cc6f9e510667@iscas.ac.cn/ 
>>
>>
>> (I haven't put eth{0,1} under dma_bus5 because in 6.16-rc1 there is
>> none, but ideally we should fix this.)
> So, as you are submitting the first node(s) under network_bus: bus@5, you
> should have this added into your patchset, instead of sending out with 
> none.
I hope we can agree on what the bus nodes look like before we do that 
separately.
> The same logic goes to USB too, Ze Huang was in the same offline call, 
> and
> I would prefer that we move in a coordinated way.

I hope so as well, but "we" here should include DT maintainers.

Please consider my suggestions.

Vivian "dramforever" Wang

>> DMA address translation does not depend on PDMA. It would be best if we
>> get all the possible dma-ranges buses handled in one place, instead of
>> everyone moving nodes around.
> No, you should do it in your patchset, when you add the eth0 and eth1 
> nodes,
> they will be the first in, as I said, "network_bus". I don't expect
> any 'moving nodes around'.
>
>> @Ze Huang: This affects your "MBUS" changes as well. Please take a look,
>> thanks.
>>
>>> gpio: gpio@d4019000 {
>>> @@ -792,3 +693,124 @@ pwm19: pwm@d4022c00 {
>>>                };
>>>        };
>>>   };
>>> +
>>> +&dma_bus {
>>>
>>> <snip>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/8] dma: mmp_pdma: Add optional clock support

[Vinod Koul]

On 11-06-25, 20:57, Guodong Xu wrote:
> Add support for retrieving and enabling an optional clock using
> devm_clk_get_optional_enabled() during mmp_pdma_probe().

Its dmaengine, please tag them as such

> 
> Signed-off-by: Guodong Xu <guodong@riscstar.com>
> ---
>  drivers/dma/mmp_pdma.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
> index a95d31103d30..4a6dbf558237 100644
> --- a/drivers/dma/mmp_pdma.c
> +++ b/drivers/dma/mmp_pdma.c
> @@ -15,6 +15,7 @@
>  #include <linux/device.h>
>  #include <linux/platform_data/mmp_dma.h>
>  #include <linux/dmapool.h>
> +#include <linux/clk.h>
>  #include <linux/of_dma.h>
>  #include <linux/of.h>
>  
> @@ -1019,6 +1020,7 @@ static int mmp_pdma_probe(struct platform_device *op)
>  {
>  	struct mmp_pdma_device *pdev;
>  	struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
> +	struct clk *clk;
>  	int i, ret, irq = 0;
>  	int dma_channels = 0, irq_num = 0;
>  	const enum dma_slave_buswidth widths =
> @@ -1037,6 +1039,10 @@ static int mmp_pdma_probe(struct platform_device *op)
>  	if (IS_ERR(pdev->base))
>  		return PTR_ERR(pdev->base);
>  
> +	clk = devm_clk_get_optional_enabled(pdev->dev, NULL);
> +	if (IS_ERR(clk))
> +		return PTR_ERR(clk);
> +
>  	if (pdev->dev->of_node) {
>  		/* Parse new and deprecated dma-channels properties */
>  		if (of_property_read_u32(pdev->dev->of_node, "dma-channels",
> -- 
> 2.43.0

-- 
~Vinod

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 4/8] dma: mmp_pdma: Add SpacemiT PDMA support with 64-bit addressing

[Vinod Koul]

On 11-06-25, 20:57, Guodong Xu wrote:
> Extend the MMP PDMA driver to support SpacemiT PDMA controllers with
> 64-bit physical addressing capabilities, as used in the K1 SoC. This
> change introduces a flexible architecture that maintains compatibility
> with existing 32-bit Marvell platforms while adding 64-bit support.
> 
> Key changes:
> - Add struct mmp_pdma_config to abstract platform-specific behaviors
> - Implement 64-bit address support through:
>   * New high address registers (DDADRH, DSADRH, DTADRH)
>   * DCSR_LPAEEN bit for Long Physical Address Extension mode
>   * Helper functions for 32/64-bit address handling
> - Add "spacemit,pdma-1.0" compatible string with associated config
> - Extend descriptor structure to support 64-bit addresses
> - Refactor address handling code to be platform-agnostic
> - Add proper DMA mask configuration for both 32-bit and 64-bit modes
> 
> The implementation uses a configuration-based approach to keeps all
> platform-specific code isolated in config structures. It maintains clean
> separation between 32-bit and 64-bit code paths, provides consistent
> API for both addressing modes and preserves backward compatibility.

I would ask for this to be split, first to to driver changes for adding
new ops and then adding new soc support. This way the two changes are
independent

-- 
~Vinod

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 2/8] dma: mmp_pdma: Add optional clock support

[Guodong Xu]

On Tue, Jun 17, 2025 at 2:00 PM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 11-06-25, 20:57, Guodong Xu wrote:
> > Add support for retrieving and enabling an optional clock using
> > devm_clk_get_optional_enabled() during mmp_pdma_probe().
>
> Its dmaengine, please tag them as such

Got it. I will do.

Thank you, Vinod.


>
> >
> > Signed-off-by: Guodong Xu <guodong@riscstar.com>
> > ---
> >  drivers/dma/mmp_pdma.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
> > index a95d31103d30..4a6dbf558237 100644
> > --- a/drivers/dma/mmp_pdma.c
> > +++ b/drivers/dma/mmp_pdma.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/device.h>
> >  #include <linux/platform_data/mmp_dma.h>
> >  #include <linux/dmapool.h>
> > +#include <linux/clk.h>
> >  #include <linux/of_dma.h>
> >  #include <linux/of.h>
> >
> > @@ -1019,6 +1020,7 @@ static int mmp_pdma_probe(struct platform_device *op)
> >  {
> >       struct mmp_pdma_device *pdev;
> >       struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
> > +     struct clk *clk;
> >       int i, ret, irq = 0;
> >       int dma_channels = 0, irq_num = 0;
> >       const enum dma_slave_buswidth widths =
> > @@ -1037,6 +1039,10 @@ static int mmp_pdma_probe(struct platform_device *op)
> >       if (IS_ERR(pdev->base))
> >               return PTR_ERR(pdev->base);
> >
> > +     clk = devm_clk_get_optional_enabled(pdev->dev, NULL);
> > +     if (IS_ERR(clk))
> > +             return PTR_ERR(clk);
> > +
> >       if (pdev->dev->of_node) {
> >               /* Parse new and deprecated dma-channels properties */
> >               if (of_property_read_u32(pdev->dev->of_node, "dma-channels",
> > --
> > 2.43.0
>
> --
> ~Vinod

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH 4/8] dma: mmp_pdma: Add SpacemiT PDMA support with 64-bit addressing

[Guodong Xu]

On Tue, Jun 17, 2025 at 2:02 PM Vinod Koul <vkoul@kernel.org> wrote:
>
> On 11-06-25, 20:57, Guodong Xu wrote:
> > Extend the MMP PDMA driver to support SpacemiT PDMA controllers with
> > 64-bit physical addressing capabilities, as used in the K1 SoC. This
> > change introduces a flexible architecture that maintains compatibility
> > with existing 32-bit Marvell platforms while adding 64-bit support.
> >
> > Key changes:
> > - Add struct mmp_pdma_config to abstract platform-specific behaviors
> > - Implement 64-bit address support through:
> >   * New high address registers (DDADRH, DSADRH, DTADRH)
> >   * DCSR_LPAEEN bit for Long Physical Address Extension mode
> >   * Helper functions for 32/64-bit address handling
> > - Add "spacemit,pdma-1.0" compatible string with associated config
> > - Extend descriptor structure to support 64-bit addresses
> > - Refactor address handling code to be platform-agnostic
> > - Add proper DMA mask configuration for both 32-bit and 64-bit modes
> >
> > The implementation uses a configuration-based approach to keeps all
> > platform-specific code isolated in config structures. It maintains clean
> > separation between 32-bit and 64-bit code paths, provides consistent
> > API for both addressing modes and preserves backward compatibility.
>
> I would ask for this to be split, first to to driver changes for adding
> new ops and then adding new soc support. This way the two changes are
> independent

Hi, Vinod

Thank you for the feedback. I agree with that.
I'll send v2 with this split approach.

-
Guodong

>
> --
> ~Vinod

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv