Re: [PATCH] drm/panfrost: Gate the RK3399 GPU clock in runtime suspend

[Igor Velkov]

Hi Adrián,

On 04.11.2026, Adrián Larumbe wrote:
>> On ROCK Pi 4A restore from hibernation hangs in genpd_restore_noirq()
>> of the GPU while panfrost is bound. With the clock gated in runtime
>> suspend, as on the Allwinner H616 and the Renesas parts, it restores.
>
> I find the wording in the preceding paragraph a bit confusing . Would
> you mind clarifying what 'parts' means here? I guess you refer to
> specific SoCs.

Yes, SoCs: allwinner,sun50i-h616-mali, renesas,r9a08g046-mali and
renesas,r9a09g047-mali already use default_pm_rt_data. v2 will name
them.

> Also, I wonder why not disabling the clocks would forestall coming back
> from a power suspension state. Have you raised this matter to the
> maintainers of the RK3399 SoC subsystem?

The kernel that reads the image never binds panfrost, so after
clk_disable_unused() aclk_gpu stays gated. The restored image still has
it enabled in software (enable count 1 since probe), so powering the GPU
domain back on, whose clocks include aclk_gpu, only bumps the count, and
the QoS writes that follow in rockchip_pd_power() go to a gated block
and hang. I traced this for rkvdec [1]; for the GPU I see the hang at
the same spot, genpd_restore_noirq(), and gating in runtime suspend
removes it. I haven't raised it separately; Heiko is on To.

> Would you also mind describing what you did to reproduce this
> resume-from-suspend issue? Lately we've been getting some fixes for
> similar SoC issues and I wonder whether mine also has it.

It is hibernation (restore from disk), not suspend to RAM. ROCK Pi 4A,
drm-misc-next 33ed26235db9 plus [1], panfrost as a module, bound, GPU
idle, swap file with resume= and resume_offset=: systemctl hibernate,
power off and on. Without the patch restore hangs at "panfrost
ff9a0000.gpu: calling genpd_restore_noirq" 2 of 2, with it restores
6 of 6. A quick check on another board: with panfrost bound and the GPU
idle, its core clock keeps enable count 1 in clk_summary.

> If this patch depends on another fix being merged first, I think it's
> best you delay sending a v2 until it's been committed to its relevant
> subsystem tree and changes pulled into drm-misc-next.

It applies and builds without [1]; [1] only gets this board through
restore up to the GPU. [1] goes through linux-media, so I'd rather not
tie v2 to it, but fine either way.

> I'm not entirely sure about what patch submission guidelines say about
> testing information, but normally commit trailers must come about
> last. Would you mind then moving this to right before the S-o-b?

The test notes are below the "---" on purpose, so they stay out of the
commit.

>> +	{ .compatible = "rockchip,rk3399-mali", .data = &default_pm_rt_data },
>
> You're effectively adding support to a whole new SoC. This made me
> wonder, are we sure suspension resumption not working is only because of
> GPU_PM_RT? Shouldn't we know first about its supplies and power domains,
> and any potential GPU quirks? I think this goes beyond my knowledge, so
> maybe Steven Price can pitch in.

The node already carries "rockchip,rk3399-mali", "arm,mali-t860" and
binds through the fallback today. default_pm_rt_data differs from
default_data only in GPU_PM_RT; supplies and the power domain stay as
they are. The RK3399 GPU node has no bus clocks and no resets, so
GPU_PM_RT changes only aclk_gpu here. Steven's view is welcome.

[1] https://lore.kernel.org/r/20261030-rkvdec-runtime-pm-clocks-v2-1-8ff510a231de@xxxxxx

--
Igor Velkov