[PATCH v4 0/7] Add DMAC support to the RZ/V2H(P)

[PATCH v4 0/7] Add DMAC support to the RZ/V2H(P)

[Fabrizio Castro]

Dear All,

This series adds DMAC support to the Renesas RZ/V2H(P).

Cheers,
Fab

v3->v4:
* Fixed an issue with mid_rid/req_no/ack_no initialization
v2->v3:
* Replaced rzv2h_icu_register_dma_req_ack with
  rzv2h_icu_register_dma_req_ack() in ICU patch changelog
* Added dummy for rzv2h_icu_register_dma_req_ack()
* Reworked DMAC driver as per Geert's suggestions.
v1->v2:
* Improved macros in ICU driver
* Shared new macros between ICU driver and DMAC driver
* Improved dt-bindings

Fabrizio Castro (7):
  clk: renesas: r9a09g057: Add entries for the DMACs
  dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H
  dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
  irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack()
  dmaengine: sh: rz-dmac: Allow for multiple DMACs
  dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
  arm64: dts: renesas: r9a09g057: Add DMAC nodes

 .../bindings/dma/renesas,rz-dmac.yaml         | 113 ++++++++++--
 arch/arm64/boot/dts/renesas/r9a09g057.dtsi    | 165 ++++++++++++++++++
 drivers/clk/renesas/r9a09g057-cpg.c           |  24 +++
 drivers/clk/renesas/rzv2h-cpg.h               |   2 +
 drivers/dma/sh/rz-dmac.c                      | 165 ++++++++++++++++--
 drivers/irqchip/irq-renesas-rzv2h.c           |  56 ++++++
 include/linux/irqchip/irq-renesas-rzv2h.h     |  26 +++
 7 files changed, 517 insertions(+), 34 deletions(-)
 create mode 100644 include/linux/irqchip/irq-renesas-rzv2h.h

-- 
2.34.1

[PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H

[Fabrizio Castro]

Make sure we don't allow for the clocks, clock-names, resets,
reset-names. and power-domains properties for the Renesas
RZ/A1H SoC because its DMAC doesn't have clocks, resets,
and power domains.

Fixes: 209efec19c4c ("dt-bindings: dma: rz-dmac: Document RZ/A1H SoC")
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* No change.
---
 .../devicetree/bindings/dma/renesas,rz-dmac.yaml          | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
index b356251de5a8..82de3b927479 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
@@ -112,6 +112,14 @@ allOf:
         - resets
         - reset-names
 
+    else:
+      properties:
+        clocks: false
+        clock-names: false
+        power-domains: false
+        resets: false
+        reset-names: false
+
 additionalProperties: false
 
 examples:
-- 
2.34.1

[PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Fabrizio Castro]

Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
Renesas RZ/G2L family of SoCs, but there are some differences:
* It only uses one register area
* It only uses one clock
* It only uses one reset
* Instead of using MID/IRD it uses REQ NO/ACK NO
* It is connected to the Interrupt Control Unit (ICU)

Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* Removed RZ/V2H DMAC example.
* Improved the readability of the `if` statement.
---
 .../bindings/dma/renesas,rz-dmac.yaml         | 107 +++++++++++++++---
 1 file changed, 89 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
index 82de3b927479..4b89d199c022 100644
--- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
+++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
@@ -11,19 +11,23 @@ maintainers:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - renesas,r7s72100-dmac # RZ/A1H
-          - renesas,r9a07g043-dmac # RZ/G2UL and RZ/Five
-          - renesas,r9a07g044-dmac # RZ/G2{L,LC}
-          - renesas,r9a07g054-dmac # RZ/V2L
-          - renesas,r9a08g045-dmac # RZ/G3S
-      - const: renesas,rz-dmac
+    oneOf:
+      - items:
+          - enum:
+              - renesas,r7s72100-dmac # RZ/A1H
+              - renesas,r9a07g043-dmac # RZ/G2UL and RZ/Five
+              - renesas,r9a07g044-dmac # RZ/G2{L,LC}
+              - renesas,r9a07g054-dmac # RZ/V2L
+              - renesas,r9a08g045-dmac # RZ/G3S
+          - const: renesas,rz-dmac
+
+      - const: renesas,r9a09g057-dmac # RZ/V2H(P)
 
   reg:
     items:
       - description: Control and channel register block
       - description: DMA extended resource selector block
+    minItems: 1
 
   interrupts:
     maxItems: 17
@@ -52,6 +56,7 @@ properties:
     items:
       - description: DMA main clock
       - description: DMA register access clock
+    minItems: 1
 
   clock-names:
     items:
@@ -61,14 +66,22 @@ properties:
   '#dma-cells':
     const: 1
     description:
-      The cell specifies the encoded MID/RID values of the DMAC port
-      connected to the DMA client and the slave channel configuration
-      parameters.
+      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
+      specifies the encoded MID/RID values of the DMAC port connected to the
+      DMA client and the slave channel configuration parameters.
       bits[0:9] - Specifies MID/RID value
       bit[10] - Specifies DMA request high enable (HIEN)
       bit[11] - Specifies DMA request detection type (LVL)
       bits[12:14] - Specifies DMAACK output mode (AM)
       bit[15] - Specifies Transfer Mode (TM)
+      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
+      slave channel configuration parameters.
+      bits[0:9] - Specifies the REQ NO
+      bits[10:16] - Specifies the ACK NO
+      bit[17] - Specifies DMA request high enable (HIEN)
+      bit[18] - Specifies DMA request detection type (LVL)
+      bits[19:21] - Specifies DMAACK output mode (AM)
+      bit[22] - Specifies Transfer Mode (TM)
 
   dma-channels:
     const: 16
@@ -80,12 +93,29 @@ properties:
     items:
       - description: Reset for DMA ARESETN reset terminal
       - description: Reset for DMA RST_ASYNC reset terminal
+    minItems: 1
 
   reset-names:
     items:
       - const: arst
       - const: rst_async
 
+  renesas,icu:
+    description:
+      On the RZ/V2H(P) SoC configures the ICU to which the DMAC is connected to.
+      It must contain the phandle to the ICU, and the index of the DMAC as seen
+      from the ICU (e.g. parameter k from register ICU_DMkSELy).
+    $ref: /schemas/types.yaml#/definitions/phandle-array
+    items:
+      - items:
+          - description: phandle to the ICU node.
+          - description: The DMAC index.
+              4 for DMAC0
+              0 for DMAC1
+              1 for DMAC2
+              2 for DMAC3
+              3 for DMAC4
+
 required:
   - compatible
   - reg
@@ -98,13 +128,25 @@ allOf:
   - $ref: dma-controller.yaml#
 
   - if:
-      not:
-        properties:
-          compatible:
-            contains:
-              enum:
-                - renesas,r7s72100-dmac
+      properties:
+        compatible:
+          contains:
+            enum:
+              - renesas,r9a07g043-dmac
+              - renesas,r9a07g044-dmac
+              - renesas,r9a07g054-dmac
+              - renesas,r9a08g045-dmac
     then:
+      properties:
+        reg:
+          minItems: 2
+        clocks:
+          minItems: 2
+        resets:
+          minItems: 2
+
+        renesas,icu: false
+
       required:
         - clocks
         - clock-names
@@ -112,13 +154,42 @@ allOf:
         - resets
         - reset-names
 
-    else:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r7s72100-dmac
+    then:
       properties:
         clocks: false
         clock-names: false
         power-domains: false
         resets: false
         reset-names: false
+        renesas,icu: false
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a09g057-dmac
+    then:
+      properties:
+        reg:
+          maxItems: 1
+        clocks:
+          maxItems: 1
+        resets:
+          maxItems: 1
+
+        clock-names: false
+        reset-names: false
+
+      required:
+        - clocks
+        - power-domains
+        - renesas,icu
+        - resets
 
 additionalProperties: false
 
-- 
2.34.1

[PATCH v4 7/7] arm64: dts: renesas: r9a09g057: Add DMAC nodes

[Fabrizio Castro]

Add nodes for the DMAC IPs found on the Renesas RZ/V2H(P) SoC.

Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* No change.
---
 arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 165 +++++++++++++++++++++
 1 file changed, 165 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
index 1c550b22b164..0a7d0c801e32 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g057.dtsi
@@ -252,6 +252,171 @@ sys: system-controller@10430000 {
 			status = "disabled";
 		};
 
+		dmac0: dma-controller@11400000 {
+			compatible = "renesas,r9a09g057-dmac";
+			reg = <0 0x11400000 0 0x10000>;
+			interrupts = <GIC_SPI 499 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 89  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 90  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 91  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 92  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 93  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 94  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 95  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 96  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 97  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 98  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 99  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 100 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 101 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 102 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 103 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 104 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "error",
+					  "ch0", "ch1", "ch2", "ch3",
+					  "ch4", "ch5", "ch6", "ch7",
+					  "ch8", "ch9", "ch10", "ch11",
+					  "ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 0x0>;
+			power-domains = <&cpg>;
+			resets = <&cpg 0x31>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
+			renesas,icu = <&icu 4>;
+		};
+
+		dmac1: dma-controller@14830000 {
+			compatible = "renesas,r9a09g057-dmac";
+			reg = <0 0x14830000 0 0x10000>;
+			interrupts = <GIC_SPI 495 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 25  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 26  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 27  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 28  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 29  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 30  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 31  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 32  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 33  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 34  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 35  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 36  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 37  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 38  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 39  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 40  IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "error",
+					  "ch0", "ch1", "ch2", "ch3",
+					  "ch4", "ch5", "ch6", "ch7",
+					  "ch8", "ch9", "ch10", "ch11",
+					  "ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 0x1>;
+			power-domains = <&cpg>;
+			resets = <&cpg 0x32>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
+			renesas,icu = <&icu 0>;
+		};
+
+		dmac2: dma-controller@14840000 {
+			compatible = "renesas,r9a09g057-dmac";
+			reg = <0 0x14840000 0 0x10000>;
+			interrupts = <GIC_SPI 496 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 41  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 42  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 43  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 44  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 45  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 46  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 47  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 48  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 49  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 50  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 51  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 52  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 53  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 54  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 55  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 56  IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "error",
+					  "ch0", "ch1", "ch2", "ch3",
+					  "ch4", "ch5", "ch6", "ch7",
+					  "ch8", "ch9", "ch10", "ch11",
+					  "ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 0x2>;
+			power-domains = <&cpg>;
+			resets = <&cpg 0x33>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
+			renesas,icu = <&icu 1>;
+		};
+
+		dmac3: dma-controller@12000000 {
+			compatible = "renesas,r9a09g057-dmac";
+			reg = <0 0x12000000 0 0x10000>;
+			interrupts = <GIC_SPI 497 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 57  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 58  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 59  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 60  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 61  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 62  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 63  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 64  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 65  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 66  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 67  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 68  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 69  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 70  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 71  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 72  IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "error",
+					  "ch0", "ch1", "ch2", "ch3",
+					  "ch4", "ch5", "ch6", "ch7",
+					  "ch8", "ch9", "ch10", "ch11",
+					  "ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 0x3>;
+			power-domains = <&cpg>;
+			resets = <&cpg 0x34>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
+			renesas,icu = <&icu 2>;
+		};
+
+		dmac4: dma-controller@12010000 {
+			compatible = "renesas,r9a09g057-dmac";
+			reg = <0 0x12010000 0 0x10000>;
+			interrupts = <GIC_SPI 498 IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 73  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 74  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 75  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 76  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 77  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 78  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 79  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 80  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 81  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 82  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 83  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 84  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 85  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 86  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 87  IRQ_TYPE_EDGE_RISING>,
+				     <GIC_SPI 88  IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "error",
+					  "ch0", "ch1", "ch2", "ch3",
+					  "ch4", "ch5", "ch6", "ch7",
+					  "ch8", "ch9", "ch10", "ch11",
+					  "ch12", "ch13", "ch14", "ch15";
+			clocks = <&cpg CPG_MOD 0x4>;
+			power-domains = <&cpg>;
+			resets = <&cpg 0x35>;
+			#dma-cells = <1>;
+			dma-channels = <16>;
+			renesas,icu = <&icu 3>;
+		};
+
 		ostm0: timer@11800000 {
 			compatible = "renesas,r9a09g057-ostm", "renesas,ostm";
 			reg = <0x0 0x11800000 0x0 0x1000>;
-- 
2.34.1

Re: [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Thu, Feb 20, 2025 at 03:01:05PM +0000, Fabrizio Castro wrote:
> Make sure we don't allow for the clocks, clock-names, resets,
> reset-names. and power-domains properties for the Renesas
> RZ/A1H SoC because its DMAC doesn't have clocks, resets,
> and power domains.
> 
> Fixes: 209efec19c4c ("dt-bindings: dma: rz-dmac: Document RZ/A1H SoC")
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

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

Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Thu, Feb 20, 2025 at 03:01:06PM +0000, Fabrizio Castro wrote:
> Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> Renesas RZ/G2L family of SoCs, but there are some differences:
> * It only uses one register area
> * It only uses one clock
> * It only uses one reset
> * Instead of using MID/IRD it uses REQ NO/ACK NO
> * It is connected to the Interrupt Control Unit (ICU)
> 
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>

Acked-by: Conor Dooley <conor.dooley@microchip.com>

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

Re: [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H

[Lad, Prabhakar]

On Thu, Feb 20, 2025 at 3:02 PM Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
>
> Make sure we don't allow for the clocks, clock-names, resets,
> reset-names. and power-domains properties for the Renesas
> RZ/A1H SoC because its DMAC doesn't have clocks, resets,
> and power domains.
>
> Fixes: 209efec19c4c ("dt-bindings: dma: rz-dmac: Document RZ/A1H SoC")
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> v3->v4:
> * No change.
> v2->v3:
> * No change.
> v1->v2:
> * No change.
> ---
>  .../devicetree/bindings/dma/renesas,rz-dmac.yaml          | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> index b356251de5a8..82de3b927479 100644
> --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> @@ -112,6 +112,14 @@ allOf:
>          - resets
>          - reset-names
>
> +    else:
> +      properties:
> +        clocks: false
> +        clock-names: false
> +        power-domains: false
> +        resets: false
> +        reset-names: false
> +
>  additionalProperties: false
>
>  examples:
> --
> 2.34.1
>
>

Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Lad, Prabhakar]

On Thu, Feb 20, 2025 at 3:15 PM Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
>
> Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> Renesas RZ/G2L family of SoCs, but there are some differences:
> * It only uses one register area
> * It only uses one clock
> * It only uses one reset
> * Instead of using MID/IRD it uses REQ NO/ACK NO
> * It is connected to the Interrupt Control Unit (ICU)
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> v3->v4:
> * No change.
> v2->v3:
> * No change.
> v1->v2:
> * Removed RZ/V2H DMAC example.
> * Improved the readability of the `if` statement.
> ---
>  .../bindings/dma/renesas,rz-dmac.yaml         | 107 +++++++++++++++---
>  1 file changed, 89 insertions(+), 18 deletions(-)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Cheers,
Prabhakar

> diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> index 82de3b927479..4b89d199c022 100644
> --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> @@ -11,19 +11,23 @@ maintainers:
>
>  properties:
>    compatible:
> -    items:
> -      - enum:
> -          - renesas,r7s72100-dmac # RZ/A1H
> -          - renesas,r9a07g043-dmac # RZ/G2UL and RZ/Five
> -          - renesas,r9a07g044-dmac # RZ/G2{L,LC}
> -          - renesas,r9a07g054-dmac # RZ/V2L
> -          - renesas,r9a08g045-dmac # RZ/G3S
> -      - const: renesas,rz-dmac
> +    oneOf:
> +      - items:
> +          - enum:
> +              - renesas,r7s72100-dmac # RZ/A1H
> +              - renesas,r9a07g043-dmac # RZ/G2UL and RZ/Five
> +              - renesas,r9a07g044-dmac # RZ/G2{L,LC}
> +              - renesas,r9a07g054-dmac # RZ/V2L
> +              - renesas,r9a08g045-dmac # RZ/G3S
> +          - const: renesas,rz-dmac
> +
> +      - const: renesas,r9a09g057-dmac # RZ/V2H(P)
>
>    reg:
>      items:
>        - description: Control and channel register block
>        - description: DMA extended resource selector block
> +    minItems: 1
>
>    interrupts:
>      maxItems: 17
> @@ -52,6 +56,7 @@ properties:
>      items:
>        - description: DMA main clock
>        - description: DMA register access clock
> +    minItems: 1
>
>    clock-names:
>      items:
> @@ -61,14 +66,22 @@ properties:
>    '#dma-cells':
>      const: 1
>      description:
> -      The cell specifies the encoded MID/RID values of the DMAC port
> -      connected to the DMA client and the slave channel configuration
> -      parameters.
> +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> +      specifies the encoded MID/RID values of the DMAC port connected to the
> +      DMA client and the slave channel configuration parameters.
>        bits[0:9] - Specifies MID/RID value
>        bit[10] - Specifies DMA request high enable (HIEN)
>        bit[11] - Specifies DMA request detection type (LVL)
>        bits[12:14] - Specifies DMAACK output mode (AM)
>        bit[15] - Specifies Transfer Mode (TM)
> +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> +      slave channel configuration parameters.
> +      bits[0:9] - Specifies the REQ NO
> +      bits[10:16] - Specifies the ACK NO
> +      bit[17] - Specifies DMA request high enable (HIEN)
> +      bit[18] - Specifies DMA request detection type (LVL)
> +      bits[19:21] - Specifies DMAACK output mode (AM)
> +      bit[22] - Specifies Transfer Mode (TM)
>
>    dma-channels:
>      const: 16
> @@ -80,12 +93,29 @@ properties:
>      items:
>        - description: Reset for DMA ARESETN reset terminal
>        - description: Reset for DMA RST_ASYNC reset terminal
> +    minItems: 1
>
>    reset-names:
>      items:
>        - const: arst
>        - const: rst_async
>
> +  renesas,icu:
> +    description:
> +      On the RZ/V2H(P) SoC configures the ICU to which the DMAC is connected to.
> +      It must contain the phandle to the ICU, and the index of the DMAC as seen
> +      from the ICU (e.g. parameter k from register ICU_DMkSELy).
> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +    items:
> +      - items:
> +          - description: phandle to the ICU node.
> +          - description: The DMAC index.
> +              4 for DMAC0
> +              0 for DMAC1
> +              1 for DMAC2
> +              2 for DMAC3
> +              3 for DMAC4
> +
>  required:
>    - compatible
>    - reg
> @@ -98,13 +128,25 @@ allOf:
>    - $ref: dma-controller.yaml#
>
>    - if:
> -      not:
> -        properties:
> -          compatible:
> -            contains:
> -              enum:
> -                - renesas,r7s72100-dmac
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - renesas,r9a07g043-dmac
> +              - renesas,r9a07g044-dmac
> +              - renesas,r9a07g054-dmac
> +              - renesas,r9a08g045-dmac
>      then:
> +      properties:
> +        reg:
> +          minItems: 2
> +        clocks:
> +          minItems: 2
> +        resets:
> +          minItems: 2
> +
> +        renesas,icu: false
> +
>        required:
>          - clocks
>          - clock-names
> @@ -112,13 +154,42 @@ allOf:
>          - resets
>          - reset-names
>
> -    else:
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: renesas,r7s72100-dmac
> +    then:
>        properties:
>          clocks: false
>          clock-names: false
>          power-domains: false
>          resets: false
>          reset-names: false
> +        renesas,icu: false
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: renesas,r9a09g057-dmac
> +    then:
> +      properties:
> +        reg:
> +          maxItems: 1
> +        clocks:
> +          maxItems: 1
> +        resets:
> +          maxItems: 1
> +
> +        clock-names: false
> +        reset-names: false
> +
> +      required:
> +        - clocks
> +        - power-domains
> +        - renesas,icu
> +        - resets
>
>  additionalProperties: false
>
> --
> 2.34.1
>
>

Re: [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H

[Geert Uytterhoeven]

On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> Make sure we don't allow for the clocks, clock-names, resets,
> reset-names. and power-domains properties for the Renesas
> RZ/A1H SoC because its DMAC doesn't have clocks, resets,
> and power domains.
>
> Fixes: 209efec19c4c ("dt-bindings: dma: rz-dmac: Document RZ/A1H SoC")
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Geert Uytterhoeven]

Hi Fabrizio,

On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> Renesas RZ/G2L family of SoCs, but there are some differences:
> * It only uses one register area
> * It only uses one clock
> * It only uses one reset
> * Instead of using MID/IRD it uses REQ NO/ACK NO
> * It is connected to the Interrupt Control Unit (ICU)
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>

> v1->v2:
> * Removed RZ/V2H DMAC example.
> * Improved the readability of the `if` statement.

Thanks for the update!

> --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> @@ -61,14 +66,22 @@ properties:
>    '#dma-cells':
>      const: 1
>      description:
> -      The cell specifies the encoded MID/RID values of the DMAC port
> -      connected to the DMA client and the slave channel configuration
> -      parameters.
> +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> +      specifies the encoded MID/RID values of the DMAC port connected to the
> +      DMA client and the slave channel configuration parameters.
>        bits[0:9] - Specifies MID/RID value
>        bit[10] - Specifies DMA request high enable (HIEN)
>        bit[11] - Specifies DMA request detection type (LVL)
>        bits[12:14] - Specifies DMAACK output mode (AM)
>        bit[15] - Specifies Transfer Mode (TM)
> +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> +      slave channel configuration parameters.
> +      bits[0:9] - Specifies the REQ NO

So REQ_NO is the new name for MID/RID.

> +      bits[10:16] - Specifies the ACK NO

This is a new field.
However, it is not clear to me which value to specify here, and if this
is a hardware property at all, and thus needs to be specified in DT?

> +      bit[17] - Specifies DMA request high enable (HIEN)
> +      bit[18] - Specifies DMA request detection type (LVL)
> +      bits[19:21] - Specifies DMAACK output mode (AM)
> +      bit[22] - Specifies Transfer Mode (TM)

These are the same as on other RZ SoCs.
So wouldn't it be simpler to move ACK NO to the end (iff you need it
in DT), so the rest of the layout stays the same as on other RZ SoCs?

The rest LGTM.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v4 7/7] arm64: dts: renesas: r9a09g057: Add DMAC nodes

[Geert Uytterhoeven]

On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> Add nodes for the DMAC IPs found on the Renesas RZ/V2H(P) SoC.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Fabrizio Castro]

