On my HiKey board, I'm seeing clk warnings on suspend/resume,
which seem to be caused by runtime pm suspending the device,
then the same suspend hook being called again on suspend time.
This patch fixes this by setting the SYSTEM_SLEEP_PM_OPS to
using pm_runtime_force_suspend and pm_runtime_force_resume.
Cc: Jarkko Nikula <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Mika Westerberg <[email protected]>
Cc: Wolfram Sang <[email protected]>
Cc: [email protected]
Suggested-by: Jarkko Nikula <[email protected]>
Signed-off-by: John Stultz <[email protected]>
---
v2: Switch to suggested fix by Jarkko.
---
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 79c4b4e..286447c 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -382,7 +382,7 @@ static int dw_i2c_plat_resume(struct device *dev)
static const struct dev_pm_ops dw_i2c_dev_pm_ops = {
.prepare = dw_i2c_plat_prepare,
.complete = dw_i2c_plat_complete,
- SET_SYSTEM_SLEEP_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume)
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL)
};
--
2.7.4
Hi
On 03/30/2017 06:26 AM, John Stultz wrote:
> On my HiKey board, I'm seeing clk warnings on suspend/resume,
> which seem to be caused by runtime pm suspending the device,
> then the same suspend hook being called again on suspend time.
>
> This patch fixes this by setting the SYSTEM_SLEEP_PM_OPS to
> using pm_runtime_force_suspend and pm_runtime_force_resume.
>
> Cc: Jarkko Nikula <[email protected]>
> Cc: Andy Shevchenko <[email protected]>
> Cc: Mika Westerberg <[email protected]>
> Cc: Wolfram Sang <[email protected]>
> Cc: [email protected]
> Suggested-by: Jarkko Nikula <[email protected]>
> Signed-off-by: John Stultz <[email protected]>
> ---
> v2: Switch to suggested fix by Jarkko.
> ---
> drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index 79c4b4e..286447c 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -382,7 +382,7 @@ static int dw_i2c_plat_resume(struct device *dev)
> static const struct dev_pm_ops dw_i2c_dev_pm_ops = {
> .prepare = dw_i2c_plat_prepare,
> .complete = dw_i2c_plat_complete,
> - SET_SYSTEM_SLEEP_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)
> SET_RUNTIME_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume, NULL)
We cannot do this since it will break our platforms that use the
drivers/acpi/acpi_lpss.c power domain. Reason why it fails the
pm_runtime_force_suspend() forces acpi_lpss to power down too early
before suspend_late state where context is expected to be saved during
system suspend.
acpi_lpss.c power domain
.suspend = acpi_subsys_suspend
-> pm_runtime_resume
-> acpi_lpss_runtime_resume
-> pm_generic_runtime_resume
-> dw_i2c_plat_resume
-> pm_generic_suspend
-> pm_runtime_force_suspend
-> goes through __rpm_get_callback which selects domain ops
-> acpi_lpss_runtime_suspend (context save + power down)
-> pm_generic_runtime_suspend
-> dw_i2c_plat_suspend
...
.suspend_late = acpi_lpss_suspend_late
-> acpi_lpss is already power gated here due acpi_lpss_runtime_suspend()
done during suspend phase and context save will save just 0xFFs and
resume restores wrong context.
I managed to found a use case where I'm able to trigger
dw_i2c_plat_suspend() callback twice during suspend. Quite deep dive to
PM core, lot of debugging and end result is a trivial patch that just
checks is i2c-designware runtime suspended in its suspend/resume
callbacks... This feels somewhat boilerplate and I figured also an
alternative solution to PM core.
I just sent that patch out and I Cc'ed both you and Rafael so he can
comment is this the right thing to do in driver or should it be fixed in
the PM core.
--
Jarkko