On 10/16/25 4:32 PM, Geert Uytterhoeven wrote:
Hello Geert,
On Thu, 16 Oct 2025 at 16:13, Marek Vasut <[email protected]> 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@.*{/,/}/ { /compatible/ s@.*compatible =.*@compatible@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
