Re: [PATCH v7 09/17] drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove

From: Boris Brezillon

Date: Wed Sep 02 2026 - 12:27:28 EST


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

> On 01.09.2026 15:18, Boris Brezillon wrote:
> > On Fri, 28 Aug 2026 21:56:49 +0100
> > Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx> wrote:
> >
> > > During device probe(), failure to do a PM get() will leave the usage_count
> > > set to 0, which is the value assigned at device creation time. That means
> > > when the autosuspend delay expires, runtime suspend callback won't be
> > > invoked, so the device will remain powered on forever.
> > >
> > > On top of that, failure to call PM put() during device unplug means
> > > Panfrost device's PM usage_count increases monotonically for every new
> > > module reload.
> > >
> > > The combined outcome of both of the above was that devfreq OPP transition
> > > notifications would be printed all the time, even when no jobs are being
> > > submitted. This quickly fills the kernel ring buffer with junk.
> > >
> > > To fix the above:
> > > - Manually adjust the PM refcnt at device probe and removal time.
> > > - Ensure pm_runtime_dont_use_autosuspend is called in the wind-down path.
> > > - Call pm_runtime_put_autosuspend() when device is ready to accept jobs
> > >
> > > Signed-off-by: Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx>
> > > Fixes: 635430797d3f ("drm/panfrost: Rework runtime PM initialization")
> > > Fixes: 876b15d2c88d ("drm/panfrost: Fix module unload")
> >
> > Because of how things are currently ordered, this won't be backportable
> > without patch 2, which doesn't have a Fixes tag, so, either we put the
> > fix first, and then we move code, or we make it a single commit.
>
> I think I mentioned it in a previous reply. Maybe it's best to fix the outstanding issues first
> and then moving code into panfrost_{init|fini}().

I agree it'd be simpler to do that.