On Wed, Apr 27, 2022 at 11:48 AM Charles Keepax ckeepax@opensource.cirrus.com wrote:
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.
I am not familiar with this driver or the force_suspend ops, so I am not sure if there are going to be side-effects. I don't mind collecting more data if it's helpful. I probably won't be able to add more debug info until this weekend at the earliest.
adam
Thanks, Charles