Hi Niklas,

On 06/11/2025 10:39, Niklas Söderlund wrote:
> Hi Matt,
> 
> Thanks for your feedback.
> 
> On 2025-11-06 10:19:13 +0000, Matt Coster wrote:
>> Hi Niklas,
>>
>> On 05/11/2025 23:27, Niklas Söderlund wrote:
>>> Describe Imagination Technologies PowerVR Rogue GE7800 BNVC 15.5.1.64
>>> present in Renesas R-Car R8A779A0 V3U SoC.
>>>
>>> Signed-off-by: Niklas Söderlund <[email protected]>
>>> ---
>>>  arch/arm64/boot/dts/renesas/r8a779a0.dtsi | 17 +++++++++++++++++
>>>  1 file changed, 17 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi 
>>> b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
>>> index b08865841476..aa347b699340 100644
>>> --- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
>>> +++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
>>> @@ -338,6 +338,23 @@ cmt3: timer@e6148000 {
>>>                     status = "disabled";
>>>             };
>>>  
>>> +           gsx: gsx@fd000000 {
>>
>> Why gsx? Marek's equivalent patch for r8a77965-gpu[1] used gpu (as we do
>> for every dt so far).
> 
> Wops, will fix.
> 
>>
>>> +                   compatible = "renesas,r8a779a0-gpu",
>>> +                                "img,img-ge7800",
>>> +                                "img,img-rogue";
>>> +                   reg = <0 0xfd000000 0 0x40000>;
>>> +                   interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
>>> +                   clocks = <&cpg CPG_CORE R8A779A0_CLK_ZG>,
>>> +                            <&cpg CPG_CORE R8A779A0_CLK_S3D1>,
>>> +                            <&cpg CPG_MOD 0>;
>>
>> I don't have access to a TRM for V3U (it's too new apparently, despite
>> already being obsolete), but I believe the GPU integration should be
>> similar to the M3N in [1]. In that case, the TRM (v2.40, fig 23.3) shows
>> S2D1 and 112 in place of S3D1 and 0 – are these definitely correct? The
>> 0 especially feels wrong (see also 8A.2.1.2 MSTPSR1).
> 
> Yea the V3U doc I have is not the latest. The diagram in the GPU chapter 
> list the same as you say here (S2D1 and 112), however the diagram seems 
> to just be a copy-past of the Gen3 document. Looking elsewhere in the 
> document I see:
> 
> - In the clock chapter the GPU is list as MSTP0 and not MSTP112.  
>   Comparing with the Gen3 doc this looks correct so MSTP0 is good IMHO.

Sounds reasonable. Just to cross-reference that, does 3DGE appear in the
0-bit row of the table under the register definition of MSTPSR0? I see
from renesas-cpg-mssr.c that these registers have moved for gen4 though,
so this could be a blind alley.

A similar thought – is a new entry in r8a779a0_mod_clks (defined in
r8a779a0-cpg-mssr.c) required? The equivalent table for r8a77965 has a
"3dge" entry at 112.

> 
> - The V3U don't have a S2D1 clock... but the GPU chapter lists it in the 
>   (assumed) copy-pasted diagram...  What I did was track which clocks 
>   where S2D1 on Gen3 and compared that to what those IP where using on 
>   V3U. The overlap was the DU and that uses S3D1 on V3U so I just 
>   followed that.

There's a top-level clock diagram near the top of the CPG chapter in the
TRM I have (fig 8.1d for M3N) that annotates S2D1 as being an AXI-bus
clock. Is there a similar annotation on S3D1 for V3U in your TRM? If
not, I'm happy to just follow your logic and ack this patch :)

Cheers,
Matt

> 
>>
>>> +                   clock-names = "core", "mem", "sys";
>>> +                   power-domains = <&sysc R8A779A0_PD_3DG_A>,
>>> +                                   <&sysc R8A779A0_PD_3DG_B>;
>>> +                   power-domain-names = "a", "b";
>>> +                   resets = <&cpg 0>;
>>
>> Same 0 concern as above.
>>
>> Cheers,
>> Matt
>>
>> [1]: 
>> https://lore.kernel.org/r/[email protected]/
>>  
>>
>>> +                   status = "disabled";
>>> +           };
>>> +
>>>             cpg: clock-controller@e6150000 {
>>>                     compatible = "renesas,r8a779a0-cpg-mssr";
>>>                     reg = <0 0xe6150000 0 0x4000>;
>>
>> -- 
>> Matt Coster
>> E: [email protected]

-- 
Matt Coster
E: [email protected]

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to