[PATCH v2 0/3] Add DMA support for RZ/T2H RSPI

[PATCH v2 0/3] Add DMA support for RZ/T2H RSPI

[Cosmin Tanislav]

The DMA controller can be used to transfer data to and from the SPI
controller without involving the CPU for each word of a SPI transfer.

Add support for DMA mode, and do some other cleanups while touching the
same code.

The dts changes in this series depend on the DMA series [1].

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

V2:
 * drop patches picked up by Mark
 * add new dt-bindings patch to allow multiple DMAs
 * wire up all DMA controllers for every SPI controller

Cosmin Tanislav (3):
  dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs
  arm64: dts: renesas: r9a09g077: wire up DMA support for SPI
  arm64: dts: renesas: r9a09g087: wire up DMA support for SPI

 .../bindings/spi/renesas,rzv2h-rspi.yaml         | 10 ++++++----
 arch/arm64/boot/dts/renesas/r9a09g077.dtsi       | 16 ++++++++++++++++
 arch/arm64/boot/dts/renesas/r9a09g087.dtsi       | 16 ++++++++++++++++
 3 files changed, 38 insertions(+), 4 deletions(-)

-- 
2.52.0

[PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Cosmin Tanislav]

The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
can be used with the RSPI peripheral. The current bindings only allow a
single pair of RX and TX DMAs.

Allow multiple DMAs by only restricting the possible names of the DMA
channels.

All '.*-names$' properties must conform to the string-array.yaml
meta-schema, which requires both minItems and maxItems properties to be
present before the items can be a schema. Otherwise, the items need to
be an array.

Declare a generous maxItems of 32, which should be enough for 16 DMA
controllers, so that we don't have to update this value ever again, even
if currently the maximum number of DMA controllers on a Renesas SoC is
5.

Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---

V2:
 * new patch

 .../devicetree/bindings/spi/renesas,rzv2h-rspi.yaml    | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
index a588b112e11e..383e97f0dabd 100644
--- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
+++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
@@ -57,13 +57,15 @@ properties:
       - const: presetn
       - const: tresetn
 
-  dmas:
-    maxItems: 2
+  dmas: true
 
   dma-names:
+    minItems: 2
+    maxItems: 32
     items:
-      - const: rx
-      - const: tx
+      enum:
+        - rx
+        - tx
 
   power-domains:
     maxItems: 1
-- 
2.52.0

Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Conor Dooley]

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

On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> can be used with the RSPI peripheral. The current bindings only allow a
> single pair of RX and TX DMAs.
> 
> Allow multiple DMAs by only restricting the possible names of the DMA
> channels.
> 

> All '.*-names$' properties must conform to the string-array.yaml
> meta-schema, which requires both minItems and maxItems properties to be
> present before the items can be a schema. Otherwise, the items need to
> be an array.

Why is this in the commit message?

> 
> Declare a generous maxItems of 32, which should be enough for 16 DMA
> controllers, so that we don't have to update this value ever again, even
> if currently the maximum number of DMA controllers on a Renesas SoC is
> 5.

Huh, No. The binding should constrain this to fit what the actual
devices do.


> 
> Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> ---
> 
> V2:
>  * new patch
> 
>  .../devicetree/bindings/spi/renesas,rzv2h-rspi.yaml    | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> index a588b112e11e..383e97f0dabd 100644
> --- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> @@ -57,13 +57,15 @@ properties:
>        - const: presetn
>        - const: tresetn
>  
> -  dmas:
> -    maxItems: 2
> +  dmas: true

This should have the same constraints as dma-names. You've now allowed
this to have 1 and 33 dmas, because there's no requirement to have
dma-names when you have dmas.

>  
>    dma-names:
> +    minItems: 2
> +    maxItems: 32
>      items:
> -      - const: rx
> -      - const: tx
> +      enum:
> +        - rx
> +        - tx

