Re: [RFC PATCH 5/6] riscv: dts: starfive: jh7110: activate XPbmtUC

[Bo Gan <ganboing@gmail.com>]

Hi Conor,

On 3/13/26 06:48, Conor Dooley wrote:
> On Fri, Mar 13, 2026 at 01:44:06AM -0700, Bo Gan wrote:
>> Set riscv,xpbmt-uncache-bit to 32 to match SoC memory map:
>>
>>             [0x0,   0x40000000) Low MMIO
>>      [0x40000000, 0x2_40000000) Cached Mem
>>    [0x4_40000000, 0x6_40000000) Uncached Mem UC+
>>    [0x9_00000000, 0x9_d0000000) High MMIO
>>
>> Signed-off-by: Bo Gan <ganboing@gmail.com>
> 
> 
> What I want know is how this whole setup interacts with the existing
> support that we have for these devices?
> Samuel's patchetset removed from the devicetree all of the nodes related
> to having two mappings of the same memory, and modified the existing
> erratum to only be required for older devicetrees.
> You've not removed them, only added a new property. The non-coherent
> peripherals on jh7110 already work prior to this patchset, is there not
> going to be funky behaviour with both of these things operating in
> parallel?
> 

I just want to clarify that Samuel's change is not touching JH7110, but
*JH7100*. They are very similar chips, can can confuse people sometimes,
but JH7110 evolved to put more devices such as gmac/sdio/usb/pcie through
the front port to make them cache coherent. The left over noncoherent
device are dealt by the driver through cache flushes, I believe. That's
why we have out-of-box support for JH7110 even without Samuel's patch. On
the older JH7100, none of the peripheral is DMA coherent, so we either
use ERRATA_STARFIVE_JH7100, making kernel NONPORTABLE or Samuel's patch.
Refer to this pdf for a detailed comparison:
https://github.com/starfive-tech/JH7100_Docs/blob/main/JH7100%20Cache%20Coherence%20V1.0.pdf

My patch doesn't touch anything JH7100. It's an enhancement to JH7110 (the
newer chip). The issue is that even though basic peripherals are coherent,
the video subsystem, GPU/VPU/ISP... is still not. (See page 6 in that pdf)
Hence technically, we still need to deal with the same issue on JH7110.
E.g., part of the reason we can't have GPU driver working is because we
can't map a DMA page as uncached in userspace. There's no cache flush insn
in userspace, either. This change tries to solve the issue in a simple yet
elegant way.

There's no other changes to the device-tree required, just adding the prop
for JH7110, and things should just work. As for JH7100 (the older chip), I
don't plan to support it, as the cached/uncached region are offsetted by
0xf80000000, so it can't be modeled by a single UC bit (w/o hypervisor
re-mapping it underneath, and there's no H for JH71x0) The chip was also
superseded very quickly after the release of JH7110. I don't imagine too
many users demanding support.

>> ---
>>   arch/riscv/boot/dts/starfive/jh7110.dtsi | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
>> index 6e56e9d20bb06..6dfeb31538fba 100644
>> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
>> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
>> @@ -14,6 +14,7 @@ / {
>>   	compatible = "starfive,jh7110";
>>   	#address-cells = <2>;
>>   	#size-cells = <2>;
>> +	riscv,xpbmt-uncache-bit = <32>;
>>   
>>   	cpus: cpus {
>>   		#address-cells = <1>;
>> -- 
>> 2.34.1
>>

Bo