Re: [PATCH v12 09/15] drm/panfrost: Add warning messages to fatal error conditions

[Steven Price <steven.price@arm.com>]

On 29/09/2026 04:44, Adrián Larumbe wrote:
> Rather than just failing silently, let's warn the user of device remove not
> being able to take an PM reference or the PM suspend path still reporting
> inflight jobs. Neither situation should ever happen.
> 
> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> ---
>  drivers/gpu/drm/panfrost/panfrost_device.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c b/drivers/gpu/drm/panfrost/panfrost_device.c
> index c6bf3d0663df..09a5752a3f40 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> @@ -9,6 +9,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/regulator/consumer.h>
>  #include <drm/drm_drv.h>
> +#include <drm/drm_print.h>
>  
>  #include "panfrost_device.h"
>  #include "panfrost_devfreq.h"
> @@ -357,7 +358,7 @@ int panfrost_device_init(struct panfrost_device *pfdev)
>  
>  void panfrost_device_fini(struct panfrost_device *pfdev)
>  {
> -	pm_runtime_get_sync(pfdev->base.dev);
> +	drm_WARN_ON(&pfdev->base, pm_runtime_get_sync(pfdev->base.dev) < 0);

This seems fine.

>  
>  	pm_runtime_dont_use_autosuspend(pfdev->base.dev);
>  	pm_runtime_disable(pfdev->base.dev);
> @@ -516,7 +517,7 @@ static int panfrost_device_runtime_suspend(struct device *dev)
>  {
>  	struct panfrost_device *pfdev = dev_get_drvdata(dev);
>  
> -	if (!panfrost_jm_is_idle(pfdev))
> +	if (drm_WARN_ON(&pfdev->base, !panfrost_jm_is_idle(pfdev)))

I'm a bit wary that this might be something that user space can trigger.
My AI says:

The runtime-suspend WARN can be reached by ordinary userspace job
submissions. The DRM scheduler increments credit_count before calling
Panfrost’s job runner (drivers/gpu/drm/scheduler/sched_main.c:1044).
Panfrost takes the job’s PM reference later in hardware submission
(drivers/gpu/drm/panfrost/panfrost_job.c:213). If autosuspend runs in
that interval, the new WARN
(drivers/gpu/drm/panfrost/panfrost_device.c:525) sees the credit and
fires, even though this is a timing race rather than a broken job.
Repeated submissions near the autosuspend boundary could therefore
produce repeated stack traces. The PM core treats the resulting -EBUSY
as a transient failure.

Now I have to admit I don't trust it that much - but I'd want a
convincing argument on why panfrost_jm_is_idle() will never be false here.

Thanks,
Steve

>  		return -EBUSY;
>  
>  	panfrost_devfreq_suspend(pfdev);
>