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:
> > On Tue, Sep 05, 2017 at 04:46:11PM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, September 5, 2017 4:45:11 PM CEST Mika Westerberg wrote:
> > > > On Mon, Sep 04, 2017 at 12:01:54PM +0200, Rafael J. Wysocki wrote:
> > > > > 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
