[PATCH 2/3] arm64: dts: renesas: r8a77960: Add GX6250 GPU node
Marek Vasut
marek.vasut at mailbox.org
Tue Oct 14 15:59:45 PDT 2025
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 at f1010000 {
>> resets = <&cpg 408>;
>> };
>>
>> + gpu: gpu at 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.
> 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 ?
> 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.
More information about the linux-arm-kernel
mailing list