[RFC PATCH 0/3] soc: renesas: Add address extension support for RZ/V2H
Prabhakar
prabhakar.csengg at gmail.com
Wed Sep 9 12:36:36 PDT 2026
From: Lad Prabhakar <prabhakar.mahadev-lad.rj at bp.renesas.com>
Hi all,
This series adds support for the SYS_AOF (Address Offset Function)
address extension mechanism on RZ/V2H, and enables it for the SDHI
internal DMAC so SD/eMMC DMA buffers are no longer confined to the
low 4 GiB of physical memory.
Background
==========
RZ/V2H contains bus masters (SDHI, USB, GBETH, VCD, DSI, LCDC, ISP,
DMAC, ...) that can only generate a 32-bit address on their own
bus. The SYS controller's SYS_AOFn registers let bits [31:30] of the
address such a master issues select one of four independently
configurable 6-bit fields; the selected field supplies the
corresponding upper bits ([34:30] or [35:30]) actually driven onto
the AXI interconnect, with bits [29:0] passed straight through. This
splits each master's native 4 GiB space into four relocatable 1 GiB
windows, letting it reach a 35-bit (DDR0/DDR1) or 36-bit (+PCIe0/
PCIe1) physical address space. See RZ/V2H Group Hardware User's
Manual, Figure 1.7-2 and Sections 1.7.3.2 and 4.3.3.2.88-90,
reproduced here in text form:
+--------------------+
| Master |
| 32-bit address |
| [31:0] |
+----------+---------+
|
+-----------------+-------------------+
| bits [31:30] | bits [29:0]
| select field | passed through
v |
+---------------------------------+ |
| SYS_AOFn register | |
| +------+------+------+------+ | |
| | Reg3 | Reg2 | Reg1 | Reg0 | | |
| | 11 | 10 | 01 | 00 | | |
| +--+---+--+---+--+---+--+---+ | |
+-----|------|------|------|------+ |
+------+------+------+ supplies |
| [35:30] or [34:30] |
v v
+-------------------------------------+
| AXI interconnect |
| 35- or 36-bit address |
+--------------------+----------------+
|
v
+-----------------------------------------------------+
| Physical address space |
| F_FFFF_FFFFh +-----------------------------------+ |
| | PCIe1 - 23 GiB | |
| A_4000_0000h +-----------------------------------+ |
| | PCIe0 - 24 GiB | |
| 4_4000_0000h +-----------------------------------+ |
| | DDR1 - 8 GiB | |
| 2_4000_0000h +-----------------------------------+ |
| | DDR0 - 8 GiB | |
| 0_4000_0000h +-----------------------------------+ |
| | SRAM, peripheral, xSPI - 1 GiB | |
| 0_0000_0000h +-----------------------------------+ |
+-----------------------------------------------------+
Four 1 GiB windows, each independently redirectable to
any 1 GiB-aligned target above; 35-bit-limited masters
must keep bit [5] of every field clear (1.7.3.2.1).
In case the image isnt formatted correctly please refer the link
https://raw.githubusercontent.com/prabhakarlad/img/refs/heads/main/Screenshot%202026-08-12%20162004.png
Without this, SDHI (and other masters in the same category) are
limited to buffers in the low 4 GiB.
Approach
========
Rather than hardcoding SYS_AOFn programming per board, this series
derives it from the devicetree dma-ranges property already used to
describe DMA address translation:
- Patch 1 adds generic AOF parsing/programming infrastructure to
the rz-sysc driver. Each SoC lists its AOF-capable masters as
(MMIO base, SYS_AOFn index, address width) tuples; at probe time,
the driver walks "simple-bus" wrapper nodes carrying a dma-ranges
property, matches the wrapped device against that table by MMIO
base, and programs the corresponding SYS_AOFn fields directly
from the dma-ranges translation. Devices with status = "disabled"
are skipped. Malformed or out-of-range entries (misaligned,
exceeding the master's own 4 GiB space, or requiring bit [5] on a
35-bit-limited master) are rejected.
- Patch 2 moves the SDHI nodes in r9a09g057.dtsi into per-instance
simple-bus wrapper nodes with a default, no-op (DDR0-targeting)
dma-ranges -- no functional change for boards that don't further
override it.
- Patch 3 demonstrates a non-default window on the RZ/V2H EVK:
SDHI1's dma-ranges is pointed at an 8-12 GiB DDR1 window, backed
by a restricted-dma-pool reserved-memory region so buffers handed
to SDHI1 are guaranteed to physically land inside the range the
programmed SYS_AOF17 fields can actually reach.
Boards that do not override an SDHI instance's dma-ranges see no
functional change: the default wrapper mapping added in patch 3 is
an identity remap onto DDR0's native address.
Trade-offs
==========
- Attaching a restricted-dma-pool to a device makes every DMA transfer
for that device bounce unconditionally (is_swiotlb_force_bounce()),
regardless of whether the buffer's physical address would otherwise
have been directly usable.
- Each master will require a restricted-dma-pool.
Testing
=======
Tested on the RZ/V2H EVK (r9a09g057h44-rzv2h-evk) with SDHI1 remapped
to an 8-12 GiB DDR1 window, running repeated large-file dd read/write
and mmc_test against an SD card, with no functional errors observed.
While running mmc_test a loss of ~4% was seen for read/write tests as
the mmc_test module allocated the memory using GFP_DMA flag.
This series does not yet cover the remaining AOF-capable masters
(USB, GBETH, VCD/DSI/LCDC/ISP, DMAC channels).
Request for feedback
=====================
The ~4% loss above comes from restricted-dma-pool's unconditional
bounce policy (is_swiotlb_force_bounce()): every SDHI transfer is
copied through the pool, even when the source buffer's physical
address would already have been usable without any copy at all.
This is a direct consequence of using restricted-dma-pool as the
correctness mechanism for a device whose real addressing constraint
doesn't map onto the flat dma_mask/dma-ranges model the generic DMA
layer otherwise assumes.
Before optimizing this further, I'd like inputs on whether
restricted-dma-pool is the right tool here. Suggestions and pointers
to prior art for similar SoC address-extension/aperture hardware would
be very welcome.
Thanks for reviewing.
Cheers,
Prabhakar
Lad Prabhakar (3):
soc: renesas: rz-sysc: Configure AOF registers from dma-ranges
arm64: dts: renesas: r9a09g057: Move SDHI nodes into bus nodes
arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Move SDHI1 dma range from
8-12 GiB
arch/arm64/boot/dts/renesas/r9a09g057.dtsi | 123 +++++++++++-------
.../dts/renesas/r9a09g057h44-rzv2h-evk.dts | 16 +++
drivers/soc/renesas/r9a09g057-sys.c | 9 ++
drivers/soc/renesas/rz-sysc.c | 118 +++++++++++++++++
drivers/soc/renesas/rz-sysc.h | 22 ++++
5 files changed, 240 insertions(+), 48 deletions(-)
--
2.55.0
More information about the linux-arm-kernel
mailing list