Hi Geert,

Thanks for your feedback!

> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 24 February 2025 12:44
> Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> 
> Hi Fabrizio,
> 
> On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > Renesas RZ/G2L family of SoCs, but there are some differences:
> > * It only uses one register area
> > * It only uses one clock
> > * It only uses one reset
> > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > * It is connected to the Interrupt Control Unit (ICU)
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> 
> > v1->v2:
> > * Removed RZ/V2H DMAC example.
> > * Improved the readability of the `if` statement.
> 
> Thanks for the update!
> 
> > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > @@ -61,14 +66,22 @@ properties:
> >    '#dma-cells':
> >      const: 1
> >      description:
> > -      The cell specifies the encoded MID/RID values of the DMAC port
> > -      connected to the DMA client and the slave channel configuration
> > -      parameters.
> > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > +      DMA client and the slave channel configuration parameters.
> >        bits[0:9] - Specifies MID/RID value
> >        bit[10] - Specifies DMA request high enable (HIEN)
> >        bit[11] - Specifies DMA request detection type (LVL)
> >        bits[12:14] - Specifies DMAACK output mode (AM)
> >        bit[15] - Specifies Transfer Mode (TM)
> > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > +      slave channel configuration parameters.
> > +      bits[0:9] - Specifies the REQ NO
> 
> So REQ_NO is the new name for MID/RID.