You've changed this to allow 32 dma-names, but they all need to be
called either "rx" or "tx", how is a driver meant to use dma-names to
get the second pair of dma channels? Shouldn't anything in excess of the
first two start getting numbers appended so that a driver can actually
request them?

pw-bot: changes-requested

Conor.

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

RE: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Cosmin-Gabriel Tanislav]

Hi Conor, thank you for your response.

> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, January 28, 2026 8:09 PM
> 
> On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> > The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> > can be used with the RSPI peripheral. The current bindings only allow a
> > single pair of RX and TX DMAs.
> >
> > Allow multiple DMAs by only restricting the possible names of the DMA
> > channels.
> >
> 
> > All '.*-names$' properties must conform to the string-array.yaml
> > meta-schema, which requires both minItems and maxItems properties to be
> > present before the items can be a schema. Otherwise, the items need to
> > be an array.
> 
> Why is this in the commit message?
> 

To provide a context for the maxItems that are needed below, even if
there's not really a maximum. Which is why having a maxItems does not
really make sense but it is expected by the meta-schema so we can
constrain the names of the DMA channels.

dtschema/meta-schemas/string-array.yaml:

if:
  not:
    required:
      - minItems
      - maxItems
then:
  properties:
    items:
      type: array

> >
> > Declare a generous maxItems of 32, which should be enough for 16 DMA
> > controllers, so that we don't have to update this value ever again, even
> > if currently the maximum number of DMA controllers on a Renesas SoC is
> > 5.
> 
> Huh, No. The binding should constrain this to fit what the actual
> devices do.
> 

Should the binding for SPI be updated if a device ever comes up with
6 DMA controllers? It seems a bit unrelated to me. In this case, should
we constrain the number of dmas and dma-names per SoC? Some may have 2
DMA controllers, while others may have 5. Please let me know your
thoughts, taking into account that I only added maxItems to satisfy the
meta-schema.

> 
> >
> > Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> > ---
> >
> > V2:
> >  * new patch
> >
> >  .../devicetree/bindings/spi/renesas,rzv2h-rspi.yaml    | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > index a588b112e11e..383e97f0dabd 100644
> > --- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > @@ -57,13 +57,15 @@ properties:
> >        - const: presetn
> >        - const: tresetn
> >
> > -  dmas:
> > -    maxItems: 2
> > +  dmas: true
> 
> This should have the same constraints as dma-names. You've now allowed
> this to have 1 and 33 dmas, because there's no requirement to have
> dma-names when you have dmas.
> 

I agree, I will fix it for V2 once you decide how to proceed with the
other comments.

> >
> >    dma-names:
> > +    minItems: 2
> > +    maxItems: 32
> >      items:
> > -      - const: rx
> > -      - const: tx
> > +      enum:
> > +        - rx
> > +        - tx
> 
> You've changed this to allow 32 dma-names, but they all need to be
> called either "rx" or "tx", how is a driver meant to use dma-names to
> get the second pair of dma channels? Shouldn't anything in excess of the
> first two start getting numbers appended so that a driver can actually
> request them?
> 

The DMA core handles multiple DMA channels with the same name by checking
their availability consecutively until finding an available one.

I agree that this is not pretty but this pattern is already used in the
bindings / device tree for many Renesas IPs.

There's even an exception inside dt-schema specifically for this.

dtschema/schemas/dma/dma.yaml:
  dma-names:
    anyOf:
      - uniqueItems: true
      - items:
          # Hack around Renesas bindings which repeat entries to support
          # multiple possible DMA providers
          enum: [rx, tx]

> pw-bot: changes-requested
> 
> Conor.

Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Conor Dooley]

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

