Re: [PATCH v9 06/16] drm/panfrost: Fix PM refcnt and autosuspend issues at device probe/remove

[Adrián Larumbe]

On 23.09.2026 10:00, Boris Brezillon wrote:
> On Tue, 22 Sep 2026 20:51:48 +0100
> Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx> wrote:
> 
> > On 14.09.2026 11:22, Boris Brezillon wrote:
> > > On Sat, 12 Sep 2026 00:28:07 +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 outcome of both of the above meant 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.
> > > > - Because MMU interrupts are only enabled when the device is reset,
> > > >   the very first job targeting the tiler heap BO after device probe()
> > > >   would always time out, since the driver's PM runtime resume callback
> > > >   would not be invoked.
> > > > 
> > > > 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
> > > > - Move pm_runtime_set_suspended() before panfrost_device_fini() so that
> > > >   resource unwinding happens in the opposite order as initialisation.
> > > > 
> > > > Signed-off-by: Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx>
> > > > Fixes: 635430797d3f ("drm/panfrost: Rework runtime PM initialization")
> > > > Fixes: 876b15d2c88d ("drm/panfrost: Fix module unload")
> > > > ---
> > > >  drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++++++++--
> > > >  1 file changed, 8 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > > index 55fc22e8d4d4..a3eff77add55 100644
> > > > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> > > > @@ -854,6 +854,7 @@ static int panfrost_probe(struct platform_device *pdev)
> > > >  
> > > >  	pm_runtime_set_active(pfdev->base.dev);
> > > >  	pm_runtime_mark_last_busy(pfdev->base.dev);
> > > > +	pm_runtime_get_noresume(pfdev->base.dev);
> > > >  	pm_runtime_enable(pfdev->base.dev);
> > > >  	pm_runtime_set_autosuspend_delay(pfdev->base.dev, 50); /* ~3 frames */
> > > >  	pm_runtime_use_autosuspend(pfdev->base.dev);
> > > > @@ -866,13 +867,16 @@ static int panfrost_probe(struct platform_device *pdev)
> > > >  	if (err < 0)
> > > >  		goto err_out1;
> > > >  
> > > > +	pm_runtime_put_autosuspend(pfdev->base.dev);
> > > >  
> > > >  	return 0;
> > > >  
> > > >  err_out1:
> > > > +	pm_runtime_dont_use_autosuspend(pfdev->base.dev);
> > > >  	pm_runtime_disable(pfdev->base.dev);
> > > > -	panfrost_device_fini(pfdev);
> > > > +	pm_runtime_put_noidle(pfdev->base.dev);
> > > >  	pm_runtime_set_suspended(pfdev->base.dev);
> > > > +	panfrost_device_fini(pfdev);  
> > > 
> > > Not an issue per-se, because put_noidle() is a NOP, but I think it'd be
> > > easier to reason about with this order:
> > > 
> > > 	pm_runtime_dont_use_autosuspend(pfdev->base.dev);
> > >   	pm_runtime_disable(pfdev->base.dev);
> > > 	panfrost_device_fini(pfdev);
> > >   	pm_runtime_set_suspended(pfdev->base.dev);
> > > 	pm_runtime_put_noidle(pfdev->base.dev);
> > > 
> > > This makes it clear that panfrost_device_fini() assumes the device is
> > > resumed when it's called and suspended when it returns.  
> > 
> > Your suggestion feels more natural, which makes me wonder why I decided to move
> > panfrost_device_fini() to the end of the block. 
> > 
> > IIRC we chatted about where to place pm_runtime_put_noidle() and pm_runtime_set_suspended()
> > in panfrost_device_init() when one of the subsystem initialisations failed. My intuition
> > had been to leave them until the very bottom of it, in imitation of what you hinted here,
> > but then it'd go against the notion that winding down must be done in the opposite order
> > as initialisation. And so because panfrost_device_init() happens before all the pm_runtime_*
> > incantations, I thought panfrost_device_fini() should be placed at the end in the error
> > and driver remove paths.
> > 
> > That said, I think a more intuitive init order would be one that imitates what happens in
> > Panthor when runtime PM is enabled:
> > 
> > 	/* First thing done in pm_runtime_resume_and_get -> pm_runtime_get_active -> __pm_runtime_resume */
> > 	pm_runtime_get_noresume(pfdev->base.dev);
> 
> Panthor is a bit different in that it doesn't use noresume/noidle() at
> all. What it does instead is teach the resume/suspend hooks about the
> uninitialized device use case, and it skips some operations when a
> resume/suspend() is done on an uninitialized dev. Panfrost, on the other
> hand, just assumes that clks are enabled manually before any of the
> subsystem _init() helpers are called. TLDR; this
> pm_runtime_get_noresume() can be moved after all the _init() without
> any downsides, and it keeps all PM related-init in just one place,
> which I find neat.
> 
> > 	
> > 	/* Now come subsystem initialisations */
> > 	panfrost_gpu_init(pfdev);
> > 	panfrost_mmu_init(pfdev);
> > 	panfrost_jm_init(pfdev);
> > 	panfrost_perfcnt_init(pfdev);
> > 	panfrost_gem_init(pfdev);
> > 	
> > 	/* __pm_runtime_resume -> rpm_resume first invokes the resume callback and then
> > 	 * updates runtime status to RPM_ACTIVE. */
> > 	pm_runtime_set_active(pfdev->base.dev);
> > 	
> > 	pm_runtime_enable(ptdev->base.dev);
> >         pm_runtime_mark_last_busy(pfdev->base.dev);
> > 	pm_runtime_set_autosuspend_delay(pfdev->base.dev, 50); /* ~3 frames */
> > 	pm_runtime_use_autosuspend(pfdev->base.dev);
> > 
> > And then in the error and device remove path would be almost just like you suggest.
> > 
> >         pm_runtime_dont_use_autosuspend(pfdev->base.dev);
> > 	pm_runtime_disable(pfdev->base.dev);
> > 	pm_runtime_put_noidle(pfdev->base.dev);
> > 	panfrost_device_fini(pfdev);
> > 	pm_runtime_set_suspended(pfdev->base.dev);
> > 
> > The only difference is that pm_runtime_put_noidle() happens before device_fini
> > because that's the same order as in __pm_runtime_suspend().
> 
> I really think we should keep the init/fini order consisten, so
> put_noidle() should be after the _fini() calls. But as I said above,
> I'd probably have get_noresume() called after all the _init() functions
> instead, since we can afford it in Panfrost, and it helps keeping all
> the PM-related calls in just one block.
> 
> > 
> > However, that means in the commit where I move all DRM initialisation into
> > panfrost_device_init(), in order to keep things consistent, I should move
> > pm_runtime_set_suspended() to the very end of the error path.
> 
> It probably doesn't matter much actually, because as soon as
> pm_runtime_disable() is called, nothing can change the RPM state
> anymore. So maybe scratch all of my comments, and we stick to what you
> had. It's just a transition state anyway, so, as long as it doesn't
> regress the probe/remove logic, it's probably fine.