It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.

> 
> > +      bits[10:16] - Specifies the ACK NO
> 
> This is a new field.
> However, it is not clear to me which value to specify here, and if this
> is a hardware property at all, and thus needs to be specified in DT?

It is a HW property. The value to set can be found in Table 4.6-27 from
the HW User Manual, column "Ack No".

> 
> > +      bit[17] - Specifies DMA request high enable (HIEN)
> > +      bit[18] - Specifies DMA request detection type (LVL)
> > +      bits[19:21] - Specifies DMAACK output mode (AM)
> > +      bit[22] - Specifies Transfer Mode (TM)
> 
> These are the same as on other RZ SoCs.
> So wouldn't it be simpler to move ACK NO to the end (iff you need it
> in DT), so the rest of the layout stays the same as on other RZ SoCs?

I can certainly do that.

Thanks!

Fab

> 
> The rest LGTM.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Geert Uytterhoeven]

Hi Fabrizio,

On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > Sent: 24 February 2025 12:44
> > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> >
> > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > <fabrizio.castro.jz@renesas.com> wrote:
> > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > * It only uses one register area
> > > * It only uses one clock
> > > * It only uses one reset
> > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > * It is connected to the Interrupt Control Unit (ICU)
> > >
> > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> >
> > > v1->v2:
> > > * Removed RZ/V2H DMAC example.
> > > * Improved the readability of the `if` statement.
> >
> > Thanks for the update!
> >
> > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > @@ -61,14 +66,22 @@ properties:
> > >    '#dma-cells':
> > >      const: 1
> > >      description:
> > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > -      connected to the DMA client and the slave channel configuration
> > > -      parameters.
> > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > +      DMA client and the slave channel configuration parameters.
> > >        bits[0:9] - Specifies MID/RID value
> > >        bit[10] - Specifies DMA request high enable (HIEN)
> > >        bit[11] - Specifies DMA request detection type (LVL)
> > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > >        bit[15] - Specifies Transfer Mode (TM)
> > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > +      slave channel configuration parameters.
> > > +      bits[0:9] - Specifies the REQ NO
> >
> > So REQ_NO is the new name for MID/RID.

These are documented in Table 4.7-22 ("DMA Transfer Request Detection
Operation Setting Table").

> It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
>
> > > +      bits[10:16] - Specifies the ACK NO
> >
> > This is a new field.
> > However, it is not clear to me which value to specify here, and if this
> > is a hardware property at all, and thus needs to be specified in DT?
>
> It is a HW property. The value to set can be found in Table 4.6-27 from
> the HW User Manual, column "Ack No".

Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
(for external DMA requests).  The most familiar DMA clients listed
in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
which values does it need for ACK_NO?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Fabrizio Castro]

Hi Geert,

Thanks for your feedback!

> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 28 February 2025 10:17
> Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> 
> Hi Fabrizio,
> 
> On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 24 February 2025 12:44
> > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> > >
> > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > * It only uses one register area
> > > > * It only uses one clock
> > > > * It only uses one reset
> > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > * It is connected to the Interrupt Control Unit (ICU)
> > > >
> > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > >
> > > > v1->v2:
> > > > * Removed RZ/V2H DMAC example.
> > > > * Improved the readability of the `if` statement.
> > >
> > > Thanks for the update!
> > >
> > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > @@ -61,14 +66,22 @@ properties:
> > > >    '#dma-cells':
> > > >      const: 1
> > > >      description:
> > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > -      connected to the DMA client and the slave channel configuration
> > > > -      parameters.
> > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > +      DMA client and the slave channel configuration parameters.
> > > >        bits[0:9] - Specifies MID/RID value
> > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > +      slave channel configuration parameters.
> > > > +      bits[0:9] - Specifies the REQ NO
> > >
> > > So REQ_NO is the new name for MID/RID.
> 
> These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> Operation Setting Table").

REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).

> 
> > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> >
> > > > +      bits[10:16] - Specifies the ACK NO
> > >
> > > This is a new field.
> > > However, it is not clear to me which value to specify here, and if this
> > > is a hardware property at all, and thus needs to be specified in DT?
> >
> > It is a HW property. The value to set can be found in Table 4.6-27 from
> > the HW User Manual, column "Ack No".
> 
> Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> (for external DMA requests).  The most familiar DMA clients listed
> in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> which values does it need for ACK_NO?

Only a handful of devices need it. For every other device (and use case) only the
default value is needed.

But I'll take this out for now, until we get to support a device that actually
needs ACK NO.

Thanks!

Fab

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Geert Uytterhoeven]

Hi Fabrizio,

On Fri, 28 Feb 2025 at 15:55, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > Sent: 28 February 2025 10:17
> > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> >
> > Hi Fabrizio,
> >
> > On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> > <fabrizio.castro.jz@renesas.com> wrote:
> > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > Sent: 24 February 2025 12:44
> > > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> > > >
> > > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > > * It only uses one register area
> > > > > * It only uses one clock
> > > > > * It only uses one reset
> > > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > > * It is connected to the Interrupt Control Unit (ICU)
> > > > >
> > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > > >
> > > > > v1->v2:
> > > > > * Removed RZ/V2H DMAC example.
> > > > > * Improved the readability of the `if` statement.
> > > >
> > > > Thanks for the update!
> > > >
> > > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > @@ -61,14 +66,22 @@ properties:
> > > > >    '#dma-cells':
> > > > >      const: 1
> > > > >      description:
> > > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > > -      connected to the DMA client and the slave channel configuration
> > > > > -      parameters.
> > > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > > +      DMA client and the slave channel configuration parameters.
> > > > >        bits[0:9] - Specifies MID/RID value
> > > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > > +      slave channel configuration parameters.
> > > > > +      bits[0:9] - Specifies the REQ NO
> > > >
> > > > So REQ_NO is the new name for MID/RID.
> >
> > These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> > Operation Setting Table").
>
> REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).

Indeed. But not for all of them. E.g. RSPI is missing, IIC is present.
And the numbers are shown in decimal instead of in hex ;-)

> > > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> > >
> > > > > +      bits[10:16] - Specifies the ACK NO
> > > >
> > > > This is a new field.
> > > > However, it is not clear to me which value to specify here, and if this
> > > > is a hardware property at all, and thus needs to be specified in DT?
> > >
> > > It is a HW property. The value to set can be found in Table 4.6-27 from
> > > the HW User Manual, column "Ack No".
> >
> > Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> > (for external DMA requests).  The most familiar DMA clients listed
> > in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> > which values does it need for ACK_NO?
>
> Only a handful of devices need it. For every other device (and use case) only the
> default value is needed.

The default value is RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f?
Which I believe already causes you to run into the out-of-range DMACKSELk
register offset in rzv2h_icu_register_dma_req_ack()?

> But I'll take this out for now, until we get to support a device that actually
> needs ACK NO.

OK.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Fabrizio Castro]

Hi Geert,

Thanks for your feedback!

> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 28 February 2025 15:16
> Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> 
> Hi Fabrizio,
> 
> On Fri, 28 Feb 2025 at 15:55, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: 28 February 2025 10:17
> > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> > >
> > > Hi Fabrizio,
> > >
> > > On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > Sent: 24 February 2025 12:44
> > > > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> > > > >
> > > > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > > > * It only uses one register area
> > > > > > * It only uses one clock
> > > > > > * It only uses one reset
> > > > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > > > * It is connected to the Interrupt Control Unit (ICU)
> > > > > >
> > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > > > >
> > > > > > v1->v2:
> > > > > > * Removed RZ/V2H DMAC example.
> > > > > > * Improved the readability of the `if` statement.
> > > > >
> > > > > Thanks for the update!
> > > > >
> > > > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > @@ -61,14 +66,22 @@ properties:
> > > > > >    '#dma-cells':
> > > > > >      const: 1
> > > > > >      description:
> > > > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > > > -      connected to the DMA client and the slave channel configuration
> > > > > > -      parameters.
> > > > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > > > +      DMA client and the slave channel configuration parameters.
> > > > > >        bits[0:9] - Specifies MID/RID value
> > > > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > > > +      slave channel configuration parameters.
> > > > > > +      bits[0:9] - Specifies the REQ NO
> > > > >
> > > > > So REQ_NO is the new name for MID/RID.
> > >
> > > These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> > > Operation Setting Table").
> >
> > REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).
> 
> Indeed. But not for all of them. E.g. RSPI is missing, IIC is present.

