* [PATCH v4 1/7] clk: renesas: r9a09g057: Add entries for the DMACs
2025-02-20 15:01 [PATCH v4 0/7] Add DMAC support to the RZ/V2H(P) Fabrizio Castro
@ 2025-02-20 15:01 ` Fabrizio Castro
2025-02-21 20:45 ` Lad, Prabhakar
2025-02-24 10:50 ` Geert Uytterhoeven
2025-02-20 15:01 ` [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H Fabrizio Castro
` (5 subsequent siblings)
6 siblings, 2 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-20 15:01 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Geert Uytterhoeven
Cc: Fabrizio Castro, linux-renesas-soc, linux-clk, linux-kernel,
Biju Das, Lad Prabhakar
Add clock and reset entries for the Renesas RZ/V2H(P) DMAC IPs.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
v3->v4:
* No change.
v2->v3:
* No change.
v1->v2:
* No change.
---
drivers/clk/renesas/r9a09g057-cpg.c | 24 ++++++++++++++++++++++++
drivers/clk/renesas/rzv2h-cpg.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/clk/renesas/r9a09g057-cpg.c b/drivers/clk/renesas/r9a09g057-cpg.c
index 3705e18f66ad..d63eafbca780 100644
--- a/drivers/clk/renesas/r9a09g057-cpg.c
+++ b/drivers/clk/renesas/r9a09g057-cpg.c
@@ -31,6 +31,8 @@ enum clk_ids {
CLK_PLLVDO,
/* Internal Core Clocks */
+ CLK_PLLCM33_DIV4,
+ CLK_PLLCM33_DIV4_PLLCM33,
CLK_PLLCM33_DIV16,
CLK_PLLCLN_DIV2,
CLK_PLLCLN_DIV8,
@@ -39,6 +41,8 @@ enum clk_ids {
CLK_PLLDTY_ACPU_DIV2,
CLK_PLLDTY_ACPU_DIV4,
CLK_PLLDTY_DIV16,
+ CLK_PLLDTY_RCPU,
+ CLK_PLLDTY_RCPU_DIV4,
CLK_PLLVDO_CRU0,
CLK_PLLVDO_CRU1,
CLK_PLLVDO_CRU2,
@@ -85,6 +89,9 @@ static const struct cpg_core_clk r9a09g057_core_clks[] __initconst = {
DEF_FIXED(".pllvdo", CLK_PLLVDO, CLK_QEXTAL, 105, 2),
/* Internal Core Clocks */
+ DEF_FIXED(".pllcm33_div4", CLK_PLLCM33_DIV4, CLK_PLLCM33, 1, 4),
+ DEF_DDIV(".pllcm33_div4_pllcm33", CLK_PLLCM33_DIV4_PLLCM33,
+ CLK_PLLCM33_DIV4, CDDIV0_DIVCTL1, dtable_2_64),
DEF_FIXED(".pllcm33_div16", CLK_PLLCM33_DIV16, CLK_PLLCM33, 1, 16),
DEF_FIXED(".pllcln_div2", CLK_PLLCLN_DIV2, CLK_PLLCLN, 1, 2),
@@ -95,6 +102,8 @@ static const struct cpg_core_clk r9a09g057_core_clks[] __initconst = {
DEF_FIXED(".plldty_acpu_div2", CLK_PLLDTY_ACPU_DIV2, CLK_PLLDTY_ACPU, 1, 2),
DEF_FIXED(".plldty_acpu_div4", CLK_PLLDTY_ACPU_DIV4, CLK_PLLDTY_ACPU, 1, 4),
DEF_FIXED(".plldty_div16", CLK_PLLDTY_DIV16, CLK_PLLDTY, 1, 16),
+ DEF_DDIV(".plldty_rcpu", CLK_PLLDTY_RCPU, CLK_PLLDTY, CDDIV3_DIVCTL2, dtable_2_64),
+ DEF_FIXED(".plldty_rcpu_div4", CLK_PLLDTY_RCPU_DIV4, CLK_PLLDTY_RCPU, 1, 4),
DEF_DDIV(".pllvdo_cru0", CLK_PLLVDO_CRU0, CLK_PLLVDO, CDDIV3_DIVCTL3, dtable_2_4),
DEF_DDIV(".pllvdo_cru1", CLK_PLLVDO_CRU1, CLK_PLLVDO, CDDIV4_DIVCTL0, dtable_2_4),
@@ -115,6 +124,16 @@ static const struct cpg_core_clk r9a09g057_core_clks[] __initconst = {
};
static const struct rzv2h_mod_clk r9a09g057_mod_clks[] __initconst = {
+ DEF_MOD("dmac_0_aclk", CLK_PLLCM33_DIV4_PLLCM33, 0, 0, 0, 0,
+ BUS_MSTOP(5, BIT(9))),
+ DEF_MOD("dmac_1_aclk", CLK_PLLDTY_ACPU_DIV2, 0, 1, 0, 1,
+ BUS_MSTOP(3, BIT(2))),
+ DEF_MOD("dmac_2_aclk", CLK_PLLDTY_ACPU_DIV2, 0, 2, 0, 2,
+ BUS_MSTOP(3, BIT(3))),
+ DEF_MOD("dmac_3_aclk", CLK_PLLDTY_RCPU_DIV4, 0, 3, 0, 3,
+ BUS_MSTOP(10, BIT(11))),
+ DEF_MOD("dmac_4_aclk", CLK_PLLDTY_RCPU_DIV4, 0, 4, 0, 4,
+ BUS_MSTOP(10, BIT(12))),
DEF_MOD_CRITICAL("icu_0_pclk_i", CLK_PLLCM33_DIV16, 0, 5, 0, 5,
BUS_MSTOP_NONE),
DEF_MOD_CRITICAL("gic_0_gicclk", CLK_PLLDTY_ACPU_DIV4, 1, 3, 0, 19,
@@ -223,6 +242,11 @@ static const struct rzv2h_mod_clk r9a09g057_mod_clks[] __initconst = {
static const struct rzv2h_reset r9a09g057_resets[] __initconst = {
DEF_RST(3, 0, 1, 1), /* SYS_0_PRESETN */
+ DEF_RST(3, 1, 1, 2), /* DMAC_0_ARESETN */
+ DEF_RST(3, 2, 1, 3), /* DMAC_1_ARESETN */
+ DEF_RST(3, 3, 1, 4), /* DMAC_2_ARESETN */
+ DEF_RST(3, 4, 1, 5), /* DMAC_3_ARESETN */
+ DEF_RST(3, 5, 1, 6), /* DMAC_4_ARESETN */
DEF_RST(3, 6, 1, 7), /* ICU_0_PRESETN_I */
DEF_RST(3, 8, 1, 9), /* GIC_0_GICRESET_N */
DEF_RST(3, 9, 1, 10), /* GIC_0_DBG_GICRESET_N */
diff --git a/drivers/clk/renesas/rzv2h-cpg.h b/drivers/clk/renesas/rzv2h-cpg.h
index fd8eb985c75b..576a070763cb 100644
--- a/drivers/clk/renesas/rzv2h-cpg.h
+++ b/drivers/clk/renesas/rzv2h-cpg.h
@@ -38,11 +38,13 @@ struct ddiv {
#define CPG_CDDIV3 (0x40C)
#define CPG_CDDIV4 (0x410)
+#define CDDIV0_DIVCTL1 DDIV_PACK(CPG_CDDIV0, 4, 3, 1)
#define CDDIV0_DIVCTL2 DDIV_PACK(CPG_CDDIV0, 8, 3, 2)
#define CDDIV1_DIVCTL0 DDIV_PACK(CPG_CDDIV1, 0, 2, 4)
#define CDDIV1_DIVCTL1 DDIV_PACK(CPG_CDDIV1, 4, 2, 5)
#define CDDIV1_DIVCTL2 DDIV_PACK(CPG_CDDIV1, 8, 2, 6)
#define CDDIV1_DIVCTL3 DDIV_PACK(CPG_CDDIV1, 12, 2, 7)
+#define CDDIV3_DIVCTL2 DDIV_PACK(CPG_CDDIV3, 8, 3, 14)
#define CDDIV3_DIVCTL3 DDIV_PACK(CPG_CDDIV3, 12, 1, 15)
#define CDDIV4_DIVCTL0 DDIV_PACK(CPG_CDDIV4, 0, 1, 16)
#define CDDIV4_DIVCTL1 DDIV_PACK(CPG_CDDIV4, 4, 1, 17)
--
2.34.1
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v4 1/7] clk: renesas: r9a09g057: Add entries for the DMACs
2025-02-20 15:01 ` [PATCH v4 1/7] clk: renesas: r9a09g057: Add entries for the DMACs Fabrizio Castro
@ 2025-02-21 20:45 ` Lad, Prabhakar
2025-02-24 10:50 ` Geert Uytterhoeven
1 sibling, 0 replies; 37+ messages in thread
From: Lad, Prabhakar @ 2025-02-21 20:45 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Michael Turquette, Stephen Boyd, Geert Uytterhoeven,
linux-renesas-soc, linux-clk, linux-kernel, Biju Das,
Lad Prabhakar
On Thu, Feb 20, 2025 at 3:03 PM Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
>
> Add clock and reset entries for the Renesas RZ/V2H(P) DMAC IPs.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> v3->v4:
> * No change.
> v2->v3:
> * No change.
> v1->v2:
> * No change.
> ---
> drivers/clk/renesas/r9a09g057-cpg.c | 24 ++++++++++++++++++++++++
> drivers/clk/renesas/rzv2h-cpg.h | 2 ++
> 2 files changed, 26 insertions(+)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cheers,
Prabhakar
> diff --git a/drivers/clk/renesas/r9a09g057-cpg.c b/drivers/clk/renesas/r9a09g057-cpg.c
> index 3705e18f66ad..d63eafbca780 100644
> --- a/drivers/clk/renesas/r9a09g057-cpg.c
> +++ b/drivers/clk/renesas/r9a09g057-cpg.c
> @@ -31,6 +31,8 @@ enum clk_ids {
> CLK_PLLVDO,
>
> /* Internal Core Clocks */
> + CLK_PLLCM33_DIV4,
> + CLK_PLLCM33_DIV4_PLLCM33,
> CLK_PLLCM33_DIV16,
> CLK_PLLCLN_DIV2,
> CLK_PLLCLN_DIV8,
> @@ -39,6 +41,8 @@ enum clk_ids {
> CLK_PLLDTY_ACPU_DIV2,
> CLK_PLLDTY_ACPU_DIV4,
> CLK_PLLDTY_DIV16,
> + CLK_PLLDTY_RCPU,
> + CLK_PLLDTY_RCPU_DIV4,
> CLK_PLLVDO_CRU0,
> CLK_PLLVDO_CRU1,
> CLK_PLLVDO_CRU2,
> @@ -85,6 +89,9 @@ static const struct cpg_core_clk r9a09g057_core_clks[] __initconst = {
> DEF_FIXED(".pllvdo", CLK_PLLVDO, CLK_QEXTAL, 105, 2),
>
> /* Internal Core Clocks */
> + DEF_FIXED(".pllcm33_div4", CLK_PLLCM33_DIV4, CLK_PLLCM33, 1, 4),
> + DEF_DDIV(".pllcm33_div4_pllcm33", CLK_PLLCM33_DIV4_PLLCM33,
> + CLK_PLLCM33_DIV4, CDDIV0_DIVCTL1, dtable_2_64),
> DEF_FIXED(".pllcm33_div16", CLK_PLLCM33_DIV16, CLK_PLLCM33, 1, 16),
>
> DEF_FIXED(".pllcln_div2", CLK_PLLCLN_DIV2, CLK_PLLCLN, 1, 2),
> @@ -95,6 +102,8 @@ static const struct cpg_core_clk r9a09g057_core_clks[] __initconst = {
> DEF_FIXED(".plldty_acpu_div2", CLK_PLLDTY_ACPU_DIV2, CLK_PLLDTY_ACPU, 1, 2),
> DEF_FIXED(".plldty_acpu_div4", CLK_PLLDTY_ACPU_DIV4, CLK_PLLDTY_ACPU, 1, 4),
> DEF_FIXED(".plldty_div16", CLK_PLLDTY_DIV16, CLK_PLLDTY, 1, 16),
> + DEF_DDIV(".plldty_rcpu", CLK_PLLDTY_RCPU, CLK_PLLDTY, CDDIV3_DIVCTL2, dtable_2_64),
> + DEF_FIXED(".plldty_rcpu_div4", CLK_PLLDTY_RCPU_DIV4, CLK_PLLDTY_RCPU, 1, 4),
>
> DEF_DDIV(".pllvdo_cru0", CLK_PLLVDO_CRU0, CLK_PLLVDO, CDDIV3_DIVCTL3, dtable_2_4),
> DEF_DDIV(".pllvdo_cru1", CLK_PLLVDO_CRU1, CLK_PLLVDO, CDDIV4_DIVCTL0, dtable_2_4),
> @@ -115,6 +124,16 @@ static const struct cpg_core_clk r9a09g057_core_clks[] __initconst = {
> };
>
> static const struct rzv2h_mod_clk r9a09g057_mod_clks[] __initconst = {
> + DEF_MOD("dmac_0_aclk", CLK_PLLCM33_DIV4_PLLCM33, 0, 0, 0, 0,
> + BUS_MSTOP(5, BIT(9))),
> + DEF_MOD("dmac_1_aclk", CLK_PLLDTY_ACPU_DIV2, 0, 1, 0, 1,
> + BUS_MSTOP(3, BIT(2))),
> + DEF_MOD("dmac_2_aclk", CLK_PLLDTY_ACPU_DIV2, 0, 2, 0, 2,
> + BUS_MSTOP(3, BIT(3))),
> + DEF_MOD("dmac_3_aclk", CLK_PLLDTY_RCPU_DIV4, 0, 3, 0, 3,
> + BUS_MSTOP(10, BIT(11))),
> + DEF_MOD("dmac_4_aclk", CLK_PLLDTY_RCPU_DIV4, 0, 4, 0, 4,
> + BUS_MSTOP(10, BIT(12))),
> DEF_MOD_CRITICAL("icu_0_pclk_i", CLK_PLLCM33_DIV16, 0, 5, 0, 5,
> BUS_MSTOP_NONE),
> DEF_MOD_CRITICAL("gic_0_gicclk", CLK_PLLDTY_ACPU_DIV4, 1, 3, 0, 19,
> @@ -223,6 +242,11 @@ static const struct rzv2h_mod_clk r9a09g057_mod_clks[] __initconst = {
>
> static const struct rzv2h_reset r9a09g057_resets[] __initconst = {
> DEF_RST(3, 0, 1, 1), /* SYS_0_PRESETN */
> + DEF_RST(3, 1, 1, 2), /* DMAC_0_ARESETN */
> + DEF_RST(3, 2, 1, 3), /* DMAC_1_ARESETN */
> + DEF_RST(3, 3, 1, 4), /* DMAC_2_ARESETN */
> + DEF_RST(3, 4, 1, 5), /* DMAC_3_ARESETN */
> + DEF_RST(3, 5, 1, 6), /* DMAC_4_ARESETN */
> DEF_RST(3, 6, 1, 7), /* ICU_0_PRESETN_I */
> DEF_RST(3, 8, 1, 9), /* GIC_0_GICRESET_N */
> DEF_RST(3, 9, 1, 10), /* GIC_0_DBG_GICRESET_N */
> diff --git a/drivers/clk/renesas/rzv2h-cpg.h b/drivers/clk/renesas/rzv2h-cpg.h
> index fd8eb985c75b..576a070763cb 100644
> --- a/drivers/clk/renesas/rzv2h-cpg.h
> +++ b/drivers/clk/renesas/rzv2h-cpg.h
> @@ -38,11 +38,13 @@ struct ddiv {
> #define CPG_CDDIV3 (0x40C)
> #define CPG_CDDIV4 (0x410)
>
> +#define CDDIV0_DIVCTL1 DDIV_PACK(CPG_CDDIV0, 4, 3, 1)
> #define CDDIV0_DIVCTL2 DDIV_PACK(CPG_CDDIV0, 8, 3, 2)
> #define CDDIV1_DIVCTL0 DDIV_PACK(CPG_CDDIV1, 0, 2, 4)
> #define CDDIV1_DIVCTL1 DDIV_PACK(CPG_CDDIV1, 4, 2, 5)
> #define CDDIV1_DIVCTL2 DDIV_PACK(CPG_CDDIV1, 8, 2, 6)
> #define CDDIV1_DIVCTL3 DDIV_PACK(CPG_CDDIV1, 12, 2, 7)
> +#define CDDIV3_DIVCTL2 DDIV_PACK(CPG_CDDIV3, 8, 3, 14)
> #define CDDIV3_DIVCTL3 DDIV_PACK(CPG_CDDIV3, 12, 1, 15)
> #define CDDIV4_DIVCTL0 DDIV_PACK(CPG_CDDIV4, 0, 1, 16)
> #define CDDIV4_DIVCTL1 DDIV_PACK(CPG_CDDIV4, 4, 1, 17)
> --
> 2.34.1
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 1/7] clk: renesas: r9a09g057: Add entries for the DMACs
2025-02-20 15:01 ` [PATCH v4 1/7] clk: renesas: r9a09g057: Add entries for the DMACs Fabrizio Castro
2025-02-21 20:45 ` Lad, Prabhakar
@ 2025-02-24 10:50 ` Geert Uytterhoeven
1 sibling, 0 replies; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-24 10:50 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Michael Turquette, Stephen Boyd, linux-renesas-soc, linux-clk,
linux-kernel, Biju Das, Lad Prabhakar
On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> Add clock and reset entries for the Renesas RZ/V2H(P) DMAC IPs.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v6.15.
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H
2025-02-20 15:01 [PATCH v4 0/7] Add DMAC support to the RZ/V2H(P) Fabrizio Castro
2025-02-20 15:01 ` [PATCH v4 1/7] clk: renesas: r9a09g057: Add entries for the DMACs Fabrizio Castro
@ 2025-02-20 15:01 ` Fabrizio Castro
2025-02-21 17:43 ` Conor Dooley
` (2 more replies)
2025-02-20 15:01 ` [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs Fabrizio Castro
` (4 subsequent siblings)
6 siblings, 3 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-20 15:01 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven
Cc: Fabrizio Castro, Magnus Damm, Biju Das, Wolfram Sang, dmaengine,
devicetree, linux-kernel, linux-renesas-soc, Lad Prabhakar
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
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H
2025-02-20 15:01 ` [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H Fabrizio Castro
@ 2025-02-21 17:43 ` Conor Dooley
2025-02-21 20:48 ` Lad, Prabhakar
2025-02-24 12:33 ` Geert Uytterhoeven
2 siblings, 0 replies; 37+ messages in thread
From: Conor Dooley @ 2025-02-21 17:43 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, Wolfram Sang,
dmaengine, devicetree, linux-kernel, linux-renesas-soc,
Lad Prabhakar
[-- 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H
2025-02-20 15:01 ` [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H Fabrizio Castro
2025-02-21 17:43 ` Conor Dooley
@ 2025-02-21 20:48 ` Lad, Prabhakar
2025-02-24 12:33 ` Geert Uytterhoeven
2 siblings, 0 replies; 37+ messages in thread
From: Lad, Prabhakar @ 2025-02-21 20:48 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, Wolfram Sang,
dmaengine, devicetree, linux-kernel, linux-renesas-soc,
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
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H
2025-02-20 15:01 ` [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H Fabrizio Castro
2025-02-21 17:43 ` Conor Dooley
2025-02-21 20:48 ` Lad, Prabhakar
@ 2025-02-24 12:33 ` Geert Uytterhoeven
2 siblings, 0 replies; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-24 12:33 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, Wolfram Sang,
dmaengine, devicetree, linux-kernel, linux-renesas-soc,
Lad Prabhakar
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-20 15:01 [PATCH v4 0/7] Add DMAC support to the RZ/V2H(P) Fabrizio Castro
2025-02-20 15:01 ` [PATCH v4 1/7] clk: renesas: r9a09g057: Add entries for the DMACs Fabrizio Castro
2025-02-20 15:01 ` [PATCH v4 2/7] dt-bindings: dma: rz-dmac: Restrict properties for RZ/A1H Fabrizio Castro
@ 2025-02-20 15:01 ` Fabrizio Castro
2025-02-21 17:44 ` Conor Dooley
` (2 more replies)
2025-02-20 15:01 ` [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack() Fabrizio Castro
` (3 subsequent siblings)
6 siblings, 3 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-20 15:01 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven
Cc: Fabrizio Castro, Magnus Damm, Biju Das, dmaengine, devicetree,
linux-kernel, linux-renesas-soc, Lad Prabhakar
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
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-20 15:01 ` [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs Fabrizio Castro
@ 2025-02-21 17:44 ` Conor Dooley
2025-02-21 20:55 ` Lad, Prabhakar
2025-02-24 12:43 ` Geert Uytterhoeven
2 siblings, 0 replies; 37+ messages in thread
From: Conor Dooley @ 2025-02-21 17:44 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, dmaengine, devicetree,
linux-kernel, linux-renesas-soc, Lad Prabhakar
[-- 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-20 15:01 ` [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs Fabrizio Castro
2025-02-21 17:44 ` Conor Dooley
@ 2025-02-21 20:55 ` Lad, Prabhakar
2025-02-24 12:43 ` Geert Uytterhoeven
2 siblings, 0 replies; 37+ messages in thread
From: Lad, Prabhakar @ 2025-02-21 20:55 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Biju Das, dmaengine, devicetree,
linux-kernel, linux-renesas-soc, 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
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-20 15:01 ` [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs Fabrizio Castro
2025-02-21 17:44 ` Conor Dooley
2025-02-21 20:55 ` Lad, Prabhakar
@ 2025-02-24 12:43 ` Geert Uytterhoeven
2025-02-27 18:16 ` Fabrizio Castro
2 siblings, 1 reply; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-24 12:43 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine, devicetree, linux-kernel,
linux-renesas-soc, Lad Prabhakar
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-24 12:43 ` Geert Uytterhoeven
@ 2025-02-27 18:16 ` Fabrizio Castro
2025-02-28 10:17 ` Geert Uytterhoeven
0 siblings, 1 reply; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-27 18:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-27 18:16 ` Fabrizio Castro
@ 2025-02-28 10:17 ` Geert Uytterhoeven
2025-02-28 14:55 ` Fabrizio Castro
0 siblings, 1 reply; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-28 10:17 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 10:17 ` Geert Uytterhoeven
@ 2025-02-28 14:55 ` Fabrizio Castro
2025-02-28 15:16 ` Geert Uytterhoeven
0 siblings, 1 reply; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-28 14:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 14:55 ` Fabrizio Castro
@ 2025-02-28 15:16 ` Geert Uytterhoeven
2025-02-28 15:38 ` Fabrizio Castro
0 siblings, 1 reply; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-28 15:16 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 15:16 ` Geert Uytterhoeven
@ 2025-02-28 15:38 ` Fabrizio Castro
2025-02-28 15:56 ` Geert Uytterhoeven
0 siblings, 1 reply; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-28 15:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 15:38 ` Fabrizio Castro
@ 2025-02-28 15:56 ` Geert Uytterhoeven
2025-02-28 16:32 ` Fabrizio Castro
0 siblings, 1 reply; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-28 15:56 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 15:56 ` Geert Uytterhoeven
@ 2025-02-28 16:32 ` Fabrizio Castro
2025-02-28 16:43 ` Geert Uytterhoeven
0 siblings, 1 reply; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-28 16:32 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 16:32 ` Fabrizio Castro
@ 2025-02-28 16:43 ` Geert Uytterhoeven
2025-02-28 17:28 ` Fabrizio Castro
0 siblings, 1 reply; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-28 16:43 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 16:43 ` Geert Uytterhoeven
@ 2025-02-28 17:28 ` Fabrizio Castro
2025-03-04 15:02 ` Fabrizio Castro
0 siblings, 1 reply; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-28 17:28 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs
2025-02-28 17:28 ` Fabrizio Castro
@ 2025-03-04 15:02 ` Fabrizio Castro
0 siblings, 0 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-03-04 15:02 UTC (permalink / raw)
To: Fabrizio Castro, Geert Uytterhoeven
Cc: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Biju Das, dmaengine@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack()
2025-02-20 15:01 [PATCH v4 0/7] Add DMAC support to the RZ/V2H(P) Fabrizio Castro
` (2 preceding siblings ...)
2025-02-20 15:01 ` [PATCH v4 3/7] dt-bindings: dma: rz-dmac: Document RZ/V2H(P) family of SoCs Fabrizio Castro
@ 2025-02-20 15:01 ` Fabrizio Castro
2025-02-21 21:05 ` Lad, Prabhakar
2025-02-24 12:59 ` Geert Uytterhoeven
2025-02-20 15:01 ` [PATCH v4 5/7] dmaengine: sh: rz-dmac: Allow for multiple DMACs Fabrizio Castro
` (2 subsequent siblings)
6 siblings, 2 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-20 15:01 UTC (permalink / raw)
To: Thomas Gleixner, Geert Uytterhoeven
Cc: Fabrizio Castro, linux-kernel, Biju Das, Lad Prabhakar,
linux-renesas-soc
On the Renesas RZ/V2H(P) family of SoCs, DMAC IPs are connected
to the Interrupt Control Unit (ICU).
For DMA transfers, a request number and an ack number must be
registered with the ICU, which means that the DMAC driver has
to be able to instruct the ICU driver with the registration of
such ids.
Export rzv2h_icu_register_dma_req_ack() so that the DMA driver
can register both ids in one go.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
---
v3->v4:
* No change.
v2->v3:
* Replaced rzv2h_icu_register_dma_req_ack with
rzv2h_icu_register_dma_req_ack() in changelog.
* Added dummy for rzv2h_icu_register_dma_req_ack().
* Added Rb Thomas.
v1->v2:
* Improved macros.
* Shared new macros for minimum values.
---
drivers/irqchip/irq-renesas-rzv2h.c | 56 +++++++++++++++++++++++
include/linux/irqchip/irq-renesas-rzv2h.h | 26 +++++++++++
2 files changed, 82 insertions(+)
create mode 100644 include/linux/irqchip/irq-renesas-rzv2h.h
diff --git a/drivers/irqchip/irq-renesas-rzv2h.c b/drivers/irqchip/irq-renesas-rzv2h.c
index fe2d29e91026..a8e9feda73b0 100644
--- a/drivers/irqchip/irq-renesas-rzv2h.c
+++ b/drivers/irqchip/irq-renesas-rzv2h.c
@@ -15,6 +15,7 @@
#include <linux/err.h>
#include <linux/io.h>
#include <linux/irqchip.h>
+#include <linux/irqchip/irq-renesas-rzv2h.h>
#include <linux/irqdomain.h>
#include <linux/of_address.h>
#include <linux/of_platform.h>
@@ -41,6 +42,8 @@
#define ICU_TSCLR 0x24
#define ICU_TITSR(k) (0x28 + (k) * 4)
#define ICU_TSSR(k) (0x30 + (k) * 4)
+#define ICU_DMkSELy(k, y) (0x420 + (k) * 0x20 + (y) * 4)
+#define ICU_DMACKSELk(k) (0x500 + (k) * 4)
/* NMI */
#define ICU_NMI_EDGE_FALLING 0
@@ -80,6 +83,19 @@
#define ICU_TINT_EXTRACT_GPIOINT(x) FIELD_GET(GENMASK(31, 16), (x))
#define ICU_PB5_TINT 0x55
+/* DMAC */
+#define ICU_DMAC_DkRQ_SEL_MASK GENMASK(9, 0)
+
+#define ICU_DMAC_DMAREQ_SHIFT(up) ((up) * 16)
+#define ICU_DMAC_DMAREQ_MASK(up) (ICU_DMAC_DkRQ_SEL_MASK \
+ << ICU_DMAC_DMAREQ_SHIFT(up))
+#define ICU_DMAC_PREP_DMAREQ(sel, up) (FIELD_PREP(ICU_DMAC_DkRQ_SEL_MASK, (sel)) \
+ << ICU_DMAC_DMAREQ_SHIFT(up))
+
+#define ICU_DMAC_DACK_SEL_SHIFT(field_no) ((field_no) * 8)
+#define ICU_DMAC_DACK_SEL_MASK(field_no) (GENMASK(6, 0) << ICU_DMAC_DACK_SEL_SHIFT(field_no))
+#define ICU_DMAC_PREP_DACK_SEL(sel, field_no) ((sel) << ICU_DMAC_DACK_SEL_SHIFT(field_no))
+
/**
* struct rzv2h_icu_priv - Interrupt Control Unit controller private data structure.
* @base: Controller's base address
@@ -94,6 +110,45 @@ struct rzv2h_icu_priv {
raw_spinlock_t lock;
};
+void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index, u8 dmac_channel,
+ u16 req_no, u8 ack_no)
+{
+ struct rzv2h_icu_priv *priv = platform_get_drvdata(icu_dev);
+ u32 icu_dmackselk, dmaack, dmaack_mask;
+ u32 icu_dmksely, dmareq, dmareq_mask;
+ u8 k, field_no;
+ u8 y, upper;
+
+ if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
+ req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
+
+ if (ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
+ ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
+
+ y = dmac_channel / 2;
+ upper = dmac_channel % 2;
+
+ dmareq = ICU_DMAC_PREP_DMAREQ(req_no, upper);
+ dmareq_mask = ICU_DMAC_DMAREQ_MASK(upper);
+
+ k = ack_no / 4;
+ field_no = ack_no % 4;
+
+ dmaack_mask = ICU_DMAC_DACK_SEL_MASK(field_no);
+ dmaack = ICU_DMAC_PREP_DACK_SEL(ack_no, field_no);
+
+ guard(raw_spinlock_irqsave)(&priv->lock);
+
+ icu_dmksely = readl(priv->base + ICU_DMkSELy(dmac_index, y));
+ icu_dmksely = (icu_dmksely & ~dmareq_mask) | dmareq;
+ writel(icu_dmksely, priv->base + ICU_DMkSELy(dmac_index, y));
+
+ icu_dmackselk = readl(priv->base + ICU_DMACKSELk(k));
+ icu_dmackselk = (icu_dmackselk & ~dmaack_mask) | dmaack;
+ writel(icu_dmackselk, priv->base + ICU_DMACKSELk(k));
+}
+EXPORT_SYMBOL_GPL(rzv2h_icu_register_dma_req_ack);
+
static inline struct rzv2h_icu_priv *irq_data_to_priv(struct irq_data *data)
{
return data->domain->host_data;
@@ -446,6 +501,7 @@ static int rzv2h_icu_init(struct device_node *node, struct device_node *parent)
goto put_dev;
}
+ platform_set_drvdata(pdev, rzv2h_icu_data);
rzv2h_icu_data->irqchip = &rzv2h_icu_chip;
rzv2h_icu_data->base = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
diff --git a/include/linux/irqchip/irq-renesas-rzv2h.h b/include/linux/irqchip/irq-renesas-rzv2h.h
new file mode 100644
index 000000000000..d06e01bf969b
--- /dev/null
+++ b/include/linux/irqchip/irq-renesas-rzv2h.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Renesas RZ/V2H(P) Interrupt Control Unit (ICU)
+ *
+ * Copyright (C) 2025 Renesas Electronics Corporation.
+ */
+
+#ifndef __LINUX_IRQ_RENESAS_RZV2H
+#define __LINUX_IRQ_RENESAS_RZV2H
+
+#include <linux/platform_device.h>
+
+#define RZV2H_ICU_DMAC_REQ_NO_DEFAULT 0x3ff
+#define RZV2H_ICU_DMAC_ACK_NO_DEFAULT 0x7f
+#define RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT 0x1b5
+#define RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT 0x50
+
+#ifdef CONFIG_RENESAS_RZV2H_ICU
+void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index, u8 dmac_channel,
+ u16 req_no, u8 ack_no);
+#else
+static inline void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index,
+ u8 dmac_channel, u16 req_no, u8 ack_no) { }
+#endif
+
+#endif
--
2.34.1
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack()
2025-02-20 15:01 ` [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack() Fabrizio Castro
@ 2025-02-21 21:05 ` Lad, Prabhakar
2025-02-24 12:59 ` Geert Uytterhoeven
1 sibling, 0 replies; 37+ messages in thread
From: Lad, Prabhakar @ 2025-02-21 21:05 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Thomas Gleixner, Geert Uytterhoeven, linux-kernel, Biju Das,
Lad Prabhakar, linux-renesas-soc
On Thu, Feb 20, 2025 at 3:06 PM Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
>
> On the Renesas RZ/V2H(P) family of SoCs, DMAC IPs are connected
> to the Interrupt Control Unit (ICU).
> For DMA transfers, a request number and an ack number must be
> registered with the ICU, which means that the DMAC driver has
> to be able to instruct the ICU driver with the registration of
> such ids.
>
> Export rzv2h_icu_register_dma_req_ack() so that the DMA driver
> can register both ids in one go.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> v3->v4:
> * No change.
> v2->v3:
> * Replaced rzv2h_icu_register_dma_req_ack with
> rzv2h_icu_register_dma_req_ack() in changelog.
> * Added dummy for rzv2h_icu_register_dma_req_ack().
> * Added Rb Thomas.
> v1->v2:
> * Improved macros.
> * Shared new macros for minimum values.
> ---
> drivers/irqchip/irq-renesas-rzv2h.c | 56 +++++++++++++++++++++++
> include/linux/irqchip/irq-renesas-rzv2h.h | 26 +++++++++++
> 2 files changed, 82 insertions(+)
> create mode 100644 include/linux/irqchip/irq-renesas-rzv2h.h
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cheers,
Prabhakar
> diff --git a/drivers/irqchip/irq-renesas-rzv2h.c b/drivers/irqchip/irq-renesas-rzv2h.c
> index fe2d29e91026..a8e9feda73b0 100644
> --- a/drivers/irqchip/irq-renesas-rzv2h.c
> +++ b/drivers/irqchip/irq-renesas-rzv2h.c
> @@ -15,6 +15,7 @@
> #include <linux/err.h>
> #include <linux/io.h>
> #include <linux/irqchip.h>
> +#include <linux/irqchip/irq-renesas-rzv2h.h>
> #include <linux/irqdomain.h>
> #include <linux/of_address.h>
> #include <linux/of_platform.h>
> @@ -41,6 +42,8 @@
> #define ICU_TSCLR 0x24
> #define ICU_TITSR(k) (0x28 + (k) * 4)
> #define ICU_TSSR(k) (0x30 + (k) * 4)
> +#define ICU_DMkSELy(k, y) (0x420 + (k) * 0x20 + (y) * 4)
> +#define ICU_DMACKSELk(k) (0x500 + (k) * 4)
>
> /* NMI */
> #define ICU_NMI_EDGE_FALLING 0
> @@ -80,6 +83,19 @@
> #define ICU_TINT_EXTRACT_GPIOINT(x) FIELD_GET(GENMASK(31, 16), (x))
> #define ICU_PB5_TINT 0x55
>
> +/* DMAC */
> +#define ICU_DMAC_DkRQ_SEL_MASK GENMASK(9, 0)
> +
> +#define ICU_DMAC_DMAREQ_SHIFT(up) ((up) * 16)
> +#define ICU_DMAC_DMAREQ_MASK(up) (ICU_DMAC_DkRQ_SEL_MASK \
> + << ICU_DMAC_DMAREQ_SHIFT(up))
> +#define ICU_DMAC_PREP_DMAREQ(sel, up) (FIELD_PREP(ICU_DMAC_DkRQ_SEL_MASK, (sel)) \
> + << ICU_DMAC_DMAREQ_SHIFT(up))
> +
> +#define ICU_DMAC_DACK_SEL_SHIFT(field_no) ((field_no) * 8)
> +#define ICU_DMAC_DACK_SEL_MASK(field_no) (GENMASK(6, 0) << ICU_DMAC_DACK_SEL_SHIFT(field_no))
> +#define ICU_DMAC_PREP_DACK_SEL(sel, field_no) ((sel) << ICU_DMAC_DACK_SEL_SHIFT(field_no))
> +
> /**
> * struct rzv2h_icu_priv - Interrupt Control Unit controller private data structure.
> * @base: Controller's base address
> @@ -94,6 +110,45 @@ struct rzv2h_icu_priv {
> raw_spinlock_t lock;
> };
>
> +void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index, u8 dmac_channel,
> + u16 req_no, u8 ack_no)
> +{
> + struct rzv2h_icu_priv *priv = platform_get_drvdata(icu_dev);
> + u32 icu_dmackselk, dmaack, dmaack_mask;
> + u32 icu_dmksely, dmareq, dmareq_mask;
> + u8 k, field_no;
> + u8 y, upper;
> +
> + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> + req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> +
> + if (ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> + ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> +
> + y = dmac_channel / 2;
> + upper = dmac_channel % 2;
> +
> + dmareq = ICU_DMAC_PREP_DMAREQ(req_no, upper);
> + dmareq_mask = ICU_DMAC_DMAREQ_MASK(upper);
> +
> + k = ack_no / 4;
> + field_no = ack_no % 4;
> +
> + dmaack_mask = ICU_DMAC_DACK_SEL_MASK(field_no);
> + dmaack = ICU_DMAC_PREP_DACK_SEL(ack_no, field_no);
> +
> + guard(raw_spinlock_irqsave)(&priv->lock);
> +
> + icu_dmksely = readl(priv->base + ICU_DMkSELy(dmac_index, y));
> + icu_dmksely = (icu_dmksely & ~dmareq_mask) | dmareq;
> + writel(icu_dmksely, priv->base + ICU_DMkSELy(dmac_index, y));
> +
> + icu_dmackselk = readl(priv->base + ICU_DMACKSELk(k));
> + icu_dmackselk = (icu_dmackselk & ~dmaack_mask) | dmaack;
> + writel(icu_dmackselk, priv->base + ICU_DMACKSELk(k));
> +}
> +EXPORT_SYMBOL_GPL(rzv2h_icu_register_dma_req_ack);
> +
> static inline struct rzv2h_icu_priv *irq_data_to_priv(struct irq_data *data)
> {
> return data->domain->host_data;
> @@ -446,6 +501,7 @@ static int rzv2h_icu_init(struct device_node *node, struct device_node *parent)
> goto put_dev;
> }
>
> + platform_set_drvdata(pdev, rzv2h_icu_data);
> rzv2h_icu_data->irqchip = &rzv2h_icu_chip;
>
> rzv2h_icu_data->base = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
> diff --git a/include/linux/irqchip/irq-renesas-rzv2h.h b/include/linux/irqchip/irq-renesas-rzv2h.h
> new file mode 100644
> index 000000000000..d06e01bf969b
> --- /dev/null
> +++ b/include/linux/irqchip/irq-renesas-rzv2h.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Renesas RZ/V2H(P) Interrupt Control Unit (ICU)
> + *
> + * Copyright (C) 2025 Renesas Electronics Corporation.
> + */
> +
> +#ifndef __LINUX_IRQ_RENESAS_RZV2H
> +#define __LINUX_IRQ_RENESAS_RZV2H
> +
> +#include <linux/platform_device.h>
> +
> +#define RZV2H_ICU_DMAC_REQ_NO_DEFAULT 0x3ff
> +#define RZV2H_ICU_DMAC_ACK_NO_DEFAULT 0x7f
> +#define RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT 0x1b5
> +#define RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT 0x50
> +
> +#ifdef CONFIG_RENESAS_RZV2H_ICU
> +void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index, u8 dmac_channel,
> + u16 req_no, u8 ack_no);
> +#else
> +static inline void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index,
> + u8 dmac_channel, u16 req_no, u8 ack_no) { }
> +#endif
> +
> +#endif
> --
> 2.34.1
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread* Re: [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack()
2025-02-20 15:01 ` [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack() Fabrizio Castro
2025-02-21 21:05 ` Lad, Prabhakar
@ 2025-02-24 12:59 ` Geert Uytterhoeven
2025-02-28 14:47 ` Fabrizio Castro
1 sibling, 1 reply; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-24 12:59 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Thomas Gleixner, linux-kernel, Biju Das, Lad Prabhakar,
linux-renesas-soc
Hi Fabrizio,
On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> On the Renesas RZ/V2H(P) family of SoCs, DMAC IPs are connected
> to the Interrupt Control Unit (ICU).
> For DMA transfers, a request number and an ack number must be
> registered with the ICU, which means that the DMAC driver has
> to be able to instruct the ICU driver with the registration of
> such ids.
>
> Export rzv2h_icu_register_dma_req_ack() so that the DMA driver
> can register both ids in one go.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> ---
> v3->v4:
> * No change.
> v2->v3:
> * Replaced rzv2h_icu_register_dma_req_ack with
> rzv2h_icu_register_dma_req_ack() in changelog.
> * Added dummy for rzv2h_icu_register_dma_req_ack().
> * Added Rb Thomas.
Thanks for the update!
> --- a/drivers/irqchip/irq-renesas-rzv2h.c
> +++ b/drivers/irqchip/irq-renesas-rzv2h.c
> @@ -94,6 +110,45 @@ struct rzv2h_icu_priv {
> raw_spinlock_t lock;
> };
>
> +void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index, u8 dmac_channel,
> + u16 req_no, u8 ack_no)
> +{
> + struct rzv2h_icu_priv *priv = platform_get_drvdata(icu_dev);
> + u32 icu_dmackselk, dmaack, dmaack_mask;
> + u32 icu_dmksely, dmareq, dmareq_mask;
> + u8 k, field_no;
> + u8 y, upper;
> +
> + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> + req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
What is the purpose of this check?
The hardware register field size is 10 bits, so I think it is better
to just limit it to 0x3ff.
Checking for RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT means you will have to
update this check when a new SoC supports higher values than 0x1b5.
> +
> + if (ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> + ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
What is the purpose of this check?
There are only 23 DMACKSELk registers, so using
RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f will write beyond the last
register below. And drivers/dma/sh/rz-dmac.c does call this
function with req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT and ack_no =
RZV2H_ICU_DMAC_ACK_NO_DEFAULT...
> +
> + y = dmac_channel / 2;
> + upper = dmac_channel % 2;
> +
> + dmareq = ICU_DMAC_PREP_DMAREQ(req_no, upper);
> + dmareq_mask = ICU_DMAC_DMAREQ_MASK(upper);
> +
> + k = ack_no / 4;
> + field_no = ack_no % 4;
> +
> + dmaack_mask = ICU_DMAC_DACK_SEL_MASK(field_no);
> + dmaack = ICU_DMAC_PREP_DACK_SEL(ack_no, field_no);
> +
> + guard(raw_spinlock_irqsave)(&priv->lock);
> +
> + icu_dmksely = readl(priv->base + ICU_DMkSELy(dmac_index, y));
> + icu_dmksely = (icu_dmksely & ~dmareq_mask) | dmareq;
> + writel(icu_dmksely, priv->base + ICU_DMkSELy(dmac_index, y));
> +
> + icu_dmackselk = readl(priv->base + ICU_DMACKSELk(k));
> + icu_dmackselk = (icu_dmackselk & ~dmaack_mask) | dmaack;
> + writel(icu_dmackselk, priv->base + ICU_DMACKSELk(k));
> +}
> +EXPORT_SYMBOL_GPL(rzv2h_icu_register_dma_req_ack);
> +
> static inline struct rzv2h_icu_priv *irq_data_to_priv(struct irq_data *data)
> {
> return data->domain->host_data;
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack()
2025-02-24 12:59 ` Geert Uytterhoeven
@ 2025-02-28 14:47 ` Fabrizio Castro
0 siblings, 0 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-28 14:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Gleixner, linux-kernel@vger.kernel.org, Biju Das,
Prabhakar Mahadev Lad, linux-renesas-soc@vger.kernel.org
Hi Geert,
Thanks for your feedback!
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 24 February 2025 12:59
> Subject: Re: [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack()
>
> Hi Fabrizio,
>
> On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > On the Renesas RZ/V2H(P) family of SoCs, DMAC IPs are connected
> > to the Interrupt Control Unit (ICU).
> > For DMA transfers, a request number and an ack number must be
> > registered with the ICU, which means that the DMAC driver has
> > to be able to instruct the ICU driver with the registration of
> > such ids.
> >
> > Export rzv2h_icu_register_dma_req_ack() so that the DMA driver
> > can register both ids in one go.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
> > ---
> > v3->v4:
> > * No change.
> > v2->v3:
> > * Replaced rzv2h_icu_register_dma_req_ack with
> > rzv2h_icu_register_dma_req_ack() in changelog.
> > * Added dummy for rzv2h_icu_register_dma_req_ack().
> > * Added Rb Thomas.
>
> Thanks for the update!
>
> > --- a/drivers/irqchip/irq-renesas-rzv2h.c
> > +++ b/drivers/irqchip/irq-renesas-rzv2h.c
>
> > @@ -94,6 +110,45 @@ struct rzv2h_icu_priv {
> > raw_spinlock_t lock;
> > };
> >
> > +void rzv2h_icu_register_dma_req_ack(struct platform_device *icu_dev, u8 dmac_index, u8
> dmac_channel,
> > + u16 req_no, u8 ack_no)
> > +{
> > + struct rzv2h_icu_priv *priv = platform_get_drvdata(icu_dev);
> > + u32 icu_dmackselk, dmaack, dmaack_mask;
> > + u32 icu_dmksely, dmareq, dmareq_mask;
> > + u8 k, field_no;
> > + u8 y, upper;
> > +
> > + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> > + req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
>
> What is the purpose of this check?
This is mainly to standardize the values for fixed outputs.
> The hardware register field size is 10 bits, so I think it is better
> to just limit it to 0x3ff.
> Checking for RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT means you will have to
> update this check when a new SoC supports higher values than 0x1b5.
Or I can take this check out, the caller deals with it anyways.
>
> > +
> > + if (ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> > + ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
>
> What is the purpose of this check?
> There are only 23 DMACKSELk registers, so using
> RZV2H_ICU_DMAC_ACK_NO_DEFAULT = 0x7f will write beyond the last
> register below. And drivers/dma/sh/rz-dmac.c does call this
> function with req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT and ack_no =
> RZV2H_ICU_DMAC_ACK_NO_DEFAULT...
We don’t have everything we need to test ack_no properly in upstream,
yet, that's probably why this wasn't spotted. I am going to drop the
ack_no bits for now, and add them later on once I can test it properly.
I'll rework this patch to deal only with req_no only, and I'll update
the driver patch accordingly.
Thanks!
Fab
>
> > +
> > + y = dmac_channel / 2;
> > + upper = dmac_channel % 2;
> > +
> > + dmareq = ICU_DMAC_PREP_DMAREQ(req_no, upper);
> > + dmareq_mask = ICU_DMAC_DMAREQ_MASK(upper);
> > +
> > + k = ack_no / 4;
> > + field_no = ack_no % 4;
> > +
> > + dmaack_mask = ICU_DMAC_DACK_SEL_MASK(field_no);
> > + dmaack = ICU_DMAC_PREP_DACK_SEL(ack_no, field_no);
> > +
> > + guard(raw_spinlock_irqsave)(&priv->lock);
> > +
> > + icu_dmksely = readl(priv->base + ICU_DMkSELy(dmac_index, y));
> > + icu_dmksely = (icu_dmksely & ~dmareq_mask) | dmareq;
> > + writel(icu_dmksely, priv->base + ICU_DMkSELy(dmac_index, y));
> > +
> > + icu_dmackselk = readl(priv->base + ICU_DMACKSELk(k));
> > + icu_dmackselk = (icu_dmackselk & ~dmaack_mask) | dmaack;
> > + writel(icu_dmackselk, priv->base + ICU_DMACKSELk(k));
> > +}
> > +EXPORT_SYMBOL_GPL(rzv2h_icu_register_dma_req_ack);
> > +
> > static inline struct rzv2h_icu_priv *irq_data_to_priv(struct irq_data *data)
> > {
> > return data->domain->host_data;
>
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v4 5/7] dmaengine: sh: rz-dmac: Allow for multiple DMACs
2025-02-20 15:01 [PATCH v4 0/7] Add DMAC support to the RZ/V2H(P) Fabrizio Castro
` (3 preceding siblings ...)
2025-02-20 15:01 ` [PATCH v4 4/7] irqchip/renesas-rzv2h: Add rzv2h_icu_register_dma_req_ack() Fabrizio Castro
@ 2025-02-20 15:01 ` Fabrizio Castro
2025-02-21 21:25 ` Lad, Prabhakar
2025-02-24 13:00 ` Geert Uytterhoeven
2025-02-20 15:01 ` [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support Fabrizio Castro
2025-02-20 15:01 ` [PATCH v4 7/7] arm64: dts: renesas: r9a09g057: Add DMAC nodes Fabrizio Castro
6 siblings, 2 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-20 15:01 UTC (permalink / raw)
To: Vinod Koul, Geert Uytterhoeven
Cc: Fabrizio Castro, Wolfram Sang, Biju Das, Uwe Kleine-König,
dmaengine, linux-kernel, Lad Prabhakar, linux-renesas-soc
dma_request_channel() calls into __dma_request_channel() with
NULL as value for np, which won't allow for the selection of the
correct DMAC when multiple DMACs are available.
Switch to using __dma_request_channel() directly so that we can
choose the desired DMA for the channel. This is in preparation
of adding DMAC support for the Renesas RZ/V2H(P) and similar SoCs.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
v3->v4:
* No change.
v2->v3:
* Added () for calls in changelog.
v1->v2:
* No change.
---
drivers/dma/sh/rz-dmac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
index 9235db551026..d7a4ce28040b 100644
--- a/drivers/dma/sh/rz-dmac.c
+++ b/drivers/dma/sh/rz-dmac.c
@@ -748,7 +748,8 @@ static struct dma_chan *rz_dmac_of_xlate(struct of_phandle_args *dma_spec,
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- return dma_request_channel(mask, rz_dmac_chan_filter, dma_spec);
+ return __dma_request_channel(&mask, rz_dmac_chan_filter, dma_spec,
+ ofdma->of_node);
}
/*
--
2.34.1
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v4 5/7] dmaengine: sh: rz-dmac: Allow for multiple DMACs
2025-02-20 15:01 ` [PATCH v4 5/7] dmaengine: sh: rz-dmac: Allow for multiple DMACs Fabrizio Castro
@ 2025-02-21 21:25 ` Lad, Prabhakar
2025-02-24 13:00 ` Geert Uytterhoeven
1 sibling, 0 replies; 37+ messages in thread
From: Lad, Prabhakar @ 2025-02-21 21:25 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Geert Uytterhoeven, Wolfram Sang, Biju Das,
Uwe Kleine-König, dmaengine, linux-kernel, Lad Prabhakar,
linux-renesas-soc
On Thu, Feb 20, 2025 at 3:02 PM Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
>
> dma_request_channel() calls into __dma_request_channel() with
> NULL as value for np, which won't allow for the selection of the
> correct DMAC when multiple DMACs are available.
>
> Switch to using __dma_request_channel() directly so that we can
> choose the desired DMA for the channel. This is in preparation
> of adding DMAC support for the Renesas RZ/V2H(P) and similar SoCs.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> v3->v4:
> * No change.
> v2->v3:
> * Added () for calls in changelog.
> v1->v2:
> * No change.
> ---
> drivers/dma/sh/rz-dmac.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cheers,
Prabhakar
> diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
> index 9235db551026..d7a4ce28040b 100644
> --- a/drivers/dma/sh/rz-dmac.c
> +++ b/drivers/dma/sh/rz-dmac.c
> @@ -748,7 +748,8 @@ static struct dma_chan *rz_dmac_of_xlate(struct of_phandle_args *dma_spec,
> dma_cap_zero(mask);
> dma_cap_set(DMA_SLAVE, mask);
>
> - return dma_request_channel(mask, rz_dmac_chan_filter, dma_spec);
> + return __dma_request_channel(&mask, rz_dmac_chan_filter, dma_spec,
> + ofdma->of_node);
> }
>
> /*
> --
> 2.34.1
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v4 5/7] dmaengine: sh: rz-dmac: Allow for multiple DMACs
2025-02-20 15:01 ` [PATCH v4 5/7] dmaengine: sh: rz-dmac: Allow for multiple DMACs Fabrizio Castro
2025-02-21 21:25 ` Lad, Prabhakar
@ 2025-02-24 13:00 ` Geert Uytterhoeven
1 sibling, 0 replies; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-24 13:00 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Wolfram Sang, Biju Das, Uwe Kleine-König,
dmaengine, linux-kernel, Lad Prabhakar, linux-renesas-soc
On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> dma_request_channel() calls into __dma_request_channel() with
> NULL as value for np, which won't allow for the selection of the
> correct DMAC when multiple DMACs are available.
>
> Switch to using __dma_request_channel() directly so that we can
> choose the desired DMA for the channel. This is in preparation
> of adding DMAC support for the Renesas RZ/V2H(P) and similar SoCs.
>
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
2025-02-20 15:01 [PATCH v4 0/7] Add DMAC support to the RZ/V2H(P) Fabrizio Castro
` (4 preceding siblings ...)
2025-02-20 15:01 ` [PATCH v4 5/7] dmaengine: sh: rz-dmac: Allow for multiple DMACs Fabrizio Castro
@ 2025-02-20 15:01 ` Fabrizio Castro
2025-02-21 21:44 ` Lad, Prabhakar
` (2 more replies)
2025-02-20 15:01 ` [PATCH v4 7/7] arm64: dts: renesas: r9a09g057: Add DMAC nodes Fabrizio Castro
6 siblings, 3 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-20 15:01 UTC (permalink / raw)
To: Vinod Koul, Geert Uytterhoeven
Cc: Fabrizio Castro, Magnus Damm, Wolfram Sang, Biju Das,
Uwe Kleine-König, dmaengine, linux-kernel, linux-renesas-soc,
Lad Prabhakar
The DMAC IP found on the Renesas RZ/V2H(P) family of SoCs is
similar to the version 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)
* On the RZ/G2L there is only 1 DMAC, on the RZ/V2H(P) there are 5
Add specific support for the Renesas RZ/V2H(P) family of SoC by
tackling the aforementioned differences.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
v3->v4:
* Fixed an issue with mid_rid/req_no/ack_no initialization
v2->v3:
* Dropped change to Kconfig.
* Replaced rz_dmac_type with has_icu flag.
* Put req_no and ack_no in an anonymous struct, nested under an
anonymous union with mid_rid.
* Dropped data field of_rz_dmac_match[], and added logic to determine
value of has_icu flag from DT parsing.
v1->v2:
* Switched to new macros for minimum values.
---
drivers/dma/sh/rz-dmac.c | 162 +++++++++++++++++++++++++++++++++++----
1 file changed, 146 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
index d7a4ce28040b..57a1fdeed734 100644
--- a/drivers/dma/sh/rz-dmac.c
+++ b/drivers/dma/sh/rz-dmac.c
@@ -14,6 +14,7 @@
#include <linux/dmaengine.h>
#include <linux/interrupt.h>
#include <linux/iopoll.h>
+#include <linux/irqchip/irq-renesas-rzv2h.h>
#include <linux/list.h>
#include <linux/module.h>
#include <linux/of.h>
@@ -73,7 +74,6 @@ struct rz_dmac_chan {
u32 chcfg;
u32 chctrl;
- int mid_rid;
struct list_head ld_free;
struct list_head ld_queue;
@@ -85,20 +85,36 @@ struct rz_dmac_chan {
struct rz_lmdesc *tail;
dma_addr_t base_dma;
} lmdesc;
+
+ union {
+ int mid_rid;
+ struct {
+ u16 req_no;
+ u8 ack_no;
+ };
+ };
};
#define to_rz_dmac_chan(c) container_of(c, struct rz_dmac_chan, vc.chan)
+struct rz_dmac_icu {
+ struct platform_device *pdev;
+ u8 dmac_index;
+};
+
struct rz_dmac {
struct dma_device engine;
struct device *dev;
struct reset_control *rstc;
+ struct rz_dmac_icu icu;
void __iomem *base;
void __iomem *ext_base;
unsigned int n_channels;
struct rz_dmac_chan *channels;
+ bool has_icu;
+
DECLARE_BITMAP(modules, 1024);
};
@@ -167,6 +183,23 @@ struct rz_dmac {
#define RZ_DMAC_MAX_CHANNELS 16
#define DMAC_NR_LMDESC 64
+/* RZ/V2H ICU related */
+#define RZV2H_REQ_NO_MASK GENMASK(9, 0)
+#define RZV2H_ACK_NO_MASK GENMASK(16, 10)
+#define RZV2H_HIEN_MASK BIT(17)
+#define RZV2H_LVL_MASK BIT(18)
+#define RZV2H_AM_MASK GENMASK(21, 19)
+#define RZV2H_TM_MASK BIT(22)
+#define RZV2H_EXTRACT_REQ_NO(x) FIELD_GET(RZV2H_REQ_NO_MASK, (x))
+#define RZV2H_EXTRACT_ACK_NO(x) FIELD_GET(RZV2H_ACK_NO_MASK, (x))
+#define RZVH2_EXTRACT_CHCFG(x) ((FIELD_GET(RZV2H_HIEN_MASK, (x)) << 5) | \
+ (FIELD_GET(RZV2H_LVL_MASK, (x)) << 6) | \
+ (FIELD_GET(RZV2H_AM_MASK, (x)) << 8) | \
+ (FIELD_GET(RZV2H_TM_MASK, (x)) << 22))
+
+#define RZV2H_MAX_DMAC_INDEX 4
+#define RZV2H_ICU_PROPERTY "renesas,icu"
+
/*
* -----------------------------------------------------------------------------
* Device access
@@ -324,7 +357,15 @@ static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
lmdesc->chext = 0;
lmdesc->header = HEADER_LV;
- rz_dmac_set_dmars_register(dmac, channel->index, 0);
+ if (!dmac->has_icu) {
+ rz_dmac_set_dmars_register(dmac, channel->index, 0);
+ } else {
+ rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
+ dmac->icu.dmac_index,
+ channel->index,
+ RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
+ RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
+ }
channel->chcfg = chcfg;
channel->chctrl = CHCTRL_STG | CHCTRL_SETEN;
@@ -375,7 +416,15 @@ static void rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan *channel)
channel->lmdesc.tail = lmdesc;
- rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
+ if (!dmac->has_icu) {
+ rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
+ } else {
+ rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
+ dmac->icu.dmac_index,
+ channel->index, channel->req_no,
+ channel->ack_no);
+ }
+
channel->chctrl = CHCTRL_SETEN;
}
@@ -452,9 +501,15 @@ static void rz_dmac_free_chan_resources(struct dma_chan *chan)
list_splice_tail_init(&channel->ld_active, &channel->ld_free);
list_splice_tail_init(&channel->ld_queue, &channel->ld_free);
- if (channel->mid_rid >= 0) {
- clear_bit(channel->mid_rid, dmac->modules);
- channel->mid_rid = -EINVAL;
+ if (!dmac->has_icu) {
+ if (channel->mid_rid >= 0) {
+ clear_bit(channel->mid_rid, dmac->modules);
+ channel->mid_rid = -EINVAL;
+ }
+ } else {
+ clear_bit(channel->req_no, dmac->modules);
+ channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
+ channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
}
spin_unlock_irqrestore(&channel->vc.lock, flags);
@@ -647,7 +702,15 @@ static void rz_dmac_device_synchronize(struct dma_chan *chan)
if (ret < 0)
dev_warn(dmac->dev, "DMA Timeout");
- rz_dmac_set_dmars_register(dmac, channel->index, 0);
+ if (!dmac->has_icu) {
+ rz_dmac_set_dmars_register(dmac, channel->index, 0);
+ } else {
+ rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
+ dmac->icu.dmac_index,
+ channel->index,
+ RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
+ RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
+ }
}
/*
@@ -727,13 +790,30 @@ static bool rz_dmac_chan_filter(struct dma_chan *chan, void *arg)
struct rz_dmac *dmac = to_rz_dmac(chan->device);
struct of_phandle_args *dma_spec = arg;
u32 ch_cfg;
+ u16 req_no;
+
+ if (!dmac->has_icu) {
+ channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
+ ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
+ channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
+ CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
+
+ return !test_and_set_bit(channel->mid_rid, dmac->modules);
+ }
+
+ req_no = RZV2H_EXTRACT_REQ_NO(dma_spec->args[0]);
+ if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
+ return false;
+
+ channel->req_no = req_no;
+
+ channel->ack_no = RZV2H_EXTRACT_ACK_NO(dma_spec->args[0]);
+ if (channel->ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
+ channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
- channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
- ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
- channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
- CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
+ channel->chcfg = RZVH2_EXTRACT_CHCFG(dma_spec->args[0]);
- return !test_and_set_bit(channel->mid_rid, dmac->modules);
+ return !test_and_set_bit(channel->req_no, dmac->modules);
}
static struct dma_chan *rz_dmac_of_xlate(struct of_phandle_args *dma_spec,
@@ -768,7 +848,12 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
int ret;
channel->index = index;
- channel->mid_rid = -EINVAL;
+ if (!dmac->has_icu) {
+ channel->mid_rid = -EINVAL;
+ } else {
+ channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
+ channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
+ }
/* Request the channel interrupt. */
scnprintf(pdev_irqname, sizeof(pdev_irqname), "ch%u", index);
@@ -824,6 +909,41 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
return 0;
}
+static int rz_dmac_parse_of_icu(struct device *dev, struct rz_dmac *dmac)
+{
+ struct device_node *icu_np, *np = dev->of_node;
+ struct of_phandle_args args;
+ uint32_t dmac_index;
+ int ret;
+
+ ret = of_parse_phandle_with_fixed_args(np, RZV2H_ICU_PROPERTY, 1, 0, &args);
+ if (ret)
+ return ret;
+
+ icu_np = args.np;
+ dmac_index = args.args[0];
+
+ if (dmac_index > RZV2H_MAX_DMAC_INDEX) {
+ dev_err(dev, "DMAC index %u invalid.\n", dmac_index);
+ ret = -EINVAL;
+ goto free_icu_np;
+ }
+
+ dmac->icu.pdev = of_find_device_by_node(icu_np);
+ if (!dmac->icu.pdev) {
+ dev_err(dev, "ICU device not found.\n");
+ ret = -ENODEV;
+ goto free_icu_np;
+ }
+
+ dmac->icu.dmac_index = dmac_index;
+
+free_icu_np:
+ of_node_put(icu_np);
+
+ return ret;
+}
+
static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
{
struct device_node *np = dev->of_node;
@@ -840,6 +960,10 @@ static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
return -EINVAL;
}
+ dmac->has_icu = of_property_present(np, RZV2H_ICU_PROPERTY);
+ if (dmac->has_icu)
+ return rz_dmac_parse_of_icu(dev, dmac);
+
return 0;
}
@@ -874,9 +998,11 @@ static int rz_dmac_probe(struct platform_device *pdev)
if (IS_ERR(dmac->base))
return PTR_ERR(dmac->base);
- dmac->ext_base = devm_platform_ioremap_resource(pdev, 1);
- if (IS_ERR(dmac->ext_base))
- return PTR_ERR(dmac->ext_base);
+ if (!dmac->has_icu) {
+ dmac->ext_base = devm_platform_ioremap_resource(pdev, 1);
+ if (IS_ERR(dmac->ext_base))
+ return PTR_ERR(dmac->ext_base);
+ }
/* Register interrupt handler for error */
irq = platform_get_irq_byname(pdev, irqname);
@@ -991,9 +1117,13 @@ static void rz_dmac_remove(struct platform_device *pdev)
reset_control_assert(dmac->rstc);
pm_runtime_put(&pdev->dev);
pm_runtime_disable(&pdev->dev);
+
+ if (dmac->has_icu)
+ platform_device_put(dmac->icu.pdev);
}
static const struct of_device_id of_rz_dmac_match[] = {
+ { .compatible = "renesas,r9a09g057-dmac", },
{ .compatible = "renesas,rz-dmac", },
{ /* Sentinel */ }
};
--
2.34.1
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
2025-02-20 15:01 ` [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support Fabrizio Castro
@ 2025-02-21 21:44 ` Lad, Prabhakar
2025-02-22 8:05 ` Biju Das
2025-02-24 13:19 ` Geert Uytterhoeven
2 siblings, 0 replies; 37+ messages in thread
From: Lad, Prabhakar @ 2025-02-21 21:44 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Geert Uytterhoeven, Magnus Damm, Wolfram Sang,
Biju Das, Uwe Kleine-König, dmaengine, linux-kernel,
linux-renesas-soc, Lad Prabhakar
On Thu, Feb 20, 2025 at 3:07 PM Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
>
> The DMAC IP found on the Renesas RZ/V2H(P) family of SoCs is
> similar to the version 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)
> * On the RZ/G2L there is only 1 DMAC, on the RZ/V2H(P) there are 5
>
> Add specific support for the Renesas RZ/V2H(P) family of SoC by
> tackling the aforementioned differences.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> v3->v4:
> * Fixed an issue with mid_rid/req_no/ack_no initialization
> v2->v3:
> * Dropped change to Kconfig.
> * Replaced rz_dmac_type with has_icu flag.
> * Put req_no and ack_no in an anonymous struct, nested under an
> anonymous union with mid_rid.
> * Dropped data field of_rz_dmac_match[], and added logic to determine
> value of has_icu flag from DT parsing.
> v1->v2:
> * Switched to new macros for minimum values.
> ---
> drivers/dma/sh/rz-dmac.c | 162 +++++++++++++++++++++++++++++++++++----
> 1 file changed, 146 insertions(+), 16 deletions(-)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cheers,
Prabhakar
> diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c
> index d7a4ce28040b..57a1fdeed734 100644
> --- a/drivers/dma/sh/rz-dmac.c
> +++ b/drivers/dma/sh/rz-dmac.c
> @@ -14,6 +14,7 @@
> #include <linux/dmaengine.h>
> #include <linux/interrupt.h>
> #include <linux/iopoll.h>
> +#include <linux/irqchip/irq-renesas-rzv2h.h>
> #include <linux/list.h>
> #include <linux/module.h>
> #include <linux/of.h>
> @@ -73,7 +74,6 @@ struct rz_dmac_chan {
>
> u32 chcfg;
> u32 chctrl;
> - int mid_rid;
>
> struct list_head ld_free;
> struct list_head ld_queue;
> @@ -85,20 +85,36 @@ struct rz_dmac_chan {
> struct rz_lmdesc *tail;
> dma_addr_t base_dma;
> } lmdesc;
> +
> + union {
> + int mid_rid;
> + struct {
> + u16 req_no;
> + u8 ack_no;
> + };
> + };
> };
>
> #define to_rz_dmac_chan(c) container_of(c, struct rz_dmac_chan, vc.chan)
>
> +struct rz_dmac_icu {
> + struct platform_device *pdev;
> + u8 dmac_index;
> +};
> +
> struct rz_dmac {
> struct dma_device engine;
> struct device *dev;
> struct reset_control *rstc;
> + struct rz_dmac_icu icu;
> void __iomem *base;
> void __iomem *ext_base;
>
> unsigned int n_channels;
> struct rz_dmac_chan *channels;
>
> + bool has_icu;
> +
> DECLARE_BITMAP(modules, 1024);
> };
>
> @@ -167,6 +183,23 @@ struct rz_dmac {
> #define RZ_DMAC_MAX_CHANNELS 16
> #define DMAC_NR_LMDESC 64
>
> +/* RZ/V2H ICU related */
> +#define RZV2H_REQ_NO_MASK GENMASK(9, 0)
> +#define RZV2H_ACK_NO_MASK GENMASK(16, 10)
> +#define RZV2H_HIEN_MASK BIT(17)
> +#define RZV2H_LVL_MASK BIT(18)
> +#define RZV2H_AM_MASK GENMASK(21, 19)
> +#define RZV2H_TM_MASK BIT(22)
> +#define RZV2H_EXTRACT_REQ_NO(x) FIELD_GET(RZV2H_REQ_NO_MASK, (x))
> +#define RZV2H_EXTRACT_ACK_NO(x) FIELD_GET(RZV2H_ACK_NO_MASK, (x))
> +#define RZVH2_EXTRACT_CHCFG(x) ((FIELD_GET(RZV2H_HIEN_MASK, (x)) << 5) | \
> + (FIELD_GET(RZV2H_LVL_MASK, (x)) << 6) | \
> + (FIELD_GET(RZV2H_AM_MASK, (x)) << 8) | \
> + (FIELD_GET(RZV2H_TM_MASK, (x)) << 22))
> +
> +#define RZV2H_MAX_DMAC_INDEX 4
> +#define RZV2H_ICU_PROPERTY "renesas,icu"
> +
> /*
> * -----------------------------------------------------------------------------
> * Device access
> @@ -324,7 +357,15 @@ static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
> lmdesc->chext = 0;
> lmdesc->header = HEADER_LV;
>
> - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + if (!dmac->has_icu) {
> + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + } else {
> + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> + dmac->icu.dmac_index,
> + channel->index,
> + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> + }
>
> channel->chcfg = chcfg;
> channel->chctrl = CHCTRL_STG | CHCTRL_SETEN;
> @@ -375,7 +416,15 @@ static void rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan *channel)
>
> channel->lmdesc.tail = lmdesc;
>
> - rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
> + if (!dmac->has_icu) {
> + rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
> + } else {
> + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> + dmac->icu.dmac_index,
> + channel->index, channel->req_no,
> + channel->ack_no);
> + }
> +
> channel->chctrl = CHCTRL_SETEN;
> }
>
> @@ -452,9 +501,15 @@ static void rz_dmac_free_chan_resources(struct dma_chan *chan)
> list_splice_tail_init(&channel->ld_active, &channel->ld_free);
> list_splice_tail_init(&channel->ld_queue, &channel->ld_free);
>
> - if (channel->mid_rid >= 0) {
> - clear_bit(channel->mid_rid, dmac->modules);
> - channel->mid_rid = -EINVAL;
> + if (!dmac->has_icu) {
> + if (channel->mid_rid >= 0) {
> + clear_bit(channel->mid_rid, dmac->modules);
> + channel->mid_rid = -EINVAL;
> + }
> + } else {
> + clear_bit(channel->req_no, dmac->modules);
> + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> }
>
> spin_unlock_irqrestore(&channel->vc.lock, flags);
> @@ -647,7 +702,15 @@ static void rz_dmac_device_synchronize(struct dma_chan *chan)
> if (ret < 0)
> dev_warn(dmac->dev, "DMA Timeout");
>
> - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + if (!dmac->has_icu) {
> + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + } else {
> + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> + dmac->icu.dmac_index,
> + channel->index,
> + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> + }
> }
>
> /*
> @@ -727,13 +790,30 @@ static bool rz_dmac_chan_filter(struct dma_chan *chan, void *arg)
> struct rz_dmac *dmac = to_rz_dmac(chan->device);
> struct of_phandle_args *dma_spec = arg;
> u32 ch_cfg;
> + u16 req_no;
> +
> + if (!dmac->has_icu) {
> + channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> + ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> + channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> + CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> +
> + return !test_and_set_bit(channel->mid_rid, dmac->modules);
> + }
> +
> + req_no = RZV2H_EXTRACT_REQ_NO(dma_spec->args[0]);
> + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> + return false;
> +
> + channel->req_no = req_no;
> +
> + channel->ack_no = RZV2H_EXTRACT_ACK_NO(dma_spec->args[0]);
> + if (channel->ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
>
> - channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> - ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> - channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> - CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> + channel->chcfg = RZVH2_EXTRACT_CHCFG(dma_spec->args[0]);
>
> - return !test_and_set_bit(channel->mid_rid, dmac->modules);
> + return !test_and_set_bit(channel->req_no, dmac->modules);
> }
>
> static struct dma_chan *rz_dmac_of_xlate(struct of_phandle_args *dma_spec,
> @@ -768,7 +848,12 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
> int ret;
>
> channel->index = index;
> - channel->mid_rid = -EINVAL;
> + if (!dmac->has_icu) {
> + channel->mid_rid = -EINVAL;
> + } else {
> + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> + }
>
> /* Request the channel interrupt. */
> scnprintf(pdev_irqname, sizeof(pdev_irqname), "ch%u", index);
> @@ -824,6 +909,41 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
> return 0;
> }
>
> +static int rz_dmac_parse_of_icu(struct device *dev, struct rz_dmac *dmac)
> +{
> + struct device_node *icu_np, *np = dev->of_node;
> + struct of_phandle_args args;
> + uint32_t dmac_index;
> + int ret;
> +
> + ret = of_parse_phandle_with_fixed_args(np, RZV2H_ICU_PROPERTY, 1, 0, &args);
> + if (ret)
> + return ret;
> +
> + icu_np = args.np;
> + dmac_index = args.args[0];
> +
> + if (dmac_index > RZV2H_MAX_DMAC_INDEX) {
> + dev_err(dev, "DMAC index %u invalid.\n", dmac_index);
> + ret = -EINVAL;
> + goto free_icu_np;
> + }
> +
> + dmac->icu.pdev = of_find_device_by_node(icu_np);
> + if (!dmac->icu.pdev) {
> + dev_err(dev, "ICU device not found.\n");
> + ret = -ENODEV;
> + goto free_icu_np;
> + }
> +
> + dmac->icu.dmac_index = dmac_index;
> +
> +free_icu_np:
> + of_node_put(icu_np);
> +
> + return ret;
> +}
> +
> static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
> {
> struct device_node *np = dev->of_node;
> @@ -840,6 +960,10 @@ static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
> return -EINVAL;
> }
>
> + dmac->has_icu = of_property_present(np, RZV2H_ICU_PROPERTY);
> + if (dmac->has_icu)
> + return rz_dmac_parse_of_icu(dev, dmac);
> +
> return 0;
> }
>
> @@ -874,9 +998,11 @@ static int rz_dmac_probe(struct platform_device *pdev)
> if (IS_ERR(dmac->base))
> return PTR_ERR(dmac->base);
>
> - dmac->ext_base = devm_platform_ioremap_resource(pdev, 1);
> - if (IS_ERR(dmac->ext_base))
> - return PTR_ERR(dmac->ext_base);
> + if (!dmac->has_icu) {
> + dmac->ext_base = devm_platform_ioremap_resource(pdev, 1);
> + if (IS_ERR(dmac->ext_base))
> + return PTR_ERR(dmac->ext_base);
> + }
>
> /* Register interrupt handler for error */
> irq = platform_get_irq_byname(pdev, irqname);
> @@ -991,9 +1117,13 @@ static void rz_dmac_remove(struct platform_device *pdev)
> reset_control_assert(dmac->rstc);
> pm_runtime_put(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> +
> + if (dmac->has_icu)
> + platform_device_put(dmac->icu.pdev);
> }
>
> static const struct of_device_id of_rz_dmac_match[] = {
> + { .compatible = "renesas,r9a09g057-dmac", },
> { .compatible = "renesas,rz-dmac", },
> { /* Sentinel */ }
> };
> --
> 2.34.1
>
>
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
2025-02-20 15:01 ` [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support Fabrizio Castro
2025-02-21 21:44 ` Lad, Prabhakar
@ 2025-02-22 8:05 ` Biju Das
2025-02-22 8:06 ` Biju Das
2025-02-24 13:19 ` Geert Uytterhoeven
2 siblings, 1 reply; 37+ messages in thread
From: Biju Das @ 2025-02-22 8:05 UTC (permalink / raw)
To: Fabrizio Castro, Vinod Koul, Geert Uytterhoeven
Cc: Fabrizio Castro, Magnus Damm, Wolfram Sang, Uwe Kleine-König,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
Hi Fabrizio Castro,
> -----Original Message-----
> From: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> Sent: 20 February 2025 15:01
> Subject: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
>
> The DMAC IP found on the Renesas RZ/V2H(P) family of SoCs is similar to the version 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)
> * On the RZ/G2L there is only 1 DMAC, on the RZ/V2H(P) there are 5
>
> Add specific support for the Renesas RZ/V2H(P) family of SoC by tackling the aforementioned
> differences.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> v3->v4:
> * Fixed an issue with mid_rid/req_no/ack_no initialization
> v2->v3:
> * Dropped change to Kconfig.
> * Replaced rz_dmac_type with has_icu flag.
> * Put req_no and ack_no in an anonymous struct, nested under an
> anonymous union with mid_rid.
> * Dropped data field of_rz_dmac_match[], and added logic to determine
> value of has_icu flag from DT parsing.
> v1->v2:
> * Switched to new macros for minimum values.
> ---
> drivers/dma/sh/rz-dmac.c | 162 +++++++++++++++++++++++++++++++++++----
> 1 file changed, 146 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c index d7a4ce28040b..57a1fdeed734
> 100644
> --- a/drivers/dma/sh/rz-dmac.c
> +++ b/drivers/dma/sh/rz-dmac.c
> @@ -14,6 +14,7 @@
> #include <linux/dmaengine.h>
> #include <linux/interrupt.h>
> #include <linux/iopoll.h>
> +#include <linux/irqchip/irq-renesas-rzv2h.h>
> #include <linux/list.h>
> #include <linux/module.h>
> #include <linux/of.h>
> @@ -73,7 +74,6 @@ struct rz_dmac_chan {
>
> u32 chcfg;
> u32 chctrl;
> - int mid_rid;
>
> struct list_head ld_free;
> struct list_head ld_queue;
> @@ -85,20 +85,36 @@ struct rz_dmac_chan {
> struct rz_lmdesc *tail;
> dma_addr_t base_dma;
> } lmdesc;
> +
> + union {
> + int mid_rid;
> + struct {
> + u16 req_no;
> + u8 ack_no;
> + };
> + };
> };
>
> #define to_rz_dmac_chan(c) container_of(c, struct rz_dmac_chan, vc.chan)
>
> +struct rz_dmac_icu {
> + struct platform_device *pdev;
> + u8 dmac_index;
> +};
> +
> struct rz_dmac {
> struct dma_device engine;
> struct device *dev;
> struct reset_control *rstc;
> + struct rz_dmac_icu icu;
> void __iomem *base;
> void __iomem *ext_base;
>
> unsigned int n_channels;
> struct rz_dmac_chan *channels;
>
> + bool has_icu;
> +
> DECLARE_BITMAP(modules, 1024);
> };
>
> @@ -167,6 +183,23 @@ struct rz_dmac {
> #define RZ_DMAC_MAX_CHANNELS 16
> #define DMAC_NR_LMDESC 64
>
> +/* RZ/V2H ICU related */
> +#define RZV2H_REQ_NO_MASK GENMASK(9, 0)
> +#define RZV2H_ACK_NO_MASK GENMASK(16, 10)
> +#define RZV2H_HIEN_MASK BIT(17)
> +#define RZV2H_LVL_MASK BIT(18)
> +#define RZV2H_AM_MASK GENMASK(21, 19)
> +#define RZV2H_TM_MASK BIT(22)
> +#define RZV2H_EXTRACT_REQ_NO(x) FIELD_GET(RZV2H_REQ_NO_MASK, (x))
> +#define RZV2H_EXTRACT_ACK_NO(x) FIELD_GET(RZV2H_ACK_NO_MASK, (x))
> +#define RZVH2_EXTRACT_CHCFG(x) ((FIELD_GET(RZV2H_HIEN_MASK, (x)) << 5) | \
> + (FIELD_GET(RZV2H_LVL_MASK, (x)) << 6) | \
> + (FIELD_GET(RZV2H_AM_MASK, (x)) << 8) | \
> + (FIELD_GET(RZV2H_TM_MASK, (x)) << 22))
> +
> +#define RZV2H_MAX_DMAC_INDEX 4
> +#define RZV2H_ICU_PROPERTY "renesas,icu"
> +
> /*
> * -----------------------------------------------------------------------------
> * Device access
> @@ -324,7 +357,15 @@ static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
> lmdesc->chext = 0;
> lmdesc->header = HEADER_LV;
>
> - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + if (!dmac->has_icu) {
> + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + } else {
> + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> + dmac->icu.dmac_index,
> + channel->index,
> + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> + }
>
> channel->chcfg = chcfg;
> channel->chctrl = CHCTRL_STG | CHCTRL_SETEN; @@ -375,7 +416,15 @@ static void
> rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan *channel)
>
> channel->lmdesc.tail = lmdesc;
>
> - rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
> + if (!dmac->has_icu) {
> + rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
> + } else {
> + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> + dmac->icu.dmac_index,
> + channel->index, channel->req_no,
> + channel->ack_no);
> + }
> +
> channel->chctrl = CHCTRL_SETEN;
> }
>
> @@ -452,9 +501,15 @@ static void rz_dmac_free_chan_resources(struct dma_chan *chan)
> list_splice_tail_init(&channel->ld_active, &channel->ld_free);
> list_splice_tail_init(&channel->ld_queue, &channel->ld_free);
>
> - if (channel->mid_rid >= 0) {
> - clear_bit(channel->mid_rid, dmac->modules);
> - channel->mid_rid = -EINVAL;
> + if (!dmac->has_icu) {
> + if (channel->mid_rid >= 0) {
> + clear_bit(channel->mid_rid, dmac->modules);
> + channel->mid_rid = -EINVAL;
> + }
> + } else {
> + clear_bit(channel->req_no, dmac->modules);
> + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> }
>
> spin_unlock_irqrestore(&channel->vc.lock, flags); @@ -647,7 +702,15 @@ static void
> rz_dmac_device_synchronize(struct dma_chan *chan)
> if (ret < 0)
> dev_warn(dmac->dev, "DMA Timeout");
>
> - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + if (!dmac->has_icu) {
> + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + } else {
> + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> + dmac->icu.dmac_index,
> + channel->index,
> + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> + }
> }
>
> /*
> @@ -727,13 +790,30 @@ static bool rz_dmac_chan_filter(struct dma_chan *chan, void *arg)
> struct rz_dmac *dmac = to_rz_dmac(chan->device);
> struct of_phandle_args *dma_spec = arg;
> u32 ch_cfg;
> + u16 req_no;
> +
> + if (!dmac->has_icu) {
> + channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> + ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> + channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> + CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> +
> + return !test_and_set_bit(channel->mid_rid, dmac->modules);
> + }
> +
> + req_no = RZV2H_EXTRACT_REQ_NO(dma_spec->args[0]);
> + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> + return false;
> +
> + channel->req_no = req_no;
> +
> + channel->ack_no = RZV2H_EXTRACT_ACK_NO(dma_spec->args[0]);
> + if (channel->ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
>
> - channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> - ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> - channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> - CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> + channel->chcfg = RZVH2_EXTRACT_CHCFG(dma_spec->args[0]);
Looks like a typo?? RZVH2_EXTRACT_CHCFG-> RZVH2_EXTRACT_CHCFG
Cheers,
Biju
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
2025-02-22 8:05 ` Biju Das
@ 2025-02-22 8:06 ` Biju Das
0 siblings, 0 replies; 37+ messages in thread
From: Biju Das @ 2025-02-22 8:06 UTC (permalink / raw)
To: Fabrizio Castro, Vinod Koul, Geert Uytterhoeven
Cc: Fabrizio Castro, Magnus Damm, Wolfram Sang, Uwe Kleine-König,
dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Prabhakar Mahadev Lad
> -----Original Message-----
> From: Biju Das
> Sent: 22 February 2025 08:06
> To: 'Fabrizio Castro' <fabrizio.castro.jz@renesas.com>; Vinod Koul <vkoul@kernel.org>; Geert
> Uytterhoeven <geert+renesas@glider.be>
> Cc: Fabrizio Castro <fabrizio.castro.jz@renesas.com>; Magnus Damm <magnus.damm@gmail.com>; Wolfram
> Sang <wsa+renesas@sang-engineering.com>; Uwe Kleine-König <u.kleine-koenig@baylibre.com>;
> dmaengine@vger.kernel.org; linux-kernel@vger.kernel.org; linux-renesas-soc@vger.kernel.org; Prabhakar
> Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Subject: RE: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
>
> Hi Fabrizio Castro,
>
> > -----Original Message-----
> > From: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > Sent: 20 February 2025 15:01
> > Subject: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
> >
> > The DMAC IP found on the Renesas RZ/V2H(P) family of SoCs is similar
> > to the version 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)
> > * On the RZ/G2L there is only 1 DMAC, on the RZ/V2H(P) there are 5
> >
> > Add specific support for the Renesas RZ/V2H(P) family of SoC by
> > tackling the aforementioned differences.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > ---
> > v3->v4:
> > * Fixed an issue with mid_rid/req_no/ack_no initialization
> > v2->v3:
> > * Dropped change to Kconfig.
> > * Replaced rz_dmac_type with has_icu flag.
> > * Put req_no and ack_no in an anonymous struct, nested under an
> > anonymous union with mid_rid.
> > * Dropped data field of_rz_dmac_match[], and added logic to determine
> > value of has_icu flag from DT parsing.
> > v1->v2:
> > * Switched to new macros for minimum values.
> > ---
> > drivers/dma/sh/rz-dmac.c | 162
> > +++++++++++++++++++++++++++++++++++----
> > 1 file changed, 146 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c index
> > d7a4ce28040b..57a1fdeed734
> > 100644
> > --- a/drivers/dma/sh/rz-dmac.c
> > +++ b/drivers/dma/sh/rz-dmac.c
> > @@ -14,6 +14,7 @@
> > #include <linux/dmaengine.h>
> > #include <linux/interrupt.h>
> > #include <linux/iopoll.h>
> > +#include <linux/irqchip/irq-renesas-rzv2h.h>
> > #include <linux/list.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > @@ -73,7 +74,6 @@ struct rz_dmac_chan {
> >
> > u32 chcfg;
> > u32 chctrl;
> > - int mid_rid;
> >
> > struct list_head ld_free;
> > struct list_head ld_queue;
> > @@ -85,20 +85,36 @@ struct rz_dmac_chan {
> > struct rz_lmdesc *tail;
> > dma_addr_t base_dma;
> > } lmdesc;
> > +
> > + union {
> > + int mid_rid;
> > + struct {
> > + u16 req_no;
> > + u8 ack_no;
> > + };
> > + };
> > };
> >
> > #define to_rz_dmac_chan(c) container_of(c, struct rz_dmac_chan, vc.chan)
> >
> > +struct rz_dmac_icu {
> > + struct platform_device *pdev;
> > + u8 dmac_index;
> > +};
> > +
> > struct rz_dmac {
> > struct dma_device engine;
> > struct device *dev;
> > struct reset_control *rstc;
> > + struct rz_dmac_icu icu;
> > void __iomem *base;
> > void __iomem *ext_base;
> >
> > unsigned int n_channels;
> > struct rz_dmac_chan *channels;
> >
> > + bool has_icu;
> > +
> > DECLARE_BITMAP(modules, 1024);
> > };
> >
> > @@ -167,6 +183,23 @@ struct rz_dmac {
> > #define RZ_DMAC_MAX_CHANNELS 16
> > #define DMAC_NR_LMDESC 64
> >
> > +/* RZ/V2H ICU related */
> > +#define RZV2H_REQ_NO_MASK GENMASK(9, 0)
> > +#define RZV2H_ACK_NO_MASK GENMASK(16, 10)
> > +#define RZV2H_HIEN_MASK BIT(17)
> > +#define RZV2H_LVL_MASK BIT(18)
> > +#define RZV2H_AM_MASK GENMASK(21, 19)
> > +#define RZV2H_TM_MASK BIT(22)
> > +#define RZV2H_EXTRACT_REQ_NO(x) FIELD_GET(RZV2H_REQ_NO_MASK, (x))
> > +#define RZV2H_EXTRACT_ACK_NO(x) FIELD_GET(RZV2H_ACK_NO_MASK, (x))
> > +#define RZVH2_EXTRACT_CHCFG(x) ((FIELD_GET(RZV2H_HIEN_MASK, (x)) << 5) | \
> > + (FIELD_GET(RZV2H_LVL_MASK, (x)) << 6) | \
> > + (FIELD_GET(RZV2H_AM_MASK, (x)) << 8) | \
> > + (FIELD_GET(RZV2H_TM_MASK, (x)) << 22))
> > +
> > +#define RZV2H_MAX_DMAC_INDEX 4
> > +#define RZV2H_ICU_PROPERTY "renesas,icu"
> > +
> > /*
> > * -----------------------------------------------------------------------------
> > * Device access
> > @@ -324,7 +357,15 @@ static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
> > lmdesc->chext = 0;
> > lmdesc->header = HEADER_LV;
> >
> > - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> > + if (!dmac->has_icu) {
> > + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> > + } else {
> > + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> > + dmac->icu.dmac_index,
> > + channel->index,
> > + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> > + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> > + }
> >
> > channel->chcfg = chcfg;
> > channel->chctrl = CHCTRL_STG | CHCTRL_SETEN; @@ -375,7 +416,15 @@
> > static void rz_dmac_prepare_descs_for_slave_sg(struct rz_dmac_chan
> > *channel)
> >
> > channel->lmdesc.tail = lmdesc;
> >
> > - rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
> > + if (!dmac->has_icu) {
> > + rz_dmac_set_dmars_register(dmac, channel->index, channel->mid_rid);
> > + } else {
> > + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> > + dmac->icu.dmac_index,
> > + channel->index, channel->req_no,
> > + channel->ack_no);
> > + }
> > +
> > channel->chctrl = CHCTRL_SETEN;
> > }
> >
> > @@ -452,9 +501,15 @@ static void rz_dmac_free_chan_resources(struct dma_chan *chan)
> > list_splice_tail_init(&channel->ld_active, &channel->ld_free);
> > list_splice_tail_init(&channel->ld_queue, &channel->ld_free);
> >
> > - if (channel->mid_rid >= 0) {
> > - clear_bit(channel->mid_rid, dmac->modules);
> > - channel->mid_rid = -EINVAL;
> > + if (!dmac->has_icu) {
> > + if (channel->mid_rid >= 0) {
> > + clear_bit(channel->mid_rid, dmac->modules);
> > + channel->mid_rid = -EINVAL;
> > + }
> > + } else {
> > + clear_bit(channel->req_no, dmac->modules);
> > + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> > + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> > }
> >
> > spin_unlock_irqrestore(&channel->vc.lock, flags); @@ -647,7 +702,15
> > @@ static void rz_dmac_device_synchronize(struct dma_chan *chan)
> > if (ret < 0)
> > dev_warn(dmac->dev, "DMA Timeout");
> >
> > - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> > + if (!dmac->has_icu) {
> > + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> > + } else {
> > + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> > + dmac->icu.dmac_index,
> > + channel->index,
> > + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> > + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> > + }
> > }
> >
> > /*
> > @@ -727,13 +790,30 @@ static bool rz_dmac_chan_filter(struct dma_chan *chan, void *arg)
> > struct rz_dmac *dmac = to_rz_dmac(chan->device);
> > struct of_phandle_args *dma_spec = arg;
> > u32 ch_cfg;
> > + u16 req_no;
> > +
> > + if (!dmac->has_icu) {
> > + channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> > + ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> > + channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> > + CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> > +
> > + return !test_and_set_bit(channel->mid_rid, dmac->modules);
> > + }
> > +
> > + req_no = RZV2H_EXTRACT_REQ_NO(dma_spec->args[0]);
> > + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> > + return false;
> > +
> > + channel->req_no = req_no;
> > +
> > + channel->ack_no = RZV2H_EXTRACT_ACK_NO(dma_spec->args[0]);
> > + if (channel->ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> > + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> >
> > - channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> > - ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> > - channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> > - CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> > + channel->chcfg = RZVH2_EXTRACT_CHCFG(dma_spec->args[0]);
>
> Looks like a typo?? RZVH2_EXTRACT_CHCFG-> RZVH2_EXTRACT_CHCFG
Oops.
Looks like a typo?? RZVH2_*-> RZV2H_*
Cheers,
Biju
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
2025-02-20 15:01 ` [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support Fabrizio Castro
2025-02-21 21:44 ` Lad, Prabhakar
2025-02-22 8:05 ` Biju Das
@ 2025-02-24 13:19 ` Geert Uytterhoeven
2025-02-28 15:06 ` Fabrizio Castro
2 siblings, 1 reply; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-24 13:19 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Vinod Koul, Magnus Damm, Wolfram Sang, Biju Das,
Uwe Kleine-König, dmaengine, linux-kernel, linux-renesas-soc,
Lad Prabhakar
Hi Fabrizio,
On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
> The DMAC IP found on the Renesas RZ/V2H(P) family of SoCs is
> similar to the version 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)
> * On the RZ/G2L there is only 1 DMAC, on the RZ/V2H(P) there are 5
>
> Add specific support for the Renesas RZ/V2H(P) family of SoC by
> tackling the aforementioned differences.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> v3->v4:
> * Fixed an issue with mid_rid/req_no/ack_no initialization
Thanks for your patch!
> --- a/drivers/dma/sh/rz-dmac.c
> +++ b/drivers/dma/sh/rz-dmac.c
> @@ -14,6 +14,7 @@
> #include <linux/dmaengine.h>
> #include <linux/interrupt.h>
> #include <linux/iopoll.h>
> +#include <linux/irqchip/irq-renesas-rzv2h.h>
> #include <linux/list.h>
> #include <linux/module.h>
> #include <linux/of.h>
> @@ -73,7 +74,6 @@ struct rz_dmac_chan {
>
> u32 chcfg;
> u32 chctrl;
> - int mid_rid;
>
> struct list_head ld_free;
> struct list_head ld_queue;
> @@ -85,20 +85,36 @@ struct rz_dmac_chan {
> struct rz_lmdesc *tail;
> dma_addr_t base_dma;
> } lmdesc;
> +
> + union {
> + int mid_rid;
> + struct {
> + u16 req_no;
> + u8 ack_no;
> + };
> + };
Please add comments (with/without ICU), so the casual reader knows
the meaning of the union.
Note that I am no longer convinced we need a union, as REQ_NO seems
to be just the new name for MID/RID.
> };
>
> #define to_rz_dmac_chan(c) container_of(c, struct rz_dmac_chan, vc.chan)
>
> +struct rz_dmac_icu {
> + struct platform_device *pdev;
> + u8 dmac_index;
> +};
> +
> struct rz_dmac {
> struct dma_device engine;
> struct device *dev;
> struct reset_control *rstc;
> + struct rz_dmac_icu icu;
> void __iomem *base;
> void __iomem *ext_base;
>
> unsigned int n_channels;
> struct rz_dmac_chan *channels;
>
> + bool has_icu;
> +
> DECLARE_BITMAP(modules, 1024);
> };
>
> @@ -167,6 +183,23 @@ struct rz_dmac {
> #define RZ_DMAC_MAX_CHANNELS 16
> #define DMAC_NR_LMDESC 64
>
> +/* RZ/V2H ICU related */
> +#define RZV2H_REQ_NO_MASK GENMASK(9, 0)
FTR, this is identical to MID_RID_MASK.
> +#define RZV2H_ACK_NO_MASK GENMASK(16, 10)
This is a new field.
> +#define RZV2H_HIEN_MASK BIT(17)
> +#define RZV2H_LVL_MASK BIT(18)
> +#define RZV2H_AM_MASK GENMASK(21, 19)
> +#define RZV2H_TM_MASK BIT(22)
> +#define RZV2H_EXTRACT_REQ_NO(x) FIELD_GET(RZV2H_REQ_NO_MASK, (x))
> +#define RZV2H_EXTRACT_ACK_NO(x) FIELD_GET(RZV2H_ACK_NO_MASK, (x))
> +#define RZVH2_EXTRACT_CHCFG(x) ((FIELD_GET(RZV2H_HIEN_MASK, (x)) << 5) | \
> + (FIELD_GET(RZV2H_LVL_MASK, (x)) << 6) | \
> + (FIELD_GET(RZV2H_AM_MASK, (x)) << 8) | \
> + (FIELD_GET(RZV2H_TM_MASK, (x)) << 22))
If the new field would be moved up in the configuration word,
the above would become identical to the existing CHCFG handling.
> +
> +#define RZV2H_MAX_DMAC_INDEX 4
> +#define RZV2H_ICU_PROPERTY "renesas,icu"
Please don't obfuscate DT property handling, and drop this define.
> +
> /*
> * -----------------------------------------------------------------------------
> * Device access
> @@ -324,7 +357,15 @@ static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
> lmdesc->chext = 0;
> lmdesc->header = HEADER_LV;
>
> - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + if (!dmac->has_icu) {
> + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> + } else {
> + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> + dmac->icu.dmac_index,
> + channel->index,
> + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> + }
If you do have both branches of an if-statement, please drop the
negation from the test to improve readability (everywhere):
if (dmac->has_icu) {
...
} else {
...
}
>
> channel->chcfg = chcfg;
> channel->chctrl = CHCTRL_STG | CHCTRL_SETEN;
> @@ -452,9 +501,15 @@ static void rz_dmac_free_chan_resources(struct dma_chan *chan)
> list_splice_tail_init(&channel->ld_active, &channel->ld_free);
> list_splice_tail_init(&channel->ld_queue, &channel->ld_free);
>
> - if (channel->mid_rid >= 0) {
> - clear_bit(channel->mid_rid, dmac->modules);
> - channel->mid_rid = -EINVAL;
> + if (!dmac->has_icu) {
> + if (channel->mid_rid >= 0) {
> + clear_bit(channel->mid_rid, dmac->modules);
> + channel->mid_rid = -EINVAL;
> + }
> + } else {
> + clear_bit(channel->req_no, dmac->modules);
> + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> }
Without a union, both branches would be almost the same...
>
> spin_unlock_irqrestore(&channel->vc.lock, flags);
> @@ -727,13 +790,30 @@ static bool rz_dmac_chan_filter(struct dma_chan *chan, void *arg)
> struct rz_dmac *dmac = to_rz_dmac(chan->device);
> struct of_phandle_args *dma_spec = arg;
> u32 ch_cfg;
> + u16 req_no;
> +
> + if (!dmac->has_icu) {
> + channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
So mid_rid would fit in a short, just like req_no (ignoring the latter
is unsigned, which could be changed).
> + ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> + channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> + CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> +
> + return !test_and_set_bit(channel->mid_rid, dmac->modules);
Please don't return early, but use an else branch for the ICU case,
to show symmetry.
> + }
> +
> + req_no = RZV2H_EXTRACT_REQ_NO(dma_spec->args[0]);
> + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> + return false;
Do you need this check?
> +
> + channel->req_no = req_no;
> +
> + channel->ack_no = RZV2H_EXTRACT_ACK_NO(dma_spec->args[0]);
> + if (channel->ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
Do you need this check?
> - channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> - ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> - channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> - CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> + channel->chcfg = RZVH2_EXTRACT_CHCFG(dma_spec->args[0]);
>
> - return !test_and_set_bit(channel->mid_rid, dmac->modules);
> + return !test_and_set_bit(channel->req_no, dmac->modules);
Without a union, both branches would be almost the same...
> }
>
> static struct dma_chan *rz_dmac_of_xlate(struct of_phandle_args *dma_spec,
> @@ -768,7 +848,12 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
> int ret;
>
> channel->index = index;
> - channel->mid_rid = -EINVAL;
> + if (!dmac->has_icu) {
> + channel->mid_rid = -EINVAL;
> + } else {
> + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> + }
Without a union, both branches would be almost the same...
>
> /* Request the channel interrupt. */
> scnprintf(pdev_irqname, sizeof(pdev_irqname), "ch%u", index);
> @@ -824,6 +909,41 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
> return 0;
> }
>
> +static int rz_dmac_parse_of_icu(struct device *dev, struct rz_dmac *dmac)
> +{
> + struct device_node *icu_np, *np = dev->of_node;
> + struct of_phandle_args args;
> + uint32_t dmac_index;
> + int ret;
> +
> + ret = of_parse_phandle_with_fixed_args(np, RZV2H_ICU_PROPERTY, 1, 0, &args);
> + if (ret)
> + return ret;
> +
> + icu_np = args.np;
> + dmac_index = args.args[0];
> +
> + if (dmac_index > RZV2H_MAX_DMAC_INDEX) {
> + dev_err(dev, "DMAC index %u invalid.\n", dmac_index);
> + ret = -EINVAL;
> + goto free_icu_np;
> + }
> +
> + dmac->icu.pdev = of_find_device_by_node(icu_np);
> + if (!dmac->icu.pdev) {
> + dev_err(dev, "ICU device not found.\n");
> + ret = -ENODEV;
> + goto free_icu_np;
> + }
> +
> + dmac->icu.dmac_index = dmac_index;
> +
> +free_icu_np:
> + of_node_put(icu_np);
> +
> + return ret;
> +}
> +
> static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
> {
> struct device_node *np = dev->of_node;
> @@ -840,6 +960,10 @@ static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
> return -EINVAL;
> }
>
> + dmac->has_icu = of_property_present(np, RZV2H_ICU_PROPERTY);
Doesn't of_parse_phandle_with_fixed_args() in rz_dmac_parse_of_icu()
return -ENOENT if the property is not present, so you don't have to
check for presence here?
> + if (dmac->has_icu)
> + return rz_dmac_parse_of_icu(dev, dmac);
> +
> return 0;
> }
>
> @@ -991,9 +1117,13 @@ static void rz_dmac_remove(struct platform_device *pdev)
> reset_control_assert(dmac->rstc);
> pm_runtime_put(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> +
> + if (dmac->has_icu)
No need to check for a NULL pointer.
> + platform_device_put(dmac->icu.pdev);
> }
>
> static const struct of_device_id of_rz_dmac_match[] = {
> + { .compatible = "renesas,r9a09g057-dmac", },
> { .compatible = "renesas,rz-dmac", },
> { /* Sentinel */ }
> };
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
^ permalink raw reply [flat|nested] 37+ messages in thread* RE: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
2025-02-24 13:19 ` Geert Uytterhoeven
@ 2025-02-28 15:06 ` Fabrizio Castro
0 siblings, 0 replies; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-28 15:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Vinod Koul, Magnus Damm, Wolfram Sang, Biju Das,
Uwe Kleine-König, dmaengine@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Prabhakar Mahadev Lad
Hi Geert,
Thanks for your feedback!
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: 24 February 2025 13:20
> Subject: Re: [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support
>
> Hi Fabrizio,
>
> On Thu, 20 Feb 2025 at 16:01, Fabrizio Castro
> <fabrizio.castro.jz@renesas.com> wrote:
> > The DMAC IP found on the Renesas RZ/V2H(P) family of SoCs is
> > similar to the version 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)
> > * On the RZ/G2L there is only 1 DMAC, on the RZ/V2H(P) there are 5
> >
> > Add specific support for the Renesas RZ/V2H(P) family of SoC by
> > tackling the aforementioned differences.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> > ---
> > v3->v4:
> > * Fixed an issue with mid_rid/req_no/ack_no initialization
>
> Thanks for your patch!
>
> > --- a/drivers/dma/sh/rz-dmac.c
> > +++ b/drivers/dma/sh/rz-dmac.c
> > @@ -14,6 +14,7 @@
> > #include <linux/dmaengine.h>
> > #include <linux/interrupt.h>
> > #include <linux/iopoll.h>
> > +#include <linux/irqchip/irq-renesas-rzv2h.h>
> > #include <linux/list.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > @@ -73,7 +74,6 @@ struct rz_dmac_chan {
> >
> > u32 chcfg;
> > u32 chctrl;
> > - int mid_rid;
> >
> > struct list_head ld_free;
> > struct list_head ld_queue;
> > @@ -85,20 +85,36 @@ struct rz_dmac_chan {
> > struct rz_lmdesc *tail;
> > dma_addr_t base_dma;
> > } lmdesc;
> > +
> > + union {
> > + int mid_rid;
> > + struct {
> > + u16 req_no;
> > + u8 ack_no;
> > + };
> > + };
>
> Please add comments (with/without ICU), so the casual reader knows
> the meaning of the union.
> Note that I am no longer convinced we need a union, as REQ_NO seems
> to be just the new name for MID/RID.
Since I am dropping ACK NO (for now), I think I can reuse mid_rid for V2H,
and document its use for V2H and non V2H platforms.
No need for a union anymore, let's postpone that to when we have a
valid use case for ACK NO.
>
>
> > };
> >
> > #define to_rz_dmac_chan(c) container_of(c, struct rz_dmac_chan, vc.chan)
> >
> > +struct rz_dmac_icu {
> > + struct platform_device *pdev;
> > + u8 dmac_index;
> > +};
> > +
> > struct rz_dmac {
> > struct dma_device engine;
> > struct device *dev;
> > struct reset_control *rstc;
> > + struct rz_dmac_icu icu;
> > void __iomem *base;
> > void __iomem *ext_base;
> >
> > unsigned int n_channels;
> > struct rz_dmac_chan *channels;
> >
> > + bool has_icu;
> > +
> > DECLARE_BITMAP(modules, 1024);
> > };
> >
> > @@ -167,6 +183,23 @@ struct rz_dmac {
> > #define RZ_DMAC_MAX_CHANNELS 16
> > #define DMAC_NR_LMDESC 64
> >
> > +/* RZ/V2H ICU related */
> > +#define RZV2H_REQ_NO_MASK GENMASK(9, 0)
>
> FTR, this is identical to MID_RID_MASK.
>
> > +#define RZV2H_ACK_NO_MASK GENMASK(16, 10)
>
> This is a new field.
>
> > +#define RZV2H_HIEN_MASK BIT(17)
> > +#define RZV2H_LVL_MASK BIT(18)
> > +#define RZV2H_AM_MASK GENMASK(21, 19)
> > +#define RZV2H_TM_MASK BIT(22)
> > +#define RZV2H_EXTRACT_REQ_NO(x) FIELD_GET(RZV2H_REQ_NO_MASK, (x))
> > +#define RZV2H_EXTRACT_ACK_NO(x) FIELD_GET(RZV2H_ACK_NO_MASK, (x))
> > +#define RZVH2_EXTRACT_CHCFG(x) ((FIELD_GET(RZV2H_HIEN_MASK, (x)) << 5) | \
> > + (FIELD_GET(RZV2H_LVL_MASK, (x)) << 6) | \
> > + (FIELD_GET(RZV2H_AM_MASK, (x)) << 8) | \
> > + (FIELD_GET(RZV2H_TM_MASK, (x)) << 22))
>
> If the new field would be moved up in the configuration word,
> the above would become identical to the existing CHCFG handling.
Yes. I originally thought about differentiating V2H from other platforms from the
start, as we may need to add other parameters as well (e.g. TEND No.), but we may
never get around to do that, therefore no point in differentiating them now
(especially considering I am dropping ACK No. for now).
>
> > +
> > +#define RZV2H_MAX_DMAC_INDEX 4
> > +#define RZV2H_ICU_PROPERTY "renesas,icu"
>
> Please don't obfuscate DT property handling, and drop this define.
Will do.
>
> > +
> > /*
> > * -----------------------------------------------------------------------------
> > * Device access
> > @@ -324,7 +357,15 @@ static void rz_dmac_prepare_desc_for_memcpy(struct rz_dmac_chan *channel)
> > lmdesc->chext = 0;
> > lmdesc->header = HEADER_LV;
> >
> > - rz_dmac_set_dmars_register(dmac, channel->index, 0);
> > + if (!dmac->has_icu) {
> > + rz_dmac_set_dmars_register(dmac, channel->index, 0);
> > + } else {
> > + rzv2h_icu_register_dma_req_ack(dmac->icu.pdev,
> > + dmac->icu.dmac_index,
> > + channel->index,
> > + RZV2H_ICU_DMAC_REQ_NO_DEFAULT,
> > + RZV2H_ICU_DMAC_ACK_NO_DEFAULT);
> > + }
>
> If you do have both branches of an if-statement, please drop the
> negation from the test to improve readability (everywhere):
>
> if (dmac->has_icu) {
> ...
> } else {
> ...
> }
Will do
>
> >
> > channel->chcfg = chcfg;
> > channel->chctrl = CHCTRL_STG | CHCTRL_SETEN;
>
> > @@ -452,9 +501,15 @@ static void rz_dmac_free_chan_resources(struct dma_chan *chan)
> > list_splice_tail_init(&channel->ld_active, &channel->ld_free);
> > list_splice_tail_init(&channel->ld_queue, &channel->ld_free);
> >
> > - if (channel->mid_rid >= 0) {
> > - clear_bit(channel->mid_rid, dmac->modules);
> > - channel->mid_rid = -EINVAL;
> > + if (!dmac->has_icu) {
> > + if (channel->mid_rid >= 0) {
> > + clear_bit(channel->mid_rid, dmac->modules);
> > + channel->mid_rid = -EINVAL;
> > + }
> > + } else {
> > + clear_bit(channel->req_no, dmac->modules);
> > + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> > + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> > }
>
> Without a union, both branches would be almost the same...
Indeed.
>
> >
> > spin_unlock_irqrestore(&channel->vc.lock, flags);
>
> > @@ -727,13 +790,30 @@ static bool rz_dmac_chan_filter(struct dma_chan *chan, void *arg)
> > struct rz_dmac *dmac = to_rz_dmac(chan->device);
> > struct of_phandle_args *dma_spec = arg;
> > u32 ch_cfg;
> > + u16 req_no;
> > +
> > + if (!dmac->has_icu) {
> > + channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
>
> So mid_rid would fit in a short, just like req_no (ignoring the latter
> is unsigned, which could be changed).
Yes. I am probably going to leave this alone in the next version of the series.
>
> > + ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> > + channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> > + CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> > +
> > + return !test_and_set_bit(channel->mid_rid, dmac->modules);
>
> Please don't return early, but use an else branch for the ICU case,
> to show symmetry.
If I use `mid_rid` for both V2H and other platforms rz_dmac_chan_filter() should
be identical for both cases (if I also take out the check).
>
> > + }
> > +
> > + req_no = RZV2H_EXTRACT_REQ_NO(dma_spec->args[0]);
> > + if (req_no >= RZV2H_ICU_DMAC_REQ_NO_MIN_FIX_OUTPUT)
> > + return false;
>
> Do you need this check?
I will take it out.
>
> > +
> > + channel->req_no = req_no;
> > +
> > + channel->ack_no = RZV2H_EXTRACT_ACK_NO(dma_spec->args[0]);
> > + if (channel->ack_no >= RZV2H_ICU_DMAC_ACK_NO_MIN_FIX_OUTPUT)
> > + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
>
> Do you need this check?
I am dropping ACK No.
>
> > - channel->mid_rid = dma_spec->args[0] & MID_RID_MASK;
> > - ch_cfg = (dma_spec->args[0] & CHCFG_MASK) >> 10;
> > - channel->chcfg = CHCFG_FILL_TM(ch_cfg) | CHCFG_FILL_AM(ch_cfg) |
> > - CHCFG_FILL_LVL(ch_cfg) | CHCFG_FILL_HIEN(ch_cfg);
> > + channel->chcfg = RZVH2_EXTRACT_CHCFG(dma_spec->args[0]);
> >
> > - return !test_and_set_bit(channel->mid_rid, dmac->modules);
> > + return !test_and_set_bit(channel->req_no, dmac->modules);
>
> Without a union, both branches would be almost the same...
Indeed.
>
> > }
> >
> > static struct dma_chan *rz_dmac_of_xlate(struct of_phandle_args *dma_spec,
> > @@ -768,7 +848,12 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
> > int ret;
> >
> > channel->index = index;
> > - channel->mid_rid = -EINVAL;
> > + if (!dmac->has_icu) {
> > + channel->mid_rid = -EINVAL;
> > + } else {
> > + channel->req_no = RZV2H_ICU_DMAC_REQ_NO_DEFAULT;
> > + channel->ack_no = RZV2H_ICU_DMAC_ACK_NO_DEFAULT;
> > + }
>
> Without a union, both branches would be almost the same...
Indeed.
>
> >
> > /* Request the channel interrupt. */
> > scnprintf(pdev_irqname, sizeof(pdev_irqname), "ch%u", index);
> > @@ -824,6 +909,41 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac,
> > return 0;
> > }
> >
> > +static int rz_dmac_parse_of_icu(struct device *dev, struct rz_dmac *dmac)
> > +{
> > + struct device_node *icu_np, *np = dev->of_node;
> > + struct of_phandle_args args;
> > + uint32_t dmac_index;
> > + int ret;
> > +
> > + ret = of_parse_phandle_with_fixed_args(np, RZV2H_ICU_PROPERTY, 1, 0, &args);
> > + if (ret)
> > + return ret;
> > +
> > + icu_np = args.np;
> > + dmac_index = args.args[0];
> > +
> > + if (dmac_index > RZV2H_MAX_DMAC_INDEX) {
> > + dev_err(dev, "DMAC index %u invalid.\n", dmac_index);
> > + ret = -EINVAL;
> > + goto free_icu_np;
> > + }
> > +
> > + dmac->icu.pdev = of_find_device_by_node(icu_np);
> > + if (!dmac->icu.pdev) {
> > + dev_err(dev, "ICU device not found.\n");
> > + ret = -ENODEV;
> > + goto free_icu_np;
> > + }
> > +
> > + dmac->icu.dmac_index = dmac_index;
> > +
> > +free_icu_np:
> > + of_node_put(icu_np);
> > +
> > + return ret;
> > +}
> > +
> > static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
> > {
> > struct device_node *np = dev->of_node;
> > @@ -840,6 +960,10 @@ static int rz_dmac_parse_of(struct device *dev, struct rz_dmac *dmac)
> > return -EINVAL;
> > }
> >
> > + dmac->has_icu = of_property_present(np, RZV2H_ICU_PROPERTY);
>
> Doesn't of_parse_phandle_with_fixed_args() in rz_dmac_parse_of_icu()
> return -ENOENT if the property is not present, so you don't have to
> check for presence here?
I'll rework accordingly.
>
> > + if (dmac->has_icu)
> > + return rz_dmac_parse_of_icu(dev, dmac);
> > +
> > return 0;
> > }
> >
>
> > @@ -991,9 +1117,13 @@ static void rz_dmac_remove(struct platform_device *pdev)
> > reset_control_assert(dmac->rstc);
> > pm_runtime_put(&pdev->dev);
> > pm_runtime_disable(&pdev->dev);
> > +
> > + if (dmac->has_icu)
>
> No need to check for a NULL pointer.
Right! I'll take it out.
Thanks!
Fab
>
> > + platform_device_put(dmac->icu.pdev);
> > }
> >
> > static const struct of_device_id of_rz_dmac_match[] = {
> > + { .compatible = "renesas,r9a09g057-dmac", },
> > { .compatible = "renesas,rz-dmac", },
> > { /* Sentinel */ }
> > };
>
> 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH v4 7/7] arm64: dts: renesas: r9a09g057: Add DMAC nodes
2025-02-20 15:01 [PATCH v4 0/7] Add DMAC support to the RZ/V2H(P) Fabrizio Castro
` (5 preceding siblings ...)
2025-02-20 15:01 ` [PATCH v4 6/7] dmaengine: sh: rz-dmac: Add RZ/V2H(P) support Fabrizio Castro
@ 2025-02-20 15:01 ` Fabrizio Castro
2025-02-24 13:30 ` Geert Uytterhoeven
6 siblings, 1 reply; 37+ messages in thread
From: Fabrizio Castro @ 2025-02-20 15:01 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven
Cc: Fabrizio Castro, Magnus Damm, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Lad Prabhakar
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
^ permalink raw reply related [flat|nested] 37+ messages in thread* Re: [PATCH v4 7/7] arm64: dts: renesas: r9a09g057: Add DMAC nodes
2025-02-20 15:01 ` [PATCH v4 7/7] arm64: dts: renesas: r9a09g057: Add DMAC nodes Fabrizio Castro
@ 2025-02-24 13:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 37+ messages in thread
From: Geert Uytterhoeven @ 2025-02-24 13:30 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Lad Prabhakar
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
^ permalink raw reply [flat|nested] 37+ messages in thread