On Wed, Jan 28, 2026 at 06:51:48PM +0000, Cosmin-Gabriel Tanislav wrote:
> Hi Conor, thank you for your response.
> 
> > From: Conor Dooley <conor@kernel.org>
> > Sent: Wednesday, January 28, 2026 8:09 PM
> > 
> > On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> > > The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> > > can be used with the RSPI peripheral. The current bindings only allow a
> > > single pair of RX and TX DMAs.
> > >
> > > Allow multiple DMAs by only restricting the possible names of the DMA
> > > channels.
> > >
> > 
> > > All '.*-names$' properties must conform to the string-array.yaml
> > > meta-schema, which requires both minItems and maxItems properties to be
> > > present before the items can be a schema. Otherwise, the items need to
> > > be an array.
> > 
> > Why is this in the commit message?
> > 
> 
> To provide a context for the maxItems that are needed below, even if
> there's not really a maximum. Which is why having a maxItems does not
> really make sense but it is expected by the meta-schema so we can
> constrain the names of the DMA channels.
> 
> dtschema/meta-schemas/string-array.yaml:
> 
> if:
>   not:
>     required:
>       - minItems
>       - maxItems
> then:
>   properties:
>     items:
>       type: array

Right. You can probably remove all that since I'm asking you to add
actual constraints to the property.

> > > Declare a generous maxItems of 32, which should be enough for 16 DMA
> > > controllers, so that we don't have to update this value ever again, even
> > > if currently the maximum number of DMA controllers on a Renesas SoC is
> > > 5.
> > 
> > Huh, No. The binding should constrain this to fit what the actual
> > devices do.
> > 
> 
> Should the binding for SPI be updated if a device ever comes up with
> 6 DMA controllers? It seems a bit unrelated to me. In this case, should
> we constrain the number of dmas and dma-names per SoC? Some may have 2
> DMA controllers, while others may have 5. Please let me know your
> thoughts, taking into account that I only added maxItems to satisfy the
> meta-schema.

Yes, I think you should constrain it to the correct number of providers
for each device.
Whether that's done or not, there's not all that much reason to set it
above whatever the current maximum is, since the binding will have to be
updated to add the compatible for whatever device exceeds the current max
and the limit can be increased then.

> > > Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> > > ---
> > >
> > > V2:
> > >  * new patch
> > >
> > >  .../devicetree/bindings/spi/renesas,rzv2h-rspi.yaml    | 10 ++++++----
> > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > index a588b112e11e..383e97f0dabd 100644
> > > --- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > @@ -57,13 +57,15 @@ properties:
> > >        - const: presetn
> > >        - const: tresetn
> > >
> > > -  dmas:
> > > -    maxItems: 2
> > > +  dmas: true
> > 
> > This should have the same constraints as dma-names. You've now allowed
> > this to have 1 and 33 dmas, because there's no requirement to have
> > dma-names when you have dmas.
> > 
> 
> I agree, I will fix it for V2 once you decide how to proceed with the
> other comments.
> 
> > >
> > >    dma-names:
> > > +    minItems: 2
> > > +    maxItems: 32
> > >      items:
> > > -      - const: rx
> > > -      - const: tx
> > > +      enum:
> > > +        - rx
> > > +        - tx
> > 
> > You've changed this to allow 32 dma-names, but they all need to be
> > called either "rx" or "tx", how is a driver meant to use dma-names to
> > get the second pair of dma channels? Shouldn't anything in excess of the
> > first two start getting numbers appended so that a driver can actually
> > request them?
> > 
> 
> The DMA core handles multiple DMA channels with the same name by checking
> their availability consecutively until finding an available one.

TIL

> I agree that this is not pretty but this pattern is already used in the
> bindings / device tree for many Renesas IPs.
> 
> There's even an exception inside dt-schema specifically for this.

Hmm, I see. Can you please put this into the commit message cos otherwise
this looks really strange!

> 
> dtschema/schemas/dma/dma.yaml:
>   dma-names:
>     anyOf:
>       - uniqueItems: true
>       - items:
>           # Hack around Renesas bindings which repeat entries to support
>           # multiple possible DMA providers
>           enum: [rx, tx]
> 
> > pw-bot: changes-requested
> > 
> > Conor.

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

