On 9/29/26 17:06, Icenowy Zheng wrote: > 在 2026-09-15二的 17:32 +0200，Michal Wilczynski写道： >> 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 <[email protected]> >> Signed-off-by: Dominique Belhachemi <[email protected]> >> Signed-off-by: Michal Wilczynski <[email protected]> > > ``` > Tested-by: Icenowy Zheng <[email protected]> > ``` > > But, > >> --- >> 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 <[email protected]>