I can see the RSPI related `REQ No.` in the version of the manual I am using,
although one must be very careful to look at the right entry in the table,
as the table is quite big, and the entries are ordered by `SPI No.`.

For some devices, the SPI numbers are not contiguous therefore the device specific
bits may end up scattered.
For example, for `Name` `RSPI_CH0_sp_rxintpls_n` (mind that the `pls_n` substring
is on a new line in the table) you can see from Table 4.6-23 that
its `DMAC No.` is 140 (as you said, in decimal...).

> And the numbers are shown in decimal instead of in hex ;-)
> 
> > > > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> > > >
> > > > > > +      bits[10:16] - Specifies the ACK NO
> > > > >
> > > > > This is a new field.
> > > > > However, it is not clear to me which value to specify here, and if this
> > > > > is a hardware property at all, and thus needs to be specified in DT?
> > > >
> > > > It is a HW property. The value to set can be found in Table 4.6-27 from
> > > > the HW User Manual, column "Ack No".
> > >
> > > Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> > > (for external DMA requests).  The most familiar DMA clients listed
> > > in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> > > which values does it need for ACK_NO?
> >
> > Only a handful of devices need it. For every other device (and use case) only the
> > default value is needed.
> 
> The default value is RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f?

Yes.

Thanks!

Fab


> Which I believe already causes you to run into the out-of-range DMACKSELk
> register offset in rzv2h_icu_register_dma_req_ack()?
> 
> > But I'll take this out for now, until we get to support a device that actually
> > needs ACK NO.
> 
> OK.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Geert Uytterhoeven]

Hi Fabrizio,

On Fri, 28 Feb 2025 at 16:38, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > On Fri, 28 Feb 2025 at 15:55, Fabrizio Castro
> > <fabrizio.castro.jz@renesas.com> wrote:
> > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > Sent: 24 February 2025 12:44
> > > > > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> > > > > >
> > > > > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > > > > * It only uses one register area
> > > > > > > * It only uses one clock
> > > > > > > * It only uses one reset
> > > > > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > > > > * It is connected to the Interrupt Control Unit (ICU)
> > > > > > >
> > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > > > > >
> > > > > > > v1->v2:
> > > > > > > * Removed RZ/V2H DMAC example.
> > > > > > > * Improved the readability of the `if` statement.
> > > > > >
> > > > > > Thanks for the update!
> > > > > >
> > > > > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > @@ -61,14 +66,22 @@ properties:
> > > > > > >    '#dma-cells':
> > > > > > >      const: 1
> > > > > > >      description:
> > > > > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > > > > -      connected to the DMA client and the slave channel configuration
> > > > > > > -      parameters.
> > > > > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > > > > +      DMA client and the slave channel configuration parameters.
> > > > > > >        bits[0:9] - Specifies MID/RID value
> > > > > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > > > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > > > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > > > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > > > > +      slave channel configuration parameters.
> > > > > > > +      bits[0:9] - Specifies the REQ NO
> > > > > >
> > > > > > So REQ_NO is the new name for MID/RID.
> > > >
> > > > These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> > > > Operation Setting Table").
> > >
> > > REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).
> >
> > Indeed. But not for all of them. E.g. RSPI is missing, IIC is present.
>
> I can see the RSPI related `REQ No.` in the version of the manual I am using,
> although one must be very careful to look at the right entry in the table,
> as the table is quite big, and the entries are ordered by `SPI No.`.
>
> For some devices, the SPI numbers are not contiguous therefore the device specific
> bits may end up scattered.
> For example, for `Name` `RSPI_CH0_sp_rxintpls_n` (mind that the `pls_n` substring
> is on a new line in the table) you can see from Table 4.6-23 that
> its `DMAC No.` is 140 (as you said, in decimal...).

Thanks, I had missed it because the RSPI interrupts are spread across
two places...

> > And the numbers are shown in decimal instead of in hex ;-)
> >
> > > > > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> > > > >
> > > > > > > +      bits[10:16] - Specifies the ACK NO
> > > > > >
> > > > > > This is a new field.
> > > > > > However, it is not clear to me which value to specify here, and if this
> > > > > > is a hardware property at all, and thus needs to be specified in DT?
> > > > >
> > > > > It is a HW property. The value to set can be found in Table 4.6-27 from
> > > > > the HW User Manual, column "Ack No".
> > > >
> > > > Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> > > > (for external DMA requests).  The most familiar DMA clients listed
> > > > in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> > > > which values does it need for ACK_NO?
> > >
> > > Only a handful of devices need it. For every other device (and use case) only the
> > > default value is needed.
> >
> > The default value is RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f?

If you take this out, how to distinguish between ACK_NO = 0 and
the default?

> > Which I believe already causes you to run into the out-of-range DMACKSELk
> > register offset in rzv2h_icu_register_dma_req_ack()?
> >
> > > But I'll take this out for now, until we get to support a device that actually
> > > needs ACK NO.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Fabrizio Castro]

Hi Geert,

> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 28 February 2025 15:57
> Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> 
> Hi Fabrizio,
> 
> On Fri, 28 Feb 2025 at 16:38, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > On Fri, 28 Feb 2025 at 15:55, Fabrizio Castro
> > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > > Sent: 24 February 2025 12:44
> > > > > > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> > > > > > >
> > > > > > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > > > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > > > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > > > > > * It only uses one register area
> > > > > > > > * It only uses one clock
> > > > > > > > * It only uses one reset
> > > > > > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > > > > > * It is connected to the Interrupt Control Unit (ICU)
> > > > > > > >
> > > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > > > > > >
> > > > > > > > v1->v2:
> > > > > > > > * Removed RZ/V2H DMAC example.
> > > > > > > > * Improved the readability of the `if` statement.
> > > > > > >
> > > > > > > Thanks for the update!
> > > > > > >
> > > > > > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > @@ -61,14 +66,22 @@ properties:
> > > > > > > >    '#dma-cells':
> > > > > > > >      const: 1
> > > > > > > >      description:
> > > > > > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > > > > > -      connected to the DMA client and the slave channel configuration
> > > > > > > > -      parameters.
> > > > > > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > > > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > > > > > +      DMA client and the slave channel configuration parameters.
> > > > > > > >        bits[0:9] - Specifies MID/RID value
> > > > > > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > > > > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > > > > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > > > > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > > > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > > > > > +      slave channel configuration parameters.
> > > > > > > > +      bits[0:9] - Specifies the REQ NO
> > > > > > >
> > > > > > > So REQ_NO is the new name for MID/RID.
> > > > >
> > > > > These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> > > > > Operation Setting Table").
> > > >
> > > > REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).
> > >
> > > Indeed. But not for all of them. E.g. RSPI is missing, IIC is present.
> >
> > I can see the RSPI related `REQ No.` in the version of the manual I am using,
> > although one must be very careful to look at the right entry in the table,
> > as the table is quite big, and the entries are ordered by `SPI No.`.
> >
> > For some devices, the SPI numbers are not contiguous therefore the device specific
> > bits may end up scattered.
> > For example, for `Name` `RSPI_CH0_sp_rxintpls_n` (mind that the `pls_n` substring
> > is on a new line in the table) you can see from Table 4.6-23 that
> > its `DMAC No.` is 140 (as you said, in decimal...).
> 
> Thanks, I had missed it because the RSPI interrupts are spread across
> two places...
> 
> > > And the numbers are shown in decimal instead of in hex ;-)
> > >
> > > > > > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> > > > > >
> > > > > > > > +      bits[10:16] - Specifies the ACK NO
> > > > > > >
> > > > > > > This is a new field.
> > > > > > > However, it is not clear to me which value to specify here, and if this
> > > > > > > is a hardware property at all, and thus needs to be specified in DT?
> > > > > >
> > > > > > It is a HW property. The value to set can be found in Table 4.6-27 from
> > > > > > the HW User Manual, column "Ack No".
> > > > >
> > > > > Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> > > > > (for external DMA requests).  The most familiar DMA clients listed
> > > > > in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> > > > > which values does it need for ACK_NO?
> > > >
> > > > Only a handful of devices need it. For every other device (and use case) only the
> > > > default value is needed.
> > >
> > > The default value is RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f?
> 
> If you take this out, how to distinguish between ACK_NO = 0 and
> the default?