RE: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Cosmin-Gabriel Tanislav]

> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, January 28, 2026 10:09 PM
> 
> On Wed, Jan 28, 2026 at 06:51:48PM +0000, Cosmin-Gabriel Tanislav wrote:
> > Hi Conor, thank you for your response.
> >
> > > From: Conor Dooley <conor@kernel.org>
> > > Sent: Wednesday, January 28, 2026 8:09 PM
> > >
> > > On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> > > > The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> > > > can be used with the RSPI peripheral. The current bindings only allow a
> > > > single pair of RX and TX DMAs.
> > > >
> > > > Allow multiple DMAs by only restricting the possible names of the DMA
> > > > channels.
> > > >
> > >
> > > > All '.*-names$' properties must conform to the string-array.yaml
> > > > meta-schema, which requires both minItems and maxItems properties to be
> > > > present before the items can be a schema. Otherwise, the items need to
> > > > be an array.
> > >
> > > Why is this in the commit message?
> > >
> >
> > To provide a context for the maxItems that are needed below, even if
> > there's not really a maximum. Which is why having a maxItems does not
> > really make sense but it is expected by the meta-schema so we can
> > constrain the names of the DMA channels.
> >
> > dtschema/meta-schemas/string-array.yaml:
> >
> > if:
> >   not:
> >     required:
> >       - minItems
> >       - maxItems
> > then:
> >   properties:
> >     items:
> >       type: array
> 
> Right. You can probably remove all that since I'm asking you to add
> actual constraints to the property.
> 

Okay.

> > > > Declare a generous maxItems of 32, which should be enough for 16 DMA
> > > > controllers, so that we don't have to update this value ever again, even
> > > > if currently the maximum number of DMA controllers on a Renesas SoC is
> > > > 5.
> > >
> > > Huh, No. The binding should constrain this to fit what the actual
> > > devices do.
> > >
> >
> > Should the binding for SPI be updated if a device ever comes up with
> > 6 DMA controllers? It seems a bit unrelated to me. In this case, should
> > we constrain the number of dmas and dma-names per SoC? Some may have 2
> > DMA controllers, while others may have 5. Please let me know your
> > thoughts, taking into account that I only added maxItems to satisfy the
> > meta-schema.
> 
> Yes, I think you should constrain it to the correct number of providers
> for each device.
> Whether that's done or not, there's not all that much reason to set it
> above whatever the current maximum is, since the binding will have to be
> updated to add the compatible for whatever device exceeds the current max
> and the limit can be increased then.
> 

Okay, I will submit V2 with per-device maxItems for dmas and dma-names.
minItems should probably stay at 2 to allow a specific setup if required.

> > > > Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> > > > ---
> > > >
> > > > V2:
> > > >  * new patch
> > > >
> > > >  .../devicetree/bindings/spi/renesas,rzv2h-rspi.yaml    | 10 ++++++----
> > > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > > index a588b112e11e..383e97f0dabd 100644
> > > > --- a/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > > +++ b/Documentation/devicetree/bindings/spi/renesas,rzv2h-rspi.yaml
> > > > @@ -57,13 +57,15 @@ properties:
> > > >        - const: presetn
> > > >        - const: tresetn
> > > >
> > > > -  dmas:
> > > > -    maxItems: 2
> > > > +  dmas: true
> > >
> > > This should have the same constraints as dma-names. You've now allowed
> > > this to have 1 and 33 dmas, because there's no requirement to have
> > > dma-names when you have dmas.
> > >
> >
> > I agree, I will fix it for V2 once you decide how to proceed with the
> > other comments.
> >
> > > >
> > > >    dma-names:
> > > > +    minItems: 2
> > > > +    maxItems: 32
> > > >      items:
> > > > -      - const: rx
> > > > -      - const: tx
> > > > +      enum:
> > > > +        - rx
> > > > +        - tx
> > >
> > > You've changed this to allow 32 dma-names, but they all need to be
> > > called either "rx" or "tx", how is a driver meant to use dma-names to
> > > get the second pair of dma channels? Shouldn't anything in excess of the
> > > first two start getting numbers appended so that a driver can actually
> > > request them?
> > >
> >
> > The DMA core handles multiple DMA channels with the same name by checking
> > their availability consecutively until finding an available one.
> 
> TIL
> 
> > I agree that this is not pretty but this pattern is already used in the
> > bindings / device tree for many Renesas IPs.
> >
> > There's even an exception inside dt-schema specifically for this.
> 
> Hmm, I see. Can you please put this into the commit message cos otherwise
> this looks really strange!
> 

