Re: [PATCH v7 11/17] drm/panfrost: Add debugfs knob for manually triggering a GPU reset

[Boris Brezillon <boris.brezillon@collabora.com>]

On Wed, 2 Sep 2026 16:42:53 +0100
Adrián Larumbe <adrian.larumbe@collabora.com> wrote:

> On 01.09.2026 15:27, Boris Brezillon wrote:
> > On Fri, 28 Aug 2026 21:56:51 +0100
> > Adrián Larumbe <adrian.larumbe@collabora.com> wrote:
> >   
> > > This will be of great help when testing potential races between the GPU
> > > reset sequence and other parts of the code accessing HW registers.
> > > 
> > > Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
> > > ---
> > >  drivers/gpu/drm/panfrost/panfrost_device.c | 35 ++++++++++++++++++++++++++++++
> > >  1 file changed, 35 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c b/drivers/gpu/drm/panfrost/panfrost_device.c
> > > index d8acae9b8cfa..b6a48ae0d3a6 100644
> > > --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> > > +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> > > @@ -2,6 +2,7 @@
> > >  /* Copyright 2018 Marty E. Plummer <hanetzer@startmail.com> */
> > >  /* Copyright 2019 Linaro, Ltd, Rob Herring <robh@kernel.org> */
> > >  
> > > +#include <linux/debugfs.h>
> > >  #include <linux/clk.h>
> > >  #include <linux/reset.h>
> > >  #include <linux/platform_device.h>
> > > @@ -600,9 +601,43 @@ EXPORT_GPL_DEV_PM_OPS(panfrost_pm_ops) = {
> > >  };
> > >  
> > >  #ifdef CONFIG_DEBUG_FS
> > > +static int reset_get(void *data, u64 *val)
> > > +{
> > > +	struct panfrost_device *pfdev =
> > > +		container_of(data, struct panfrost_device, base);
> > > +
> > > +	*val = atomic_read(&pfdev->reset.pending);
> > > +	return 0;
> > > +}
> > > +
> > > +static int reset_set(void *data, u64 val)
> > > +{
> > > +	struct panfrost_device *pfdev =
> > > +		container_of(data, struct panfrost_device, base);
> > > +
> > > +	if (pm_runtime_get_if_in_use(pfdev->base.dev)) {  
> > 
> > Are you sure it's not pm_runtime_get_if_active() we want here? If use
> > the _if_in_use() variant and autosuspend is enabled, we might skip a
> > reset on a device that's active.  
> 
> Do you mean if a driver has brought the RPM count down to 0 and scheduled a deferred suspend?
> Couldn't manually triggering a reset then somehow race with whatever is being done in
> panfrost_device_runtime_suspend() ?

If a concurrent suspend is happening, _get_if_active() would wait for
the transition to happen, and return false when the suspend is
effective. If a suspend was scheduled (rpm ref was zero), it will be
cancelled, and you'll end up with an RPM ref preventing any suspend from
happening until you call pm_runtime_put(). So I think we're good.