Hi All, We've discussed that at length here: http://marc.info/?t=139950469000003&r=1&w=4 but I'm starting a new thread to refresh things a bit. This is about adding a mechanism allowing us to avoid runtime-suspended devices during system suspend. The reason why it has to touch the PM core is because that needs to be coordinated across the device hierarchy. The idea is to add a new device PM flag and to modify the PM core as follows. - If ->prepare() returns a positive number for a device, that means "this device is runtime-suspended and you can leave it like that if you do the same for all of its descendants". - If that happens, the PM core sets the new flag for the device in question *if* the device is indeed runtime-suspended *and* *if* the transition is a suspend (and not hibernation, for example). Otherwise, it clears the flag for the device. All of that happens in device_prepare(). - In __device_suspend() the PM core clears the new flag for the device's parent if it is clear for the device to ensure that the flag will only be set for a device if it is also set for all of its descendants. - PM core skips ->suspend/late/noirq and ->resume/early/noirq for all devices having the flag set - so the flag can be called "direct_complete" as it causes the PM core to go directy for the ->complete() callback when set. - The ->complete() callback has to check direct_complete if ->prepare() returned a positive number previously and is responsible for further handling of the device. That is introduced by patch [2/3]. To simplify things slightly it is helpful to move the invocation of pm_runtime_barrier() from __device_suspend() to device_prepare(), but still under pm_runtime_get_noresume() beforehand (patch [1/3]). Patch [3/3] shows how this can be used by adding support for it to the ACPI PM comain. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