Sure thing.

> >
> > dtschema/schemas/dma/dma.yaml:
> >   dma-names:
> >     anyOf:
> >       - uniqueItems: true
> >       - items:
> >           # Hack around Renesas bindings which repeat entries to support
> >           # multiple possible DMA providers
> >           enum: [rx, tx]
> >
> > > pw-bot: changes-requested
> > >
> > > Conor.

Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Geert Uytterhoeven]

Hi Conor,

On Wed, 28 Jan 2026 at 21:09, Conor Dooley <conor@kernel.org> wrote:
> On Wed, Jan 28, 2026 at 06:51:48PM +0000, Cosmin-Gabriel Tanislav wrote:
> > > From: Conor Dooley <conor@kernel.org>

> > > On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> > > > The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> > > > can be used with the RSPI peripheral. The current bindings only allow a
> > > > single pair of RX and TX DMAs.
> > > >
> > > > Allow multiple DMAs by only restricting the possible names of the DMA
> > > > channels.
> > >
> > > > All '.*-names$' properties must conform to the string-array.yaml
> > > > meta-schema, which requires both minItems and maxItems properties to be
> > > > present before the items can be a schema. Otherwise, the items need to
> > > > be an array.
> > >
> > > Why is this in the commit message?
> >
> > To provide a context for the maxItems that are needed below, even if
> > there's not really a maximum. Which is why having a maxItems does not
> > really make sense but it is expected by the meta-schema so we can
> > constrain the names of the DMA channels.
> >
> > dtschema/meta-schemas/string-array.yaml:
> >
> > if:
> >   not:
> >     required:
> >       - minItems
> >       - maxItems
> > then:
> >   properties:
> >     items:
> >       type: array
>
> Right. You can probably remove all that since I'm asking you to add
> actual constraints to the property.
>
> > > > Declare a generous maxItems of 32, which should be enough for 16 DMA
> > > > controllers, so that we don't have to update this value ever again, even
> > > > if currently the maximum number of DMA controllers on a Renesas SoC is
> > > > 5.
> > >
> > > Huh, No. The binding should constrain this to fit what the actual
> > > devices do.

The device is the SPI controller, or the SoC where the SPI controller
is integrated?

> >
> > Should the binding for SPI be updated if a device ever comes up with
> > 6 DMA controllers? It seems a bit unrelated to me. In this case, should
> > we constrain the number of dmas and dma-names per SoC? Some may have 2
> > DMA controllers, while others may have 5. Please let me know your
> > thoughts, taking into account that I only added maxItems to satisfy the
> > meta-schema.
>
> Yes, I think you should constrain it to the correct number of providers
> for each device.
> Whether that's done or not, there's not all that much reason to set it
> above whatever the current maximum is, since the binding will have to be
> updated to add the compatible for whatever device exceeds the current max
> and the limit can be increased then.

The actual maximum number of dmas pairs does not depend on the SPI
controller, but on the SoC integration.  I think the (single) DMA
request signal from the SPI controller is just wired to all DMACs
present (on this SoC, IIRC there were some Renesas SoCs where some
 DMA clients are wired to only a single DMAC).

