Re: [PATCH v4 19/20] riscv: dts: starfive: jh7110: Update DT for display subsystem

On 9/29/26 17:06, Icenowy Zheng wrote:

在 2026-09-15二的 17:32 +0200，Michal Wilczynski写道：

quoted

Activate the display subsystem by describing the video output
subsystem,
which the documentation calls dom_vout_top, as a bus node covering
the
whole 0x29400000 region, with dc8200, the HDMI block, the video
output
system controller and voutcrg as its children.

The subsystem node owns the resources its children share: the NoC
display
bus clock and reset that gate access to every register in the region,
and
the PD_VOUT power domain. Modelling it this way keeps a shared gate
owned
by the block that shares it rather than by whichever consumer happens
to
probe first, and lets dc8200 inherit dma-noncoherent for framebuffer
DMA
from the bus it sits on.

The monolithic hdmi node is in turn modelled as a container with
hdmi_phy
and hdmi_controller children. This lets the PHY (clock provider,
depending only on xin24m) and the controller (clock consumer) probe
independently, breaking the circular clock dependency with voutcrg.

voutcrg consumes the pixel clock from the &hdmi_phy node instead of
the
old fixed-clock, and dc8200 gets its pixel clocks from voutcrg's
MUXes.
The old, incorrect hdmitx0-pixel-clock fixed-clock node is removed.

The HDMI controller gets a phandle to the video output system
controller,
which holds the mux selecting the DC8200 output that drives the HDMI
transmitter.

CMA is enlarged and constrained to memory the display controller can
address, because the default pool is too small for its framebuffers.

Co-developed-by: Dominique Belhachemi <redacted>
Signed-off-by: Dominique Belhachemi <redacted>
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>

Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>

But,

quoted

---
 arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 121
+++++++++++++++++++++++-
 arch/riscv/boot/dts/starfive/jh7110.dtsi        | 105
++++++++++++++++----
 2 files changed, 203 insertions(+), 23 deletions(-)

diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi

b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
index
a7a1c09a2c9075711f3a214a49618911fdc7b421..a4c3daf712a63b177f744e8c613
416d22e0c9dbd 100644

--- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi

@@ -33,6 +33,27 @@ memory@40000000 {
 		bootph-pre-ram;
 	};
 
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/*
+		 * The display controller allocates its framebuffers

from CMA,
+		 * and the default pool is too small for them. Keep
the pool
+		 * inside the range the controller can address; it
fits in the
+		 * memory every VisionFive 2 variant has.
+		 */
+		linux,cma {
+			compatible = "shared-dma-pool";
+			reusable;
+			size = <0x0 0x20000000>;
+			alignment = <0x0 0x1000>;
+			alloc-ranges = <0x0 0x70000000 0x0
0x20000000>;
+			linux,cma-default;
+		};
+	};
+

I don't know whether constraining the CMA pool in the DT is a good
idea.

Thanks,
Icenowy

So I've tested the version without alloc-ranges and some of the modetest
runs failed especially the higher resolutions. It seems this is because
without alloc-ranges __reserved_mem_alloc_size() allocates top down with
MEMBLOCK_ALLOC_ANYWHERE so the pool lands above 4 GB, which the DC8200
cannot reach - vs_dc.c sets a 32-bit DMA mask.

25 of the 42 advertised modes failed with "failed to create dumb buffer:
Cannot allocate memory" - every 4K and 1080p mode, down to 1360x768.
Only 1280x800 and below survive.

So the range seems to be a hardware limit which is why I think it
belongs in the DT. I'd like to keep it in v6.

Best regards,
-- 
Michal Wilczynski [off-list ref]