[RFC PATCH 0/3] soc: renesas: Add address extension support for RZ/V2H
Biju Das
biju.das.jz at bp.renesas.com
Tue Nov 3 09:57:03 PST 2026
Hi All,
> -----Original Message-----
> From: Prabhakar <prabhakar.csengg at gmail.com>
> Sent: 09 September 2026 20:37
> Subject: [RFC PATCH 0/3] soc: renesas: Add address extension support for RZ/V2H
>
> 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.
On RZ/G3E, I haven't used restricted-dma-pool.
With u-boot configuring
mw 0x10430540 0x03020104
mw 0x10430544 0x03020104
mw 0x10430548 0x03020104
and with the DTS change below, I see performance improvement on eMMC/SDHI interface on RZ/G3E.
This avoids swiotlb during DMA transfer as all memory is DMA capable.
+ sdhi_bus: sdhi-bus {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges = <0x0 0x48000000 0x0 0x48000000 0x0 0xb8000000>,
+ <0x0 0x00000000 0x1 0x00000000 0x0 0x40000000>;
then
cat /sys/block/mmcblk0/queue/max_hw_sectors_kb
4194303
This results in performance boost with mmc_test
eMMC (HS200 Mode)
Read: 182 MB/s vs 138 MB/s(without address extension)
Write : 135 MB/s vs 58 MB/s
SDR104:
Read: 95 MB/s vs 88 MB/s
Write: 88 MB/s vs 40 MB/se
Cheers,
Biju
>
> 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