[PATCh v3 0/2] Add DMA ACK signal routing for RZ/V2H family

[PATCh v3 0/2] Add DMA ACK signal routing for RZ/V2H family

[John Madieu]

Some peripherals on RZ/V2H, RZ/V2N, and RZ/G3E SoCs require explicit
DMA ACK signal routing through the ICU for level-based DMA handshaking.

Rather than encoding the ACK signal number as a second DMA specifier
cell, derive it in-driver from the MID/RID request number using
arithmetic formulas based on ICU Table 4.6-28 (3 linear peripheral
groups). It must also be noted that DMA ack register is located in
the ICU block


This series adds:
  - ICU driver extension to register/deregister DMA ACK signals
    (DMA ACK register is located in the ICU block)
  - rz-dmac driver support for ACK signal routing via MID/RID lookup,
    including restore on system resume

Note: patch 2/2 depends upon [1], the Cyclic DMA series from Claudiu.

Changes:

v3:
 - Splitout from v2 [2] into DMA-specific series 
 - No code change

v2:
 - Drop DMA ACK second cell from DT specifier
 - Derive ACK signal number in-driver from MID/RID using arithmetic
   formulas per ICU Table 4.6-28 (3 linear peripheral groups)

[1] https://lore.kernel.org/all/20260320112838.2200198-1-claudiu.beznea.uj@bp.renesas.com/
[2] https://lore.kernel.org/all/20260402090524.9137-1-john.madieu.xa@bp.renesas.com/

John Madieu (2):
  irqchip/renesas-rzv2h: Add DMA ACK signal routing support
  dma: sh: rz-dmac: Add DMA ACK signal routing support

 drivers/dma/sh/rz-dmac.c                  | 72 +++++++++++++++++++++++
 drivers/irqchip/irq-renesas-rzv2h.c       | 40 +++++++++++++
 include/linux/irqchip/irq-renesas-rzv2h.h |  5 ++
 3 files changed, 117 insertions(+)

-- 
2.25.1

[PATCh v3 1/2] irqchip/renesas-rzv2h: Add DMA ACK signal routing support

[John Madieu]

Some peripherals on RZ/G3E SoCs (SSIU, SPDIF, SCU/SRC, DVC) require
explicit ACK signal routing through the ICU via the ICU_DMACKSELk
registers for level-based DMA handshaking.

Add rzv2h_icu_register_dma_ack() to configure ICU_DMACKSELk, routing
a DMAC channel's ACK signal to the specified peripheral.

Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---

Changes:

v3: No changes
v2: No changes

 drivers/irqchip/irq-renesas-rzv2h.c       | 40 +++++++++++++++++++++++
 include/linux/irqchip/irq-renesas-rzv2h.h |  5 +++
 2 files changed, 45 insertions(+)

diff --git a/drivers/irqchip/irq-renesas-rzv2h.c b/drivers/irqchip/irq-renesas-rzv2h.c
index 31f191641ff8..4ebcb91c0b6c 100644
--- a/drivers/irqchip/irq-renesas-rzv2h.c
+++ b/drivers/irqchip/irq-renesas-rzv2h.c
@@ -151,6 +151,12 @@ struct rzv2h_hw_info {
 #define ICU_DMAC_PREP_DMAREQ(sel, up)		(FIELD_PREP(ICU_DMAC_DkRQ_SEL_MASK, (sel)) \
 						 << ICU_DMAC_DMAREQ_SHIFT(up))
 
