On Tuesday, August 29, 2017 12:29:27 PM CEST Johannes Stezenbach wrote: > Hi, > > On Tue, Aug 29, 2017 at 02:18:13AM +0200, Rafael J. Wysocki wrote: > > On Wednesday, August 23, 2017 4:42:00 PM CEST Ulf Hansson wrote: > > > The i2c designware platform driver, drivers/i2c/busses/i2c-designware-platdrv.c, > > > isn't well optimized for system sleep. > > > > > > What makes this driver particularly interesting is because it's a cross-SoC > > > driver, which sometimes means there is an ACPI PM domain attached to the i2c > > > device and sometimes not. The driver is being used on both x86 and ARM. > ... > > Basically, the point is to allow i2c-designware-platdrv to point its late > > suspend and early resume callbacks, respectively, to pm_runtime_force_suspend() > > and pm_runtime_force_resume() which then will do the right thing regardless of > > whether or not the device is runtime suspended when system suspend starts. > > I'd like to point out a comment added by Hans de Goede in > https://bugzilla.kernel.org/show_bug.cgi?id=193891#c99 > > The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is > attached to I2C7, these methods get executed by acpi_dev_suspend_late / > acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend / > resume callbacks it is already suspended at the time those calls happen, > leading to a device-suspend error and the system not suspending at all. > > It's the reason for the Cherrytrail I2C7 special treatment in > i2c-designware-platdrv.c and pm_disabled = true in i2c-designware-baytrail.c, > however pm_disabled seems to be a problem for S0ix support. > To solve it, i2c-designware-platdrv needs to suspend after all > devices using ACPI OpRegions for suspend. That's a totally different issue from the one at hand. It simply means that the devices using I2C for suspend/resume need to be suspended *before* the I2C controller and resumed *after* it. So this is a system suspend/resume *ordering* issue and not a runtime PM vs system suspend issue. It can be addressed, for example, by doing the I2C controller's suspend/resume at the noirq stage. Has anyone tried that? Thanks, Rafael -- 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
