Use force_suspend/resume to make sure clocks are disabled/enabled
accordingly during system suspend/resume.
Signed-off-by: Shengjiu Wang <[email protected]>
---
sound/soc/codecs/wm8962.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 0a2cfff44441..80332c147da9 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3854,6 +3854,8 @@ static int wm8962_runtime_suspend(struct device *dev)
static const struct dev_pm_ops wm8962_pm = {
SET_RUNTIME_PM_OPS(wm8962_runtime_suspend, wm8962_runtime_resume, NULL)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
};
static const struct i2c_device_id wm8962_i2c_id[] = {
--
2.21.0
On Fri, Apr 24, 2020 at 02:12:07PM +0800, Shengjiu Wang wrote:
> Use force_suspend/resume to make sure clocks are disabled/enabled
> accordingly during system suspend/resume.
>
> Signed-off-by: Shengjiu Wang <[email protected]>
> ---
> sound/soc/codecs/wm8962.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
> index 0a2cfff44441..80332c147da9 100644
> --- a/sound/soc/codecs/wm8962.c
> +++ b/sound/soc/codecs/wm8962.c
> @@ -3854,6 +3854,8 @@ static int wm8962_runtime_suspend(struct device *dev)
>
> static const struct dev_pm_ops wm8962_pm = {
> SET_RUNTIME_PM_OPS(wm8962_runtime_suspend, wm8962_runtime_resume, NULL)
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> + pm_runtime_force_resume)
I would be interested in a little more explaination of why this is
the correct fix here?
My concern is this presumably precludes the CODEC being used in any
application where it is expected to process audio during system
suspend. Admittedly, the target market for this device probably
makes that unlikely, but I am slightly uncomfortable just assuming
that will always be true.
As far as I can see the expectation is that DAPM shutdowns down
all audio streams during system suspend (except those marked to
ignore suspend, as per my above concerns) and that will cause
a pm_runtime_put on each DAPM context which I would imagine is
intended to put the CODEC into runtime suspend. I am guessing the
reason you have problems is because of the driver doing its own
pm_runtime operations in set_fll, which probably takes an extra
reference preventing the power down. Is a more complex fix
correcting the interaction with DAPM the correct solution here?
Thanks,
Charles
On Fri, Apr 24, 2020 at 10:43:47AM +0000, Charles Keepax wrote:
> intended to put the CODEC into runtime suspend. I am guessing the
> reason you have problems is because of the driver doing its own
> pm_runtime operations in set_fll, which probably takes an extra
> reference preventing the power down. Is a more complex fix
> correcting the interaction with DAPM the correct solution here?
Or just updating the machine driver to turn off the FLL when shutting
down (or even when the device is idle in general).