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
V3:
* impose proper maxItems for each device
* impose maxItems for dmas property
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 | 16 +++++++++++++---
arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 16 ++++++++++++++++
3 files changed, 45 insertions(+), 3 deletions(-)
--
2.52.0
All supported 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.
The DMA core allows specifying multiple DMAs with the same name, and it
will pick the first available one.
There is an exception in the base dt-schema rules specifically for
allowing this behavior (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]
Allow multiple DMAs to have the same name and only restrict the possible
names of the DMA channels, not their count.
For RZ/T2H and RZ/N2H SoCs, limit the number of DMA channels to 6, as
they have 3 DMA controllers.
For RZ/V2H and RZ/V2N SoCs, limit the number of DMA channels to 10, as
they have 5 DMA controllers.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V3:
* impose proper maxItems for each device
* impose maxItems for dmas property
V2:
* new patch
.../bindings/spi/renesas,rzv2h-rspi.yaml | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
On Wed, Jan 28, 2026 at 11:51:30PM +0200, Cosmin Tanislav wrote:
All supported 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.
The DMA core allows specifying multiple DMAs with the same name, and it
will pick the first available one.
There is an exception in the base dt-schema rules specifically for
allowing this behavior (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]
Allow multiple DMAs to have the same name and only restrict the possible
names of the DMA channels, not their count.
For RZ/T2H and RZ/N2H SoCs, limit the number of DMA channels to 6, as
they have 3 DMA controllers.
What's the rationale behind not setting minItems to 6 here
For RZ/V2H and RZ/V2N SoCs, limit the number of DMA channels to 10, as
they have 5 DMA controllers.
and to 10 here? Do any of the spi controllers on these SoCs not have the
ability to use all of the available dma controllers?
quoted hunk
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V3:
* impose proper maxItems for each device
* impose maxItems for dmas property
V2:
* new patch
.../bindings/spi/renesas,rzv2h-rspi.yaml | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
From: Conor Dooley <conor@kernel.org>
Sent: Thursday, January 29, 2026 7:45 PM
On Wed, Jan 28, 2026 at 11:51:30PM +0200, Cosmin Tanislav wrote:
quoted
All supported 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.
The DMA core allows specifying multiple DMAs with the same name, and it
will pick the first available one.
There is an exception in the base dt-schema rules specifically for
allowing this behavior (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]
Allow multiple DMAs to have the same name and only restrict the possible
names of the DMA channels, not their count.
For RZ/T2H and RZ/N2H SoCs, limit the number of DMA channels to 6, as
they have 3 DMA controllers.
What's the rationale behind not setting minItems to 6 here
quoted
For RZ/V2H and RZ/V2N SoCs, limit the number of DMA channels to 10, as
they have 5 DMA controllers.
and to 10 here? Do any of the spi controllers on these SoCs not have the
ability to use all of the available dma controllers?
I left minItems to 2 in case it is necessary to wire up SPI to only a
subset of the DMA controllers, maybe for performance reasons in a
board-specific dts?
I know that dts is only supposed to describe the hardware itself, but for
now this would be the only way to pre-select which DMA controller is used
for a specific IP.
Let me know your thoughts.
quoted
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V3:
* impose proper maxItems for each device
* impose maxItems for dmas property
V2:
* new patch
.../bindings/spi/renesas,rzv2h-rspi.yaml | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
On Thu, Jan 29, 2026 at 05:55:21PM +0000, Cosmin-Gabriel Tanislav wrote:
quoted
From: Conor Dooley <conor@kernel.org>
Sent: Thursday, January 29, 2026 7:45 PM
On Wed, Jan 28, 2026 at 11:51:30PM +0200, Cosmin Tanislav wrote:
quoted
All supported 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.
The DMA core allows specifying multiple DMAs with the same name, and it
will pick the first available one.
There is an exception in the base dt-schema rules specifically for
allowing this behavior (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]
Allow multiple DMAs to have the same name and only restrict the possible
names of the DMA channels, not their count.
For RZ/T2H and RZ/N2H SoCs, limit the number of DMA channels to 6, as
they have 3 DMA controllers.
What's the rationale behind not setting minItems to 6 here
quoted
For RZ/V2H and RZ/V2N SoCs, limit the number of DMA channels to 10, as
they have 5 DMA controllers.
and to 10 here? Do any of the spi controllers on these SoCs not have the
ability to use all of the available dma controllers?
I left minItems to 2 in case it is necessary to wire up SPI to only a
subset of the DMA controllers, maybe for performance reasons in a
board-specific dts?
I know that dts is only supposed to describe the hardware itself, but for
now this would be the only way to pre-select which DMA controller is used
for a specific IP.
Let me know your thoughts.
Yeah, I can buy that argument.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
From: Krzysztof Kozlowski <krzk@kernel.org> Date: 2026-02-18 07:49:52
On 28/01/2026 22:51, Cosmin Tanislav wrote:
quoted hunk
All supported 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.
The DMA core allows specifying multiple DMAs with the same name, and it
will pick the first available one.
There is an exception in the base dt-schema rules specifically for
allowing this behavior (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]
Allow multiple DMAs to have the same name and only restrict the possible
names of the DMA channels, not their count.
For RZ/T2H and RZ/N2H SoCs, limit the number of DMA channels to 6, as
they have 3 DMA controllers.
For RZ/V2H and RZ/V2N SoCs, limit the number of DMA channels to 10, as
they have 5 DMA controllers.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V3:
* impose proper maxItems for each device
* impose maxItems for dmas property
V2:
* new patch
.../bindings/spi/renesas,rzv2h-rspi.yaml | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
As pointed out by Renesas, this is not correct or finished.
I don't understand why Renesas people don't review THEIR own code
instead, but send a patch correcting other un-merged patch.
Really, start working on each other submissions.
NAK
Best regards,
Krzysztof
On Wed, 28 Jan 2026 at 22:52, Cosmin Tanislav
[off-list ref] wrote:
All supported 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.
The DMA core allows specifying multiple DMAs with the same name, and it
will pick the first available one.
There is an exception in the base dt-schema rules specifically for
allowing this behavior (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]
Allow multiple DMAs to have the same name and only restrict the possible
names of the DMA channels, not their count.
For RZ/T2H and RZ/N2H SoCs, limit the number of DMA channels to 6, as
they have 3 DMA controllers.
For RZ/V2H and RZ/V2N SoCs, limit the number of DMA channels to 10, as
they have 5 DMA controllers.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V3:
* impose proper maxItems for each device
* impose maxItems for dmas property
FTR
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
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>
---
V3:
* no changes
V2:
* wire up all DMA controllers
arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
On Wed, 28 Jan 2026 at 22:52, Cosmin Tanislav
[off-list ref] wrote:
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>
Thanks, will queue in renesas-devel for v7.1.
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
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>
---
V3:
* no changes
V2:
* wire up all DMA controllers
arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
On Wed, 28 Jan 2026 at 22:52, Cosmin Tanislav
[off-list ref] wrote:
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>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.1.
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
From: Mark Brown <broonie@kernel.org> Date: 2026-02-25 19:07:45
On Wed, 28 Jan 2026 23:51:29 +0200, Cosmin Tanislav wrote:
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].
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/3] dt-bindings: spi: renesas,rzv2h-rspi: allow multiple DMAs
commit: 4d28f38f64ef69ab27839069ef3346c3c878d137
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark