PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1
Tony Lindgren
tony at atomide.com
Tue Feb 2 08:49:10 PST 2016
* Alan Stern <stern at rowland.harvard.edu> [160202 08:17]:
> On Tue, 2 Feb 2016, Ulf Hansson wrote:
> >
> > Your observations is correct. The hardware will be kept active
> > in-between the probe attempts (and thus also if probing fails).
> > Although, that's not a regression as that's the behaviour you get from
> > runtime PM, when drivers are implemented like omap_hsmmc.
>
> Perhaps this is what we should do. If probing gets deferred a few
> times, doing runtime suspends and resumes in between will be a waste of
> time.
That sounds like an optimization though. We'd still have to disable
the deviec somehow after deferred probe gives up.
> ? pm_runtime_put_sync() _already_ does not respect the autosuspend
> mode. If you want to respect it, you have to call
> pm_runtime_put_sync_autosuspend() instead.
I think you found the real bug there. So the right fix is to
call pm_runtime_put_sync_autosuspend() at the end of failed
probe in omap_hsmmc. Let me give that a try here.
Can we add some warning to pm_runtime_put_sync() about that?
Regards,
Tony
More information about the linux-arm-kernel
mailing list