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@xxxxxx>
> 
> 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@xxxxxx>
> ---
> 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@xxxxxx

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@xxxxxx>

Adrian Larumbe