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

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

[Igor Velkov via B4 Relay]

From: Igor Velkov <iav@iav.lv>

The RK3399 Mali-T860 matches arm,mali-t860 and gets default_data, so
panfrost enables aclk_gpu at probe and keeps it enabled until unbind;
runtime suspend powers the GPU off but leaves the clock on.

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.

Match rockchip,rk3399-mali to default_pm_rt_data.

Signed-off-by: Igor Velkov <iav@iav.lv>
---
Tested on ROCK Pi 4A, drm-misc-next 33ed26235db9 with the rkvdec fix [1]
applied: hibernation with HDMI active restores 6 of 6 with this patch
(once right after glmark2-es2-drm), and hangs 2 of 2 without it.
[1] fixes the same kind of hang in rkvdec, which otherwise hits first.

[1] https://lore.kernel.org/r/20261030-rkvdec-runtime-pm-clocks-v1-1-fb2c5b629e79@iav.lv
---
 drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 7c348a0bf1ee..21a9a12abefc 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -983,6 +983,7 @@ static const struct of_device_id dt_match[] = {
 	  .data = &amlogic_data, },
 	{ .compatible = "renesas,r9a08g046-mali", .data = &default_pm_rt_data },
 	{ .compatible = "renesas,r9a09g047-mali", .data = &default_pm_rt_data },
+	{ .compatible = "rockchip,rk3399-mali", .data = &default_pm_rt_data },
 	{ .compatible = "arm,mali-t604", .data = &default_data, },
 	{ .compatible = "arm,mali-t624", .data = &default_data, },
 	{ .compatible = "arm,mali-t628", .data = &default_data, },

---
base-commit: 33ed26235db93162935d1719bc6f538c384a2fd8
change-id: 20261030-panfrost-rk3399-pm-rt-cea3fc1790d9

Best regards,
-- 
Igor Velkov <iav@iav.lv>

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

[Adrián Larumbe]

Hi Igor,

On 30.10.2026 06:43, Igor Velkov via B4 Relay wrote:
> From: Igor Velkov <iav@iav.lv>
> 
> The RK3399 Mali-T860 matches arm,mali-t860 and gets default_data, so
> panfrost enables aclk_gpu at probe and keeps it enabled until unbind;
> runtime suspend powers the GPU off but leaves the clock on.
> 
> 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.

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?

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.

> Match rockchip,rk3399-mali to default_pm_rt_data.
> 
> Signed-off-by: Igor Velkov <iav@iav.lv>
> ---
> Tested on ROCK Pi 4A, drm-misc-next 33ed26235db9 with the rkvdec fix [1]
> applied: hibernation with HDMI active restores 6 of 6 with this patch
> (once right after glmark2-es2-drm), and hangs 2 of 2 without it.
> [1] fixes the same kind of hang in rkvdec, which otherwise hits first.

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.

> [1] https://lore.kernel.org/r/20261030-rkvdec-runtime-pm-clocks-v1-1-fb2c5b629e79@iav.lv

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?

---
>  drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 7c348a0bf1ee..21a9a12abefc 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -983,6 +983,7 @@ static const struct of_device_id dt_match[] = {
>  	  .data = &amlogic_data, },
>  	{ .compatible = "renesas,r9a08g046-mali", .data = &default_pm_rt_data },
>  	{ .compatible = "renesas,r9a09g047-mali", .data = &default_pm_rt_data },
> +	{ .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.

>  	{ .compatible = "arm,mali-t604", .data = &default_data, },
>  	{ .compatible = "arm,mali-t624", .data = &default_data, },
>  	{ .compatible = "arm,mali-t628", .data = &default_data, },
> 
> ---
> base-commit: 33ed26235db93162935d1719bc6f538c384a2fd8
> change-id: 20261030-panfrost-rk3399-pm-rt-cea3fc1790d9
> 
> Best regards,
> -- 
> Igor Velkov <iav@iav.lv>

Adrian Larumbe

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@iav.lv

--
Igor Velkov