+/* DMAC ACK routing - 4 x 7-bit fields per 32-bit register, 8-bit spacing */
+#define ICU_DMAC_DACK_SEL_MASK			GENMASK(6, 0)
+#define ICU_DMAC_DACK_SHIFT(n)			((n) * 8)
+#define ICU_DMAC_DACK_FIELD_MASK(n)		(ICU_DMAC_DACK_SEL_MASK << ICU_DMAC_DACK_SHIFT(n))
+#define ICU_DMAC_PREP_DACK(val, n)		(((val) & ICU_DMAC_DACK_SEL_MASK) << ICU_DMAC_DACK_SHIFT(n))
+
 /**
  * struct rzv2h_icu_priv - Interrupt Control Unit controller private data structure.
  * @base:	Controller's base address
@@ -188,6 +194,40 @@ void rzv2h_icu_register_dma_req(struct platform_device *icu_dev, u8 dmac_index,
 }
 EXPORT_SYMBOL_GPL(rzv2h_icu_register_dma_req);
 
+/**
+ * rzv2h_icu_register_dma_ack - Configure DMA ACK signal routing
+ * @icu_dev:      ICU platform device
+ * @dmac_index:   DMAC instance index (0-4)
+ * @dmac_channel: DMAC channel number (0-15), or RZV2H_ICU_DMAC_ACK_NO_DEFAULT
+ *                to disconnect routing for a given ack_no
+ * @ack_no:       Peripheral ACK number (0-88) per RZ/G3E manual Table 4.6-28,
+ *                used as index into ICU_DMACKSELk
+ *
+ * Routes the ACK signal of the peripheral identified by @ack_no to DMAC
+ * channel @dmac_channel of instance @dmac_index. When @dmac_channel is
+ * RZV2H_ICU_DMAC_ACK_NO_DEFAULT the field is reset, disconnecting any
+ * previously configured routing for that peripheral.
+ */
+void rzv2h_icu_register_dma_ack(struct platform_device *icu_dev, u8 dmac_index,
+				u8 dmac_channel, u16 ack_no)
+{
+	struct rzv2h_icu_priv *priv = platform_get_drvdata(icu_dev);
+	u8 reg_idx = ack_no / 4;
+	u8 field_idx = ack_no & 0x3;
+	u8 dmac_ack_src = (dmac_channel == RZV2H_ICU_DMAC_ACK_NO_DEFAULT) ?
+			  RZV2H_ICU_DMAC_ACK_NO_DEFAULT :
+			  (dmac_index * 16 + dmac_channel);
+	u32 val;
+
+	guard(raw_spinlock_irqsave)(&priv->lock);
+
+	val = readl(priv->base + ICU_DMACKSELk(reg_idx));
+	val &= ~ICU_DMAC_DACK_FIELD_MASK(field_idx);
+	val |= ICU_DMAC_PREP_DACK(dmac_ack_src, field_idx);
+	writel(val, priv->base + ICU_DMACKSELk(reg_idx));
+}
+EXPORT_SYMBOL_GPL(rzv2h_icu_register_dma_ack);
+
 static inline struct rzv2h_icu_priv *irq_data_to_priv(struct irq_data *data)
 {
 	return data->domain->host_data;
diff --git a/include/linux/irqchip/irq-renesas-rzv2h.h b/include/linux/irqchip/irq-renesas-rzv2h.h
index 618a60d2eac0..4ffa898eaaf2 100644
--- a/include/linux/irqchip/irq-renesas-rzv2h.h
+++ b/include/linux/irqchip/irq-renesas-rzv2h.h
@@ -11,13 +11,18 @@
 #include <linux/platform_device.h>
 
 #define RZV2H_ICU_DMAC_REQ_NO_DEFAULT		0x3ff
+#define RZV2H_ICU_DMAC_ACK_NO_DEFAULT		0x7f
 
 #ifdef CONFIG_RENESAS_RZV2H_ICU
 void rzv2h_icu_register_dma_req(struct platform_device *icu_dev, u8 dmac_index, u8 dmac_channel,
 				u16 req_no);
+void rzv2h_icu_register_dma_ack(struct platform_device *icu_dev, u8 dmac_index,
+				u8 dmac_channel, u16 ack_no);
 #else
 static inline void rzv2h_icu_register_dma_req(struct platform_device *icu_dev, u8 dmac_index,
 					      u8 dmac_channel, u16 req_no) { }
+static inline void rzv2h_icu_register_dma_ack(struct platform_device *icu_dev, u8 dmac_index,
+					      u8 dmac_channel, u16 ack_no) { }
 #endif
 
 #endif /* __LINUX_IRQ_RENESAS_RZV2H */
-- 
2.25.1

Re: [PATCh v3 1/2] irqchip/renesas-rzv2h: Add DMA ACK signal routing support

[Thomas Gleixner]

On Thu, Apr 02 2026 at 18:22, John Madieu wrote:
> Some peripherals on RZ/G3E SoCs (SSIU, SPDIF, SCU/SRC, DVC) require
> explicit ACK signal routing through the ICU via the ICU_DMACKSELk
> registers for level-based DMA handshaking.
>
> Add rzv2h_icu_register_dma_ack() to configure ICU_DMACKSELk, routing
> a DMAC channel's ACK signal to the specified peripheral.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>

Assuming this goes through the DMA tree:

Acked-by: Thomas Gleixner <tglx@kernel.org>

[PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing support

[John Madieu]

Some peripherals on RZ/G3E SoCs (SSIU, SPDIF, SCU/SRC, DVC, PFC)
require explicit ACK signal routing through the ICU for level-based DMA
handshaking.

Rather than extending the DT binding with an optional second #dma-cells
(which would require all DMA consumers to supply two cells even when ACK
routing is not needed), derive the ACK signal number directly from the
MID/RID request number using the linear mapping defined in RZ/G3E hardware
manual Table 4.6-28:

  PFC external DMA pins (DREQ0..DREQ4):
    req_no 0x000-0x004 -> ACK No. 84-88

  SSIU BUSIFs (ssip00..ssip93):
    req_no 0x161-0x198 -> ACK No. 28-83

  SPDIF (CH0..CH2) + SCU SRC (sr0..sr9) + DVC (cmd0..cmd1):
    req_no 0x199-0x1b4 -> ACK No. 0-27

ACK routing is programmed when a channel is prepared for transfer and
cleared when the channel is released or the transfer times out, following
the same pattern as MID/RID request routing.

Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---

Changes:

v3: No changes

v2:
 - Drop DMA ACK second cell from DT specifier
 - Derive ACK signal number in-driver from MID/RID using arithmetic formulas
   per ICU Table 4.6-28 (3 linear peripheral groups)

 drivers/dma/sh/rz-dmac.c | 72 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
index 95a89c9d2925..bde3da96b37e 100644
--- a/drivers/dma/sh/rz-dmac.c
+++ b/drivers/dma/sh/rz-dmac.c
@@ -97,6 +97,7 @@ struct rz_dmac_chan {
 	u32 chcfg;
 	u32 chctrl;
 	int mid_rid;
+	int dmac_ack;
 
 	struct {
 		u32 nxla;
@@ -124,6 +125,9 @@ struct rz_dmac_icu {
 struct rz_dmac_info {
 	void (*icu_register_dma_req)(struct platform_device *icu_dev,
 				     u8 dmac_index, u8 dmac_channel, u16 req_no);
+	void (*icu_register_dma_ack)(struct platform_device *icu_dev,
+				     u8 dmac_index, u8 dmac_channel, u16 ack_no);
+	u16 default_dma_ack_no;
 	u16 default_dma_req_no;
 };
 
@@ -362,6 +366,60 @@ static void rz_dmac_set_dma_req_no(struct rz_dmac *dmac, unsigned int index,
 		rz_dmac_set_dmars_register(dmac, index, req_no);
 }
 
+/*
+ * Map MID/RID request number (bits[0:9] of DMA specifier) to the ICU
+ * DMA ACK signal number, per RZ/G3E hardware manual Table 4.6-28.
+ *
+ * Three peripheral groups cover all ACK-capable peripherals:
+ *
+ *   PFC external DMA pins (DREQ0..DREQ4):
+ *     req_no 0x000-0x004 -> ACK No. 84-88  (ack = req_no + 84)
+ *
+ *   SSIU BUSIFs (ssip00..ssip93):
+ *     req_no 0x161-0x198 -> ACK No. 28-83  (ack = req_no - 0x145)
+ *
+ *   SPDIF (CH0..CH2) + SCU SRC (sr0..sr9) + DVC (cmd0..cmd1):
+ *     req_no 0x199-0x1b4 -> ACK No. 0-27   (ack = req_no - 0x199)
+ */
+static int rz_dmac_get_ack_no(const struct rz_dmac_info *info, u16 req_no)
+{
+	if (!info->icu_register_dma_ack)
+		return -EINVAL;
+
+	switch (req_no) {
+	case 0x000 ... 0x004:
+		/* PFC external DMA pins: ACK No. 84-88 */
+		return req_no + 84;
+	case 0x161 ... 0x198:
+		/* SSIU BUSIFs: ACK No. 28-83 */
+		return req_no - 0x145;
+	case 0x199 ... 0x1b4:
+		/* SPDIF + SCU SRC + DVC: ACK No. 0-27 */
+		return req_no - 0x199;
+	default:
+		return -EINVAL;
+	}
+}
+
+static void rz_dmac_set_dma_ack_no(struct rz_dmac *dmac, unsigned int index,
+				   int ack_no)
+{
+	if (ack_no < 0 || !dmac->info->icu_register_dma_ack)
+		return;
+
+	dmac->info->icu_register_dma_ack(dmac->icu.pdev, dmac->icu.dmac_index,
+					 index, ack_no);
+}
+
+static void rz_dmac_reset_dma_ack_no(struct rz_dmac *dmac, int ack_no)
+{
+	if (ack_no < 0 || !dmac->info->icu_register_dma_ack)
+		return;
+
+	dmac->info->icu_register_dma_ack(dmac->icu.pdev, dmac->icu.dmac_index,
+					 dmac->info->default_dma_ack_no, ack_no);
+}
+
 static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
 {
 	struct dma_chan *chan = &channel->vc.chan;
@@ -431,6 +489,7 @@ static void rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan *channel)
 	channel->lmdesc.tail = lmdesc;
 
 	rz_dmac_set_dma_req_no(dmac, channel->index, channel->mid_rid);
+	rz_dmac_set_dma_ack_no(dmac, channel->index, channel->dmac_ack);
 }
 
 static void rz_dmac_prepare_descs_for_cyclic(struct rz_dmac_chan *channel)
@@ -485,6 +544,7 @@ static void rz_dmac_prepare_descs_for_cyclic(struct rz_dmac_chan *channel)
 	channel->lmdesc.tail = lmdesc;
 
 	rz_dmac_set_dma_req_no(dmac, channel->index, channel->mid_rid);
+	rz_dmac_set_dma_ack_no(dmac, channel->index, channel->dmac_ack);
 }
 
 static int rz_dmac_xfer_desc(struct rz_dmac_chan *chan)
@@ -567,6 +627,9 @@ static void rz_dmac_free_chan_resources(struct dma_chan *chan)
 		channel->mid_rid = -EINVAL;
 	}
 
+	rz_dmac_reset_dma_ack_no(dmac, channel->dmac_ack);
+	channel->dmac_ack = -EINVAL;
+
 	spin_unlock_irqrestore(&channel->vc.lock, flags);
 
 	list_for_each_entry_safe(desc, _desc, &channel->ld_free, node) {
@@ -814,6 +877,7 @@ static void rz_dmac_device_synchronize(struct dma_chan *chan)
 		dev_warn(dmac->dev, "DMA Timeout");
 
 	rz_dmac_set_dma_req_no(dmac, channel->index, dmac->info->default_dma_req_no);
+	rz_dmac_reset_dma_ack_no(dmac, channel->dmac_ack);
 }
 
 static struct rz_lmdesc *
@@ -1164,6 +1228,8 @@ static bool rz_dmac_chan_filter(struct dma_chan *chan, void *arg)
 	channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
 			 CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
 
+	channel->dmac_ack = rz_dmac_get_ack_no(dmac->info, channel->mid_rid);
+
 	return !test_and_set_bit(channel->mid_rid, dmac->modules);
 }
 
@@ -1200,6 +1266,7 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
 
 	channel->index = index;
 	channel->mid_rid = -EINVAL;
+	channel->dmac_ack = -EINVAL;
 
 	/* Request the channel interrupt. */
 	scnprintf(pdev_irqname, sizeof(pdev_irqname), "ch%u", index);
@@ -1569,6 +1636,9 @@ static int rz_dmac_resume(struct device *dev)
 
 		guard(spinlock_irqsave)(&channel->vc.lock);
 
+		rz_dmac_set_dma_req_no(dmac, channel->index, channel->mid_rid);
+		rz_dmac_set_dma_ack_no(dmac, channel->index, channel->dmac_ack);
+
 		if (!(channel->status & BIT(RZ_DMAC_CHAN_STATUS_CYCLIC))) {
 			rz_dmac_ch_writel(&dmac->channels[i], CHCTRL_DEFAULT, CHCTRL, 1);
 			continue;
@@ -1601,6 +1671,8 @@ static const struct dev_pm_ops rz_dmac_pm_ops = {
 
 static const struct rz_dmac_info rz_dmac_v2h_info = {
 	.icu_register_dma_req = rzv2h_icu_register_dma_req,
+	.icu_register_dma_ack = rzv2h_icu_register_dma_ack,
+	.default_dma_ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT,
 	.default_dma_req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
 };
 
-- 
2.25.1

Re: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing support

[Frank Li]

On Thu, Apr 02, 2026 at 06:22:12PM +0200, John Madieu wrote:
> Some peripherals on RZ/G3E SoCs (SSIU, SPDIF, SCU/SRC, DVC, PFC)
> require explicit ACK signal routing through the ICU for level-based DMA
> handshaking.
>
> Rather than extending the DT binding with an optional second #dma-cells
> (which would require all DMA consumers to supply two cells even when ACK
> routing is not needed), derive the ACK signal number directly from the
> MID/RID request number using the linear mapping defined in RZ/G3E hardware
> manual Table 4.6-28:
>
>   PFC external DMA pins (DREQ0..DREQ4):
>     req_no 0x000-0x004 -> ACK No. 84-88
>
>   SSIU BUSIFs (ssip00..ssip93):
>     req_no 0x161-0x198 -> ACK No. 28-83
>
>   SPDIF (CH0..CH2) + SCU SRC (sr0..sr9) + DVC (cmd0..cmd1):
>     req_no 0x199-0x1b4 -> ACK No. 0-27
>
> ACK routing is programmed when a channel is prepared for transfer and
> cleared when the channel is released or the transfer times out, following
> the same pattern as MID/RID request routing.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v3: No changes
>
> v2:
>  - Drop DMA ACK second cell from DT specifier
>  - Derive ACK signal number in-driver from MID/RID using arithmetic formulas
>    per ICU Table 4.6-28 (3 linear peripheral groups)
>
>  drivers/dma/sh/rz-dmac.c | 72 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
>
>  static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
>  {
>  	struct dma_chan *chan = &channel->vc.chan;
> @@ -431,6 +489,7 @@ static void rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan *channel)
>  	channel->lmdesc.tail = lmdesc;
>
>  	rz_dmac_set_dma_req_no(dmac, channel->index, channel->mid_rid);
> +	rz_dmac_set_dma_ack_no(dmac, channel->index, channel->dmac_ack);

I am not familar with your hardware, why ACK folllow req immediately?
suppose ACK happen after transfer done.

If ACK need after req, why not add ack handle in rz_dmac_set_dma_req_no()
directly.

Frank

> --
> 2.25.1
>

RE: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing support

[John Madieu]

Hi Frank,

thanks for your review.

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Donnerstag, 7. Mai 2026 20:49
> To: John Madieu <john.madieu.xa@bp.renesas.com>
> Subject: Re: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing
> support
> 
> 
> On Thu, Apr 02, 2026 at 06:22:12PM +0200, John Madieu wrote:
> > Some peripherals on RZ/G3E SoCs (SSIU, SPDIF, SCU/SRC, DVC, PFC)
> > require explicit ACK signal routing through the ICU for level-based
> > DMA handshaking.
> >
> > Rather than extending the DT binding with an optional second
> > #dma-cells (which would require all DMA consumers to supply two cells
> > even when ACK routing is not needed), derive the ACK signal number
> > directly from the MID/RID request number using the linear mapping
> > defined in RZ/G3E hardware manual Table 4.6-28:
> >
> >   PFC external DMA pins (DREQ0..DREQ4):
> >     req_no 0x000-0x004 -> ACK No. 84-88
> >
> >   SSIU BUSIFs (ssip00..ssip93):
> >     req_no 0x161-0x198 -> ACK No. 28-83
> >
> >   SPDIF (CH0..CH2) + SCU SRC (sr0..sr9) + DVC (cmd0..cmd1):
> >     req_no 0x199-0x1b4 -> ACK No. 0-27
> >
> > ACK routing is programmed when a channel is prepared for transfer and
> > cleared when the channel is released or the transfer times out,
> > following the same pattern as MID/RID request routing.
> >
> > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > ---
> >
> > Changes:
> >
> > v3: No changes
> >
> > v2:
> >  - Drop DMA ACK second cell from DT specifier
> >  - Derive ACK signal number in-driver from MID/RID using arithmetic
> formulas
> >    per ICU Table 4.6-28 (3 linear peripheral groups)
> >
> >  drivers/dma/sh/rz-dmac.c | 72
> > ++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 72 insertions(+)
> >
> >  static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan
> > *channel)  {
> >       struct dma_chan *chan = &channel->vc.chan; @@ -431,6 +489,7 @@
> > static void rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan
> *channel)
> >       channel->lmdesc.tail = lmdesc;
> >
> >       rz_dmac_set_dma_req_no(dmac, channel->index, channel->mid_rid);
> > +     rz_dmac_set_dma_ack_no(dmac, channel->index, channel->dmac_ack);
> 
> I am not familar with your hardware, why ACK folllow req immediately?
> suppose ACK happen after transfer done.

rz_dmac_set_dma_ack_no() does not fire an ACK pulse, it programs a static
routing mux in the ICU (ICU_DMACKSELk) that selects which DMAC channel is
the source of the ACK line for a given peripheral. It is the symmetric
counterpart of ICU_DMAREQSELk programmed by rz_dmac_set_dma_req_no().

Both registers must be configured before any transfer can happen on
the channel: the REQ mux routes the peripheral's request line into
the DMAC, the ACK mux routes the DMAC's acknowledge line back to the
peripheral. Once the routing is in place, the level-based REQ/ACK
handshake itself runs entirely in hardware on every burst, with no
driver involvement per transfer.

Maybe should I reword the commit message to make this distinction
explicit (routing config vs per-transfer signal).

> 
> If ACK need after req, why not add ack handle in rz_dmac_set_dma_req_no()
> directly.

I would prefer to keep rz_dmac_set_dma_ack_no() as its own helper, to
mirror the existing rz_dmac_set_dma_req_no() path. The surrounding
infrastructure is already structured around per-routing helpers, and
the ACK additions in this patch deliberately follow that pattern:
.icu_register_dma_ack/.default_dma_ack_no.

The two ICU registers also index their fields differently. ICU_DMAkSELy
fields are indexed by DMAC channel and carry the peripheral req_no as
the value, while ICU_DMACKSELk fields are indexed by the peripheral
ack_no and carry the DMAC source channel as the value. Folding ACK
into rz_dmac_set_dma_req_no() would mix those two layouts in one helper
for no behavioral gain.

Regards,
John


> 
> Frank
> 
> > --
> > 2.25.1
> >

Re: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing support

[Frank Li]

On Mon, May 11, 2026 at 05:04:46PM +0000, John Madieu wrote:
> Hi Frank,
>
> thanks for your review.
>
> > -----Original Message-----
> > From: Frank Li <Frank.li@nxp.com>
> > Sent: Donnerstag, 7. Mai 2026 20:49
> > To: John Madieu <john.madieu.xa@bp.renesas.com>
> > Subject: Re: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing
> > support
> >
> >
> > On Thu, Apr 02, 2026 at 06:22:12PM +0200, John Madieu wrote:
> > > Some peripherals on RZ/G3E SoCs (SSIU, SPDIF, SCU/SRC, DVC, PFC)
> > > require explicit ACK signal routing through the ICU for level-based
> > > DMA handshaking.
> > >
> > > Rather than extending the DT binding with an optional second
> > > #dma-cells (which would require all DMA consumers to supply two cells
> > > even when ACK routing is not needed), derive the ACK signal number
> > > directly from the MID/RID request number using the linear mapping
> > > defined in RZ/G3E hardware manual Table 4.6-28:
> > >
> > >   PFC external DMA pins (DREQ0..DREQ4):
> > >     req_no 0x000-0x004 -> ACK No. 84-88
> > >
> > >   SSIU BUSIFs (ssip00..ssip93):
> > >     req_no 0x161-0x198 -> ACK No. 28-83
> > >
> > >   SPDIF (CH0..CH2) + SCU SRC (sr0..sr9) + DVC (cmd0..cmd1):
> > >     req_no 0x199-0x1b4 -> ACK No. 0-27
> > >
> > > ACK routing is programmed when a channel is prepared for transfer and
> > > cleared when the channel is released or the transfer times out,
> > > following the same pattern as MID/RID request routing.
> > >
> > > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > > ---
> > >
> > > Changes:
> > >
> > > v3: No changes
> > >
> > > v2:
> > >  - Drop DMA ACK second cell from DT specifier
> > >  - Derive ACK signal number in-driver from MID/RID using arithmetic
> > formulas
> > >    per ICU Table 4.6-28 (3 linear peripheral groups)
> > >
> > >  drivers/dma/sh/rz-dmac.c | 72
> > > ++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 72 insertions(+)
> > >
> > >  static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan
> > > *channel)  {
> > >       struct dma_chan *chan = &channel->vc.chan; @@ -431,6 +489,7 @@
> > > static void rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan
> > *channel)
> > >       channel->lmdesc.tail = lmdesc;
> > >
> > >       rz_dmac_set_dma_req_no(dmac, channel->index, channel->mid_rid);
> > > +     rz_dmac_set_dma_ack_no(dmac, channel->index, channel->dmac_ack);
> >
> > I am not familar with your hardware, why ACK folllow req immediately?
> > suppose ACK happen after transfer done.
>
> rz_dmac_set_dma_ack_no() does not fire an ACK pulse, it programs a static
> routing mux in the ICU (ICU_DMACKSELk) that selects which DMAC channel is
> the source of the ACK line for a given peripheral. It is the symmetric
> counterpart of ICU_DMAREQSELk programmed by rz_dmac_set_dma_req_no().
>
> Both registers must be configured before any transfer can happen on
> the channel: the REQ mux routes the peripheral's request line into
> the DMAC, the ACK mux routes the DMAC's acknowledge line back to the
> peripheral. Once the routing is in place, the level-based REQ/ACK
> handshake itself runs entirely in hardware on every burst, with no
> driver involvement per transfer.

