On Wed, 2 Sep 2026 16:42:53 +0100 Adrián Larumbe <[email protected]> wrote:
> On 01.09.2026 15:27, Boris Brezillon wrote: > > On Fri, 28 Aug 2026 21:56:51 +0100 > > Adrián Larumbe <[email protected]> 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 <[email protected]> > > > --- > > > 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 <[email protected]> */ > > > /* Copyright 2019 Linaro, Ltd, Rob Herring <[email protected]> */ > > > > > > +#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.
