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.
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.