Supposed these register should belong to dma-engine, but it was located
into irq, you open a private API to irq chip drivers. Ideally these
register ownership should move to here.

these routing mux should be in allocate channel callback, not in
rz_dmac_prepare_descs_for_slave_sg() or in xlate function.

Frank

>
> Maybe should I reword the commit message to make this distinction
> explicit (routing config vs per-transfer signal).
>
> >
> > If ACK need after req, why not add ack handle in rz_dmac_set_dma_req_no()
> > directly.
>
> I would prefer to keep rz_dmac_set_dma_ack_no() as its own helper, to
> mirror the existing rz_dmac_set_dma_req_no() path. The surrounding
> infrastructure is already structured around per-routing helpers, and
> the ACK additions in this patch deliberately follow that pattern:
> .icu_register_dma_ack/.default_dma_ack_no.
>
> The two ICU registers also index their fields differently. ICU_DMAkSELy
> fields are indexed by DMAC channel and carry the peripheral req_no as
> the value, while ICU_DMACKSELk fields are indexed by the peripheral
> ack_no and carry the DMAC source channel as the value. Folding ACK
> into rz_dmac_set_dma_req_no() would mix those two layouts in one helper
> for no behavioral gain.
>
> Regards,
> John
>
>
> >
> > Frank
> >
> > > --
> > > 2.25.1
> > >

