Re: [PATCH 2/3] arm64: dts: renesas: r8a77960: Add GX6250 GPU node

[Matt Coster <Matt.Coster@imgtec.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2666 bytes --]

Hi Marek,

On 14/10/2025 23:59, Marek Vasut wrote:
> On 10/14/25 1:52 PM, Matt Coster wrote:
> 
> Hello Matt,
> 
>>> +++ b/arch/arm64/boot/dts/renesas/r8a77960.dtsi
>>> @@ -2565,6 +2565,18 @@ gic: interrupt-controller@f1010000 {
>>>               resets = <&cpg 408>;
>>>           };
>>>   +        gpu: gpu@fd000000 {
>>> +            compatible = "renesas,r8a77960-gpu",
>>> +                     "img,img-gx6250",
>>> +                     "img,img-rogue";
>>> +            reg = <0 0xfd000000 0 0x40000>;
>>> +            interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
>>> +            clocks = <&cpg CPG_MOD 112>;
>>> +            clock-names = "core";
>>> +            power-domains = <&sysc R8A7796_PD_3DG_B>;
>>
>> My comments here apply to the other dts patch (P3/3) as well since the
>> integration appears to be identical between the two SoCs.
>>
>> There are two power domains on this GPU and the SoC exposes both of
>> them; no reason to fall back to the single-domain scheme here.
>>
>> I know the sysc driver declares the dependency of _B on _A, but the dts
>> shouldn't rely on that, so can we have:
>>
>>     power-domains = <&sysc R8A7796_PD_3DG_A>, <&sysc R8A7796_PD_3DG_B>;
>>     power-domain-names = "a", "b";
> 
> Both SoCs fixed in V2 , which I will post in a few days , thanks !
> 
>>> +            resets = <&cpg 112>;
>>
>> Is this a reset line? Is it a clock?
> 
> This is a reset line. The MSTP controls both clocks and resets, but
> this particular phandle describes reset control.

Ack

> 
>> I see this pattern used throughout
>> the Renesas dts, but I'm just thinking how this will interact with the
>> powervr driver. The reset line is optional since some hardware
>> integrations manage it for us during the power-up/down sequences, which
>> appears to be the case here with the MSTP control (from my brief dig
>> through the Renesas TRM).
> 
> As far as I can tell, the pvr_power.c toggles the IP reset after the
> IP clock were already enabled, so the IP should be correctly reset.
> What kind of problem do you expect ?

I think I'm just being paranoid about the weirdness (to me at least) of
having one device be treated as both clock and reset line. Assuming this
is tested as working, I'm okay with it, especially as it seems to be the
norm for Renesas.

> 
>> Related, see my comments on the bindings patch (P1/3) about how clocks
>> are wired up in this SoC.
> I tried to reply to that one, hopefully it makes some sense.

Looks like we've figured it out there, thanks for your comments!

Cheers,
Matt


-- 
Matt Coster
E: matt.coster@imgtec.com

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]