On Tuesday, September 5, 2017 4:55:44 PM CEST Rafael J. Wysocki wrote:

On Tuesday, September 5, 2017 4:58:35 PM CEST Mika Westerberg wrote:

quoted

On Tue, Sep 05, 2017 at 04:46:11PM +0200, Rafael J. Wysocki wrote:

quoted

On Tuesday, September 5, 2017 4:45:11 PM CEST Mika Westerberg wrote:

quoted

On Mon, Sep 04, 2017 at 12:01:54PM +0200, Rafael J. Wysocki wrote:

quoted

 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_RUNTIME_PM_OPS(dw_i2c_plat_runtime_suspend,
-			   dw_i2c_plat_resume,
-			   NULL)
+	SET_LATE_SYSTEM_SLEEP_PM_OPS(dw_i2c_plat_suspend, dw_i2c_plat_resume)

This seems to cause problem with intel-lpss MFD driver because it uses
.suspend() and .resume() instead of .suspend_late() and .resume_early().

OK, so there is one more dependency here.

Can you please point me to this code?

It is in drivers/mfd/intel-lpss.c. See intel_lpss_resume().

Looking at it, but I don't quite see how this is related to the
i2c-designware-platedv suspend/resume ...

My guess would be that i2c-designware is a child of the intel-lpss thing
and therefore it is expected to be suspended before it and resumed later,
right?

In that case doing runtime PM during the i2c-designware suspend/resume is
a no-go as well.

Oh well.

Would moving the intel_lpss_suspend/resume() to ->suspend_late/->resume_early
be viable?