I am not sure I understand what you mean, so my answer here may be completely off.

ACK No. 0 corresponds to SPDIF, CH0, TX, while ACK No. 0x7F is not valid.

My understanding of this is that there is a DACK_SEL field per ACK No (23 ICU_DMACKSELk
registers, 4 DACK_SEL fields per ICU_DMACKSELk registers -> 23 * 4 = 92 DACK_SEL fields),
to match the 92 ACK numbers listed in Table 4.6-27.

Each DACK_SEL field should contain the global channel index (5 DMACs, 16 channels per DMAC
-> 5 * 16 = 80 channels in total) associated to the ACK No.
If DACK_SEL contains a valid channel number (0-79), then the corresponding signal
gets controlled accordingly, otherwise a fixed output is generated instead.

Mind that the code I sent wasn't dealing with it properly, but wasn't spotted due
to limited testing capabilities, and it's safe to take out, as the DACK_SEL fields
will all contain invalid channel numbers by default.

Looking ahead, there is a similar scenario with the TEND signals as well.

So for now the plan is to upstream support for memory/memory and device/memory (REQ No.,
tested with RSPI), add support for ACK No later (perhaps testing it with audio, or via
an external device), and finally TEND No if we get to it.

Thanks!

Fab

> 
> > > Which I believe already causes you to run into the out-of-range DMACKSELk
> > > register offset in rzv2h_icu_register_dma_req_ack()?
> > >
> > > > But I'll take this out for now, until we get to support a device that actually
> > > > needs ACK NO.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Geert Uytterhoeven]

Hi Fabrizio,

On Fri, 28 Feb 2025 at 17:32, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > On Fri, 28 Feb 2025 at 16:38, Fabrizio Castro
> > <fabrizio.castro.jz@renesas.com> wrote:
> > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > On Fri, 28 Feb 2025 at 15:55, Fabrizio Castro
> > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > > > Sent: 24 February 2025 12:44
> > > > > > > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> > > > > > > >
> > > > > > > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > > > > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > > > > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > > > > > > * It only uses one register area
> > > > > > > > > * It only uses one clock
> > > > > > > > > * It only uses one reset
> > > > > > > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > > > > > > * It is connected to the Interrupt Control Unit (ICU)
> > > > > > > > >
> > > > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > > > > > > >
> > > > > > > > > v1->v2:
> > > > > > > > > * Removed RZ/V2H DMAC example.
> > > > > > > > > * Improved the readability of the `if` statement.
> > > > > > > >
> > > > > > > > Thanks for the update!
> > > > > > > >
> > > > > > > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > > @@ -61,14 +66,22 @@ properties:
> > > > > > > > >    '#dma-cells':
> > > > > > > > >      const: 1
> > > > > > > > >      description:
> > > > > > > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > > > > > > -      connected to the DMA client and the slave channel configuration
> > > > > > > > > -      parameters.
> > > > > > > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > > > > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > > > > > > +      DMA client and the slave channel configuration parameters.
> > > > > > > > >        bits[0:9] - Specifies MID/RID value
> > > > > > > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > > > > > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > > > > > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > > > > > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > > > > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > > > > > > +      slave channel configuration parameters.
> > > > > > > > > +      bits[0:9] - Specifies the REQ NO
> > > > > > > >
> > > > > > > > So REQ_NO is the new name for MID/RID.
> > > > > >
> > > > > > These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> > > > > > Operation Setting Table").
> > > > >
> > > > > REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).
> > > >
> > > > Indeed. But not for all of them. E.g. RSPI is missing, IIC is present.
> > >
> > > I can see the RSPI related `REQ No.` in the version of the manual I am using,
> > > although one must be very careful to look at the right entry in the table,
> > > as the table is quite big, and the entries are ordered by `SPI No.`.
> > >
> > > For some devices, the SPI numbers are not contiguous therefore the device specific
> > > bits may end up scattered.
> > > For example, for `Name` `RSPI_CH0_sp_rxintpls_n` (mind that the `pls_n` substring
> > > is on a new line in the table) you can see from Table 4.6-23 that
> > > its `DMAC No.` is 140 (as you said, in decimal...).
> >
> > Thanks, I had missed it because the RSPI interrupts are spread across
> > two places...
> >
> > > > And the numbers are shown in decimal instead of in hex ;-)
> > > >
> > > > > > > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> > > > > > >
> > > > > > > > > +      bits[10:16] - Specifies the ACK NO
> > > > > > > >
> > > > > > > > This is a new field.
> > > > > > > > However, it is not clear to me which value to specify here, and if this
> > > > > > > > is a hardware property at all, and thus needs to be specified in DT?
> > > > > > >
> > > > > > > It is a HW property. The value to set can be found in Table 4.6-27 from
> > > > > > > the HW User Manual, column "Ack No".
> > > > > >
> > > > > > Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> > > > > > (for external DMA requests).  The most familiar DMA clients listed
> > > > > > in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> > > > > > which values does it need for ACK_NO?
> > > > >
> > > > > Only a handful of devices need it. For every other device (and use case) only the
> > > > > default value is needed.
> > > >
> > > > The default value is RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f?
> >
> > If you take this out, how to distinguish between ACK_NO = 0 and
> > the default?
>
> I am not sure I understand what you mean, so my answer here may be completely off.
>
> ACK No. 0 corresponds to SPDIF, CH0, TX, while ACK No. 0x7F is not valid.

OK, that was my understanding, too.

> My understanding of this is that there is a DACK_SEL field per ACK No (23 ICU_DMACKSELk
> registers, 4 DACK_SEL fields per ICU_DMACKSELk registers -> 23 * 4 = 92 DACK_SEL fields),
> to match the 92 ACK numbers listed in Table 4.6-27.
>
> Each DACK_SEL field should contain the global channel index (5 DMACs, 16 channels per DMAC
> -> 5 * 16 = 80 channels in total) associated to the ACK No.
> If DACK_SEL contains a valid channel number (0-79), then the corresponding signal
> gets controlled accordingly, otherwise a fixed output is generated instead.
>
> Mind that the code I sent wasn't dealing with it properly, but wasn't spotted due
> to limited testing capabilities, and it's safe to take out, as the DACK_SEL fields
> will all contain invalid channel numbers by default.
>
> Looking ahead, there is a similar scenario with the TEND signals as well.
>
> So for now the plan is to upstream support for memory/memory and device/memory (REQ No.,
> tested with RSPI), add support for ACK No later (perhaps testing it with audio, or via
> an external device), and finally TEND No if we get to it.

So which values will you put in the dmas property for RSPI?
I assume:
       bits[0:9] - Specifies REQ_NO value
       bit[10] - Specifies DMA request high enable (HIEN)
       bit[11] - Specifies DMA request detection type (LVL)
       bits[12:14] - Specifies DMAACK output mode (AM)
       bit[15] - Specifies Transfer Mode (TM)
i.e. all remaining bits will be zero?

How do you plan to handle adding ACK_NO bits later?
I.e. how to distinguish between remaining bits zero and remaining
bits containing a valid ACK_NO value (which can be zero, for SPDIF)?

I hope I made myself clear this time.
If not, weekend time ;-)

Have a nice weekend!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Fabrizio Castro]

Hi Geert,

> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 28 February 2025 16:44
> Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> 
> Hi Fabrizio,
> 
> On Fri, 28 Feb 2025 at 17:32, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > On Fri, 28 Feb 2025 at 16:38, Fabrizio Castro
> > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > On Fri, 28 Feb 2025 at 15:55, Fabrizio Castro
> > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > > On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> > > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > > > > Sent: 24 February 2025 12:44
> > > > > > > > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of
> SoCs
> > > > > > > > >
> > > > > > > > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > > > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > > > > > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > > > > > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > > > > > > > * It only uses one register area
> > > > > > > > > > * It only uses one clock
> > > > > > > > > > * It only uses one reset
> > > > > > > > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > > > > > > > * It is connected to the Interrupt Control Unit (ICU)
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > > > > > > > >
> > > > > > > > > > v1->v2:
> > > > > > > > > > * Removed RZ/V2H DMAC example.
> > > > > > > > > > * Improved the readability of the `if` statement.
> > > > > > > > >
> > > > > > > > > Thanks for the update!
> > > > > > > > >
> > > > > > > > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > > > @@ -61,14 +66,22 @@ properties:
> > > > > > > > > >    '#dma-cells':
> > > > > > > > > >      const: 1
> > > > > > > > > >      description:
> > > > > > > > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > > > > > > > -      connected to the DMA client and the slave channel configuration
> > > > > > > > > > -      parameters.
> > > > > > > > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > > > > > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > > > > > > > +      DMA client and the slave channel configuration parameters.
> > > > > > > > > >        bits[0:9] - Specifies MID/RID value
> > > > > > > > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > > > > > > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > > > > > > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > > > > > > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > > > > > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > > > > > > > +      slave channel configuration parameters.
> > > > > > > > > > +      bits[0:9] - Specifies the REQ NO
> > > > > > > > >
> > > > > > > > > So REQ_NO is the new name for MID/RID.
> > > > > > >
> > > > > > > These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> > > > > > > Operation Setting Table").
> > > > > >
> > > > > > REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).
> > > > >
> > > > > Indeed. But not for all of them. E.g. RSPI is missing, IIC is present.
> > > >
> > > > I can see the RSPI related `REQ No.` in the version of the manual I am using,
> > > > although one must be very careful to look at the right entry in the table,
> > > > as the table is quite big, and the entries are ordered by `SPI No.`.
> > > >
> > > > For some devices, the SPI numbers are not contiguous therefore the device specific
> > > > bits may end up scattered.
> > > > For example, for `Name` `RSPI_CH0_sp_rxintpls_n` (mind that the `pls_n` substring
> > > > is on a new line in the table) you can see from Table 4.6-23 that
> > > > its `DMAC No.` is 140 (as you said, in decimal...).
> > >
> > > Thanks, I had missed it because the RSPI interrupts are spread across
> > > two places...
> > >
> > > > > And the numbers are shown in decimal instead of in hex ;-)
> > > > >
> > > > > > > > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> > > > > > > >
> > > > > > > > > > +      bits[10:16] - Specifies the ACK NO
> > > > > > > > >
> > > > > > > > > This is a new field.
> > > > > > > > > However, it is not clear to me which value to specify here, and if this
> > > > > > > > > is a hardware property at all, and thus needs to be specified in DT?
> > > > > > > >
> > > > > > > > It is a HW property. The value to set can be found in Table 4.6-27 from
> > > > > > > > the HW User Manual, column "Ack No".
> > > > > > >
> > > > > > > Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> > > > > > > (for external DMA requests).  The most familiar DMA clients listed
> > > > > > > in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> > > > > > > which values does it need for ACK_NO?
> > > > > >
> > > > > > Only a handful of devices need it. For every other device (and use case) only the
> > > > > > default value is needed.
> > > > >
> > > > > The default value is RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f?
> > >
> > > If you take this out, how to distinguish between ACK_NO = 0 and
> > > the default?
> >
> > I am not sure I understand what you mean, so my answer here may be completely off.
> >
> > ACK No. 0 corresponds to SPDIF, CH0, TX, while ACK No. 0x7F is not valid.
> 
> OK, that was my understanding, too.
> 
> > My understanding of this is that there is a DACK_SEL field per ACK No (23 ICU_DMACKSELk
> > registers, 4 DACK_SEL fields per ICU_DMACKSELk registers -> 23 * 4 = 92 DACK_SEL fields),
> > to match the 92 ACK numbers listed in Table 4.6-27.
> >
> > Each DACK_SEL field should contain the global channel index (5 DMACs, 16 channels per DMAC
> > -> 5 * 16 = 80 channels in total) associated to the ACK No.
> > If DACK_SEL contains a valid channel number (0-79), then the corresponding signal
> > gets controlled accordingly, otherwise a fixed output is generated instead.
> >
> > Mind that the code I sent wasn't dealing with it properly, but wasn't spotted due
> > to limited testing capabilities, and it's safe to take out, as the DACK_SEL fields
> > will all contain invalid channel numbers by default.
> >
> > Looking ahead, there is a similar scenario with the TEND signals as well.
> >
> > So for now the plan is to upstream support for memory/memory and device/memory (REQ No.,
> > tested with RSPI), add support for ACK No later (perhaps testing it with audio, or via
> > an external device), and finally TEND No if we get to it.
> 
> So which values will you put in the dmas property for RSPI?
> I assume:
>        bits[0:9] - Specifies REQ_NO value
>        bit[10] - Specifies DMA request high enable (HIEN)
>        bit[11] - Specifies DMA request detection type (LVL)
>        bits[12:14] - Specifies DMAACK output mode (AM)
>        bit[15] - Specifies Transfer Mode (TM)
> i.e. all remaining bits will be zero?

I see what you mean now. And there would be an ABI mismatch between older DTs and newer kernels,
newer kernels would interpret the values incorrectly (as you said, 0 is a valid number).

> 
> How do you plan to handle adding ACK_NO bits later?
> I.e. how to distinguish between remaining bits zero and remaining
> bits containing a valid ACK_NO value (which can be zero, for SPDIF)?

We could add the ACK No. and the TEND No. to the binding (after TM), and implement it
later in the driver (once we have some practical use case for them)?

There are also a couple of alternatives:
* we could add 1 to ACK No. and TEND No.? At that point 0 would be an invalid number?
  In which case we could add DT and driver support later?
* we could fill up the remaining bits with 1s? We only have 5 TEND numbers, so 0b111 would
  be invalid. Similarly, we have 92 ACK numbers, so 0b1111111 would also be invalid. Also
  this shouldn't break the ABIs once we get around to add the rest?

> 
> I hope I made myself clear this time.

Very clear! Thank you.

> If not, weekend time ;-)
> 
> Have a nice weekend!

Thank you, and you!

Cheers,
Fab

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs

[Fabrizio Castro]

Hi Geert,