I think I'll leave it the way it is and then add a comment that explains
why the manual adjustment of PM references and status. 

> > 
> > > >  err_out0:
> > > >  	return err;
> > > >  }
> > > > @@ -884,9 +888,11 @@ static void panfrost_remove(struct platform_device *pdev)
> > > >  	drm_dev_unregister(&pfdev->base);
> > > >  
> > > >  	pm_runtime_get_sync(pfdev->base.dev);
> > > > +	pm_runtime_dont_use_autosuspend(pfdev->base.dev);
> > > > +	pm_runtime_put_noidle(pfdev->base.dev);
> > > >  	pm_runtime_disable(pfdev->base.dev);  
> > > 
> > > Let's keep the order consistent with the probe path:
> > > 
> > > 	pm_runtime_dont_use_autosuspend(pfdev->base.dev);
> > > 	pm_runtime_disable(pfdev->base.dev);
> > > 	panfrost_device_fini(pfdev);
> > > 	pm_runtime_set_suspended(pfdev->base.dev);
> > > 	pm_runtime_put_noidle(pfdev->base.dev);
> > > 
> > > I also think this deserves comments to explain the noresume/noidle
> > > dance (device_init/fini take care of clks internally, and when they
> > > return the device is resumed/suspended, so all we have to is update the
> > > state, and acquire a ref).  
> > 
> > I don't mind doing this, but I think the fact we're calling noresume/noidle
> > functions already implies device power-up is being handled manually rather
> > by having RPM invoke resume and suspend callbacks behind the scenes, so
> > we've no choice other than adjusting PM user counter and status ourselves.
> 
> Fair enough.

Adrian Larumbe