Gr{oetje,eeting}s,

                        Geert

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

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

Re: [PATCH v2 1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs

[Conor Dooley]

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

On Thu, Jan 29, 2026 at 09:04:45AM +0100, Geert Uytterhoeven wrote:
> Hi Conor,
> 
> On Wed, 28 Jan 2026 at 21:09, Conor Dooley <conor@kernel.org> wrote:
> > On Wed, Jan 28, 2026 at 06:51:48PM +0000, Cosmin-Gabriel Tanislav wrote:
> > > > From: Conor Dooley <conor@kernel.org>
> 
> > > > On Tue, Jan 27, 2026 at 10:17:04PM +0200, Cosmin Tanislav wrote:
> > > > > The Renesas RZ/T2H and RZ/N2H SoCs have multiple DMA controllers that
> > > > > can be used with the RSPI peripheral. The current bindings only allow a
> > > > > single pair of RX and TX DMAs.
> > > > >
> > > > > Allow multiple DMAs by only restricting the possible names of the DMA
> > > > > channels.
> > > >
> > > > > All '.*-names$' properties must conform to the string-array.yaml
> > > > > meta-schema, which requires both minItems and maxItems properties to be
> > > > > present before the items can be a schema. Otherwise, the items need to
> > > > > be an array.
> > > >
> > > > Why is this in the commit message?
> > >
> > > To provide a context for the maxItems that are needed below, even if
> > > there's not really a maximum. Which is why having a maxItems does not
> > > really make sense but it is expected by the meta-schema so we can
> > > constrain the names of the DMA channels.
> > >
> > > dtschema/meta-schemas/string-array.yaml:
> > >
> > > if:
> > >   not:
> > >     required:
> > >       - minItems
> > >       - maxItems
> > > then:
> > >   properties:
> > >     items:
> > >       type: array
> >
> > Right. You can probably remove all that since I'm asking you to add
> > actual constraints to the property.
> >
> > > > > Declare a generous maxItems of 32, which should be enough for 16 DMA
> > > > > controllers, so that we don't have to update this value ever again, even
> > > > > if currently the maximum number of DMA controllers on a Renesas SoC is
> > > > > 5.
> > > >
> > > > Huh, No. The binding should constrain this to fit what the actual
> > > > devices do.
> 
> The device is the SPI controller, or the SoC where the SPI controller
> is integrated?

Whether the SoC's number of dma controllers is the limiter or whether it's
the number of inputs to the spi controller isn't something I know the
answer to (and which it is in theory could vary between SoCs), so I used
device instead of "SoC integration of the spi controller represented by
a given compatible".

> > > Should the binding for SPI be updated if a device ever comes up with
> > > 6 DMA controllers? It seems a bit unrelated to me. In this case, should
> > > we constrain the number of dmas and dma-names per SoC? Some may have 2
> > > DMA controllers, while others may have 5. Please let me know your
> > > thoughts, taking into account that I only added maxItems to satisfy the
> > > meta-schema.
> >
> > Yes, I think you should constrain it to the correct number of providers
> > for each device.
> > Whether that's done or not, there's not all that much reason to set it
> > above whatever the current maximum is, since the binding will have to be
> > updated to add the compatible for whatever device exceeds the current max
> > and the limit can be increased then.
> 
> The actual maximum number of dmas pairs does not depend on the SPI
> controller, but on the SoC integration.  I think the (single) DMA
> request signal from the SPI controller is just wired to all DMACs
> present (on this SoC, IIRC there were some Renesas SoCs where some
>  DMA clients are wired to only a single DMAC).

Right, that's largely what I had gathered from Cosmin-Gabriel's comments
and the patch itself. I think the comments I made here are all still
applicable? If there's a new SoC, there'll be a new compatible for the
spi controller's integration on that SoC and the limit can be bumped
then.

Cheers,
Conor.


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

[PATCH v2 2/3] arm64: dts: renesas: r9a09g077: wire up DMA support for SPI

[Cosmin Tanislav]

RZ/T2H (R9A09G077) has three DMA controllers that can be used by
peripherals like SPI to offload data transfers from the CPU.

Wire up the DMA channels for the SPI peripherals.

Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---

V2:
 * wire up all DMA controllers

 arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
index 14d7fb6f8952..0e44b01a56c7 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
@@ -200,6 +200,10 @@ rspi0: spi@80007000 {
 			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKM>,
 				 <&cpg CPG_MOD 104>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x267a>, <&dmac0 0x267b>,
+			       <&dmac1 0x267a>, <&dmac1 0x267b>,
+			       <&dmac2 0x267a>, <&dmac2 0x267b>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -218,6 +222,10 @@ rspi1: spi@80007400 {
 			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKM>,
 				 <&cpg CPG_MOD 105>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x267f>, <&dmac0 0x2680>,
+			       <&dmac1 0x267f>, <&dmac1 0x2680>,
+			       <&dmac2 0x267f>, <&dmac2 0x2680>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -236,6 +244,10 @@ rspi2: spi@80007800 {
 			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKM>,
 				 <&cpg CPG_MOD 106>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x2684>, <&dmac0 0x2685>,
+			       <&dmac1 0x2684>, <&dmac1 0x2685>,
+			       <&dmac2 0x2684>, <&dmac2 0x2685>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -254,6 +266,10 @@ rspi3: spi@81007000 {
 			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKM>,
 				 <&cpg CPG_MOD 602>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x2689>, <&dmac0 0x268a>,
+			       <&dmac1 0x2689>, <&dmac1 0x268a>,
+			       <&dmac2 0x2689>, <&dmac2 0x268a>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
-- 
2.52.0

[PATCH v2 3/3] arm64: dts: renesas: r9a09g087: wire up DMA support for SPI

[Cosmin Tanislav]

RZ/N2H (R9A09G087) has three DMA controllers that can be used by
peripherals like SPI to offload data transfers from the CPU.

Wire up the DMA channels for the SPI peripherals.

Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---

V2:
 * wire up all DMA controllers

 arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
index 4a1339561332..7d1c669ad262 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
@@ -200,6 +200,10 @@ rspi0: spi@80007000 {
 			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKM>,
 				 <&cpg CPG_MOD 104>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x267a>, <&dmac0 0x267b>,
+			       <&dmac1 0x267a>, <&dmac1 0x267b>,
+			       <&dmac2 0x267a>, <&dmac2 0x267b>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -218,6 +222,10 @@ rspi1: spi@80007400 {
 			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKM>,
 				 <&cpg CPG_MOD 105>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x267f>, <&dmac0 0x2680>,
+			       <&dmac1 0x267f>, <&dmac1 0x2680>,
+			       <&dmac2 0x267f>, <&dmac2 0x2680>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -236,6 +244,10 @@ rspi2: spi@80007800 {
 			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKM>,
 				 <&cpg CPG_MOD 106>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x2684>, <&dmac0 0x2685>,
+			       <&dmac1 0x2684>, <&dmac1 0x2685>,
+			       <&dmac2 0x2684>, <&dmac2 0x2685>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -254,6 +266,10 @@ rspi3: spi@81007000 {
 			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKM>,
 				 <&cpg CPG_MOD 602>;
 			clock-names = "pclk", "pclkspi";
+			dmas = <&dmac0 0x2689>, <&dmac0 0x268a>,
+			       <&dmac1 0x2689>, <&dmac1 0x268a>,
+			       <&dmac2 0x2689>, <&dmac2 0x268a>;
+			dma-names = "rx", "tx", "rx", "tx", "rx", "tx";
 			power-domains = <&cpg>;
 			#address-cells = <1>;
 			#size-cells = <0>;
-- 
2.52.0