> From: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> Sent: 28 February 2025 17:29
> Subject: RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> 
> Hi Geert,
> 
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > Sent: 28 February 2025 16:44
> > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
> >
> > Hi Fabrizio,
> >
> > On Fri, 28 Feb 2025 at 17:32, Fabrizio Castro
> > <fabrizio.castro.jz@renesas.com> wrote:
> > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > On Fri, 28 Feb 2025 at 16:38, Fabrizio Castro
> > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > On Fri, 28 Feb 2025 at 15:55, Fabrizio Castro
> > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > > > On Thu, 27 Feb 2025 at 19:16, Fabrizio Castro
> > > > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > > > > > > > > Sent: 24 February 2025 12:44
> > > > > > > > > > Subject: Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of
> > SoCs
> > > > > > > > > >
> > > > > > > > > > On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> > > > > > > > > > <fabrizio.castro.jz@renesas.com> wrote:
> > > > > > > > > > > Document the Renesas RZ/V2H(P) family of SoCs DMAC block.
> > > > > > > > > > > The Renesas RZ/V2H(P) DMAC is very similar to the one found on the
> > > > > > > > > > > Renesas RZ/G2L family of SoCs, but there are some differences:
> > > > > > > > > > > * It only uses one register area
> > > > > > > > > > > * It only uses one clock
> > > > > > > > > > > * It only uses one reset
> > > > > > > > > > > * Instead of using MID/IRD it uses REQ NO/ACK NO
> > > > > > > > > > > * It is connected to the Interrupt Control Unit (ICU)
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > > > > > > > > >
> > > > > > > > > > > v1->v2:
> > > > > > > > > > > * Removed RZ/V2H DMAC example.
> > > > > > > > > > > * Improved the readability of the `if` statement.
> > > > > > > > > >
> > > > > > > > > > Thanks for the update!
> > > > > > > > > >
> > > > > > > > > > > --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > > > > +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
> > > > > > > > > > > @@ -61,14 +66,22 @@ properties:
> > > > > > > > > > >    '#dma-cells':
> > > > > > > > > > >      const: 1
> > > > > > > > > > >      description:
> > > > > > > > > > > -      The cell specifies the encoded MID/RID values of the DMAC port
> > > > > > > > > > > -      connected to the DMA client and the slave channel configuration
> > > > > > > > > > > -      parameters.
> > > > > > > > > > > +      For the RZ/A1H, RZ/Five, RZ/G2{L,LC,UL}, RZ/V2L, and RZ/G3S SoCs, the cell
> > > > > > > > > > > +      specifies the encoded MID/RID values of the DMAC port connected to the
> > > > > > > > > > > +      DMA client and the slave channel configuration parameters.
> > > > > > > > > > >        bits[0:9] - Specifies MID/RID value
> > > > > > > > > > >        bit[10] - Specifies DMA request high enable (HIEN)
> > > > > > > > > > >        bit[11] - Specifies DMA request detection type (LVL)
> > > > > > > > > > >        bits[12:14] - Specifies DMAACK output mode (AM)
> > > > > > > > > > >        bit[15] - Specifies Transfer Mode (TM)
> > > > > > > > > > > +      For the RZ/V2H(P) SoC the cell specifies the REQ NO, the ACK NO, and the
> > > > > > > > > > > +      slave channel configuration parameters.
> > > > > > > > > > > +      bits[0:9] - Specifies the REQ NO
> > > > > > > > > >
> > > > > > > > > > So REQ_NO is the new name for MID/RID.
> > > > > > > >
> > > > > > > > These are documented in Table 4.7-22 ("DMA Transfer Request Detection
> > > > > > > > Operation Setting Table").
> > > > > > >
> > > > > > > REQ_NO is documented in both Table 4.7-22 and in Table 4.6-23 (column `DMAC No.`).
> > > > > >
> > > > > > Indeed. But not for all of them. E.g. RSPI is missing, IIC is present.
> > > > >
> > > > > I can see the RSPI related `REQ No.` in the version of the manual I am using,
> > > > > although one must be very careful to look at the right entry in the table,
> > > > > as the table is quite big, and the entries are ordered by `SPI No.`.
> > > > >
> > > > > For some devices, the SPI numbers are not contiguous therefore the device specific
> > > > > bits may end up scattered.
> > > > > For example, for `Name` `RSPI_CH0_sp_rxintpls_n` (mind that the `pls_n` substring
> > > > > is on a new line in the table) you can see from Table 4.6-23 that
> > > > > its `DMAC No.` is 140 (as you said, in decimal...).
> > > >
> > > > Thanks, I had missed it because the RSPI interrupts are spread across
> > > > two places...
> > > >
> > > > > > And the numbers are shown in decimal instead of in hex ;-)
> > > > > >
> > > > > > > > > It's certainly similar. I would say that REQ_NO + ACK_NO is the new MID_RID.
> > > > > > > > >
> > > > > > > > > > > +      bits[10:16] - Specifies the ACK NO
> > > > > > > > > >
> > > > > > > > > > This is a new field.
> > > > > > > > > > However, it is not clear to me which value to specify here, and if this
> > > > > > > > > > is a hardware property at all, and thus needs to be specified in DT?
> > > > > > > > >
> > > > > > > > > It is a HW property. The value to set can be found in Table 4.6-27 from
> > > > > > > > > the HW User Manual, column "Ack No".
> > > > > > > >
> > > > > > > > Thanks, but that table only shows values for SPDIF, SCU, SSIU and PFC
> > > > > > > > (for external DMA requests).  The most familiar DMA clients listed
> > > > > > > > in Table 4.7-22 are missing.  E.g. RSPI0 uses REQ_NO 0x8C/0x8D, but
> > > > > > > > which values does it need for ACK_NO?
> > > > > > >
> > > > > > > Only a handful of devices need it. For every other device (and use case) only the
> > > > > > > default value is needed.
> > > > > >
> > > > > > The default value is RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f?
> > > >
> > > > If you take this out, how to distinguish between ACK_NO = 0 and
> > > > the default?
> > >
> > > I am not sure I understand what you mean, so my answer here may be completely off.
> > >
> > > ACK No. 0 corresponds to SPDIF, CH0, TX, while ACK No. 0x7F is not valid.
> >
> > OK, that was my understanding, too.
> >
> > > My understanding of this is that there is a DACK_SEL field per ACK No (23 ICU_DMACKSELk
> > > registers, 4 DACK_SEL fields per ICU_DMACKSELk registers -> 23 * 4 = 92 DACK_SEL fields),
> > > to match the 92 ACK numbers listed in Table 4.6-27.
> > >
> > > Each DACK_SEL field should contain the global channel index (5 DMACs, 16 channels per DMAC
> > > -> 5 * 16 = 80 channels in total) associated to the ACK No.
> > > If DACK_SEL contains a valid channel number (0-79), then the corresponding signal
> > > gets controlled accordingly, otherwise a fixed output is generated instead.
> > >
> > > Mind that the code I sent wasn't dealing with it properly, but wasn't spotted due
> > > to limited testing capabilities, and it's safe to take out, as the DACK_SEL fields
> > > will all contain invalid channel numbers by default.
> > >
> > > Looking ahead, there is a similar scenario with the TEND signals as well.
> > >
> > > So for now the plan is to upstream support for memory/memory and device/memory (REQ No.,
> > > tested with RSPI), add support for ACK No later (perhaps testing it with audio, or via
> > > an external device), and finally TEND No if we get to it.
> >
> > So which values will you put in the dmas property for RSPI?
> > I assume:
> >        bits[0:9] - Specifies REQ_NO value
> >        bit[10] - Specifies DMA request high enable (HIEN)
> >        bit[11] - Specifies DMA request detection type (LVL)
> >        bits[12:14] - Specifies DMAACK output mode (AM)
> >        bit[15] - Specifies Transfer Mode (TM)

I will switch to this layout for the next version.

> > i.e. all remaining bits will be zero?
> 
> I see what you mean now. And there would be an ABI mismatch between older DTs and newer kernels,
> newer kernels would interpret the values incorrectly (as you said, 0 is a valid number).
> 
> >
> > How do you plan to handle adding ACK_NO bits later?
> > I.e. how to distinguish between remaining bits zero and remaining
> > bits containing a valid ACK_NO value (which can be zero, for SPDIF)?
> 
> We could add the ACK No. and the TEND No. to the binding (after TM), and implement it
> later in the driver (once we have some practical use case for them)?
> 
> There are also a couple of alternatives:
> * we could add 1 to ACK No. and TEND No.? At that point 0 would be an invalid number?
>   In which case we could add DT and driver support later?
> * we could fill up the remaining bits with 1s? We only have 5 TEND numbers, so 0b111 would
>   be invalid. Similarly, we have 92 ACK numbers, so 0b1111111 would also be invalid. Also
>   this shouldn't break the ABIs once we get around to add the rest?

Considering that `ACK No.` and `TEND No`. are uniquely paired to `REQ No.`, I think we can
omit them from the DT, and just look them up from a table in the corresponding driver, and
we should be good to go.

Thanks!

Fab

> 
> >
> > I hope I made myself clear this time.
> 
> Very clear! Thank you.
> 
> > If not, weekend time ;-)
> >
> > Have a nice weekend!
> 
> Thank you, and you!
> 
> Cheers,
> Fab
> 
> >
> > Gr{oetje,eeting}s,
> >
> >                         Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> >                                 -- Linus Torvalds