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

[Marek Vasut]

On 10/16/25 4:32 PM, Geert Uytterhoeven wrote:

Hello Geert,

> On Thu, 16 Oct 2025 at 16:13, Marek Vasut <marek.vasut at mailbox.org> wrote:
>> On 10/16/25 12:14 PM, Geert Uytterhoeven wrote:
>>>> which are also never disabled, do we want to disable the GPU by default
>>>> and enable per-board ?
>>>
>>> Yes please. We do the same with renesas,*-mali GPU nodes.
>>> The board may not even have graphical output.
>>> Or do you envision using the GPU for more general and headless operation?
>>
>> The GPU does have GP-GPU compute shader, so even headless system can do
>> compute on the GPU.
> 
> How is this handled on other SoCs?

I did a quick measurement to get some statistics from next-20251016 :

$ sed -n '/gpu at .*{/,/}/ { /compatible/ s at .*compatible =.*@compatible at p ; 
/status / s@^[ \t]\+@@p }' $( git grep -l 'gpu@' arch ) | sort | uniq -c
     152 compatible
      66 status = "disabled";
       8 status = "okay";

It seems there are 152 GPU nodes, 66 are explicitly disabled, the rest 
are enabled, so about 3/5 of the GPU nodes are default enabled. But my 
measurement is crude.

>>>> I would argue the GPU should be enabled by default, so the GPU driver
>>>> can do a proper power management of the GPU. If firmware is missing, at
>>>> least power it off on failed probe, if nothing else.
>>>
>>> The *_PD_3DG_* domains are powered down anyway when unused.
>>
>> If the driver was bound to the GPU node, then the domain would be surely
>> powered down in control of the Linux kernel driver, without depending on
>> the prior stage to leave it powered down.
>>
>> I think it is in fact better to bind the GPU driver to the GPU IP and
>> let the GPU driver power manage the GPU in a well defined manner,
>> instead of depending on the prior stage to leave the GPU in some
>> specific state ?
> 
> The domains are powered down by the rcar-sysc PM Domain driver,
> hence the system does not rely on any prior stage taking care of that.

OK

-- 
Best regards,
Marek Vasut