RE: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing support

[John Madieu]

Hi Frank,

> -----Original Message-----
> From: Frank Li <Frank.li@nxp.com>
> Sent: Montag, 11. Mai 2026 22:21
> To: John Madieu <john.madieu.xa@bp.renesas.com>
> Subject: Re: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal routing
> support
> 
> [You don't often get email from frank.li@nxp.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Mon, May 11, 2026 at 05:04:46PM +0000, John Madieu wrote:
> > Hi Frank,
> >
> > thanks for your review.
> >
> > > -----Original Message-----
> > > From: Frank Li <Frank.li@nxp.com>
> > > Sent: Donnerstag, 7. Mai 2026 20:49
> > > To: John Madieu <john.madieu.xa@bp.renesas.com>
> > > Subject: Re: [PATCh v3 2/2] dma: sh: rz-dmac: Add DMA ACK signal
> > > routing support
> > >
> > >
> > > On Thu, Apr 02, 2026 at 06:22:12PM +0200, John Madieu wrote:
> > > > Some peripherals on RZ/G3E SoCs (SSIU, SPDIF, SCU/SRC, DVC, PFC)
> > > > require explicit ACK signal routing through the ICU for
> > > > level-based DMA handshaking.
> > > >
> > > > Rather than extending the DT binding with an optional second
> > > > #dma-cells (which would require all DMA consumers to supply two
> > > > cells even when ACK routing is not needed), derive the ACK signal
> > > > number directly from the MID/RID request number using the linear
> > > > mapping defined in RZ/G3E hardware manual Table 4.6-28:
> > > >
> > > >   PFC external DMA pins (DREQ0..DREQ4):
> > > >     req_no 0x000-0x004 -> ACK No. 84-88
> > > >
> > > >   SSIU BUSIFs (ssip00..ssip93):
> > > >     req_no 0x161-0x198 -> ACK No. 28-83
> > > >
> > > >   SPDIF (CH0..CH2) + SCU SRC (sr0..sr9) + DVC (cmd0..cmd1):
> > > >     req_no 0x199-0x1b4 -> ACK No. 0-27
> > > >
> > > > ACK routing is programmed when a channel is prepared for transfer
> > > > and cleared when the channel is released or the transfer times
> > > > out, following the same pattern as MID/RID request routing.
> > > >
> > > > Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> > > > ---
> > > >
> > > > Changes:
> > > >
> > > > v3: No changes
> > > >
> > > > v2:
> > > >  - Drop DMA ACK second cell from DT specifier
> > > >  - Derive ACK signal number in-driver from MID/RID using
> > > > arithmetic
> > > formulas
> > > >    per ICU Table 4.6-28 (3 linear peripheral groups)
> > > >
> > > >  drivers/dma/sh/rz-dmac.c | 72
> > > > ++++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 72 insertions(+)
> > > >
> > > >  static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan
> > > > *channel)  {
> > > >       struct dma_chan *chan = &channel->vc.chan; @@ -431,6 +489,7
> > > > @@ static void rz_dmac_prepare_descs_for_slave_sg(struct
> > > > rz_dmac_chan
> > > *channel)
> > > >       channel->lmdesc.tail = lmdesc;
> > > >
> > > >       rz_dmac_set_dma_req_no(dmac, channel->index,
> > > > channel->mid_rid);
> > > > +     rz_dmac_set_dma_ack_no(dmac, channel->index,
> > > > + channel->dmac_ack);
> > >
> > > I am not familar with your hardware, why ACK folllow req immediately?
> > > suppose ACK happen after transfer done.
> >
> > rz_dmac_set_dma_ack_no() does not fire an ACK pulse, it programs a
> > static routing mux in the ICU (ICU_DMACKSELk) that selects which DMAC
> > channel is the source of the ACK line for a given peripheral. It is
> > the symmetric counterpart of ICU_DMAREQSELk programmed by
> rz_dmac_set_dma_req_no().
> >
> > Both registers must be configured before any transfer can happen on
> > the channel: the REQ mux routes the peripheral's request line into the
> > DMAC, the ACK mux routes the DMAC's acknowledge line back to the
> > peripheral. Once the routing is in place, the level-based REQ/ACK
> > handshake itself runs entirely in hardware on every burst, with no
> > driver involvement per transfer.
> 
> Supposed these register should belong to dma-engine, but it was located
> into irq, you open a private API to irq chip drivers. Ideally these
> register ownership should move to here.

These registers belong to the ICU's MMIO region, along with the
IRQ/TINT/NMI/ECC machinery owned by the irqchip driver. The established
pattern is for the irqchip to keep ownership of the whole region and
export a small entry point for the DMA engine to call into. That pattern
was introduced by Fabrizio when the irqchip driver landed and adopted
by Cosmin when chip-specific REQ routing was added to rz-dmac [1].

> 
> these routing mux should be in allocate channel callback, not in
> rz_dmac_prepare_descs_for_slave_sg() or in xlate function.

The prepare-path placement is also pre-existing. The new
rz_dmac_setset_dma_ack_no() call in this patch sit at the same
sites, by design, so the REQ and ACK routes share one lifecycle.

Moving the routing setup to device_alloc_chan_resources() is a
reasonable direction, but it would only make sense if REQ and ACK
move together, and it would be a refactor of existing and recently
landed [1] REQ code in the same change. Should we go this way ?

[1] https://lore.kernel.org/all/20260105114445.878262-1-cosmin-gabriel.tanislav.xa@renesas.com/

Regards,
John