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

[Michal Wilczynski]

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 <db@xxxxxxxxxx>
>> Signed-off-by: Dominique Belhachemi <db@xxxxxxxxxx>
>> Signed-off-by: Michal Wilczynski <m.wilczynski@xxxxxxxxxxx>
> 
> ```
> Tested-by: Icenowy Zheng <zhengxingda@xxxxxxxxxxx>
> ```
> 
> 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 <m.wilczynski@xxxxxxxxxxx>