On Wed, Apr 27, 2022 at 04:24:31PM +0100, Mark Brown wrote:
> On Wed, Apr 27, 2022 at 02:57:30PM +0000, Charles Keepax wrote:
> > On Wed, Apr 27, 2022 at 08:12:56AM -0500, Adam Ford wrote:
> > > static const struct dev_pm_ops wm8962_pm = {
> > > + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
> > > SET_RUNTIME_PM_OPS(wm8962_runtime_suspend, wm8962_runtime_resume, NULL)
> > > };
>
> > > I applied this, and it appears to make the issue go away on a 5.15
> > > kernel. I haven't tried it on a 5.18 yet. If this fixes the issue,
> > > would that be an acceptable solution to push upstream?
>
> > Feels like those operations should be runtime PM, like there is
> > no reason to keep the CODEC in a high power state than necessary.
>
> The issue Adam reported was suspending during playback - if you suspend
> during playback or capture the device is not idle at the point where we
> start trying to suspend so it shouldn't be in runtime suspend and won't
> by default be runtime suspended by the PM core.
Yeah in my head snd_soc_suspend would have been called which
would (assuming the DAI doesn't have ignore_suspend set) shut
down the DAPM graph for the audio route, causing the runtime
references to all be released and the CODEC to be suspended
through runtime_pm. Not sure if I missed something there, and
that also allows for systems where the CODEC doesn't suspend
during system suspend. That said guess there probably arn't
any use-cases for that on wm8962 and I am more than happy to
use the force_suspend ops if you are happy with it.
Thanks,
Charles
