Hibernate runtime-resume fixes
Subsystems (3)
cover Hibernate runtime-resume fixes
I stumbled across these two issues while implementing runtime pm for Thunderbolt. Unfortunately hibernate is not working on my machine (no swap partition) so I could not test the patches beyond verifying that they compile. I merely had the impression that this is wrong when reading the code. Somebody please double-check if the patches are legitimate. If they are not then I apologize for the noise.
Best regards,
Lukas
Lukas Wunner (2):
PM / sleep: Clear pm_suspend_global_flags upon hibernate ACPI / PM: Runtime resume devices when waking from hibernate
drivers/acpi/sleep.c | 1 + kernel/power/hibernate.c | 1 + 2 files changed, 2 insertions(+)
Signature · 1 line
1.8.5.2 (Apple Git-48)
PATCH 1/2 PM / sleep: Clear pm_suspend_global_flags upon hibernate
When suspending to RAM, waking up and later suspending to disk, we gratuitously runtime resume devices after the thaw phase. This does not occur if we always suspend to RAM or always to disk.
pm_complete_with_resume_check(), which gets called from pci_pm_complete() among others, schedules a runtime resume if PM_SUSPEND_FLAG_FW_RESUME is set. The flag is set during a suspend-to-RAM cycle. It is cleared at the beginning of the suspend-to-RAM cycle but not afterwards and it is not cleared during a suspend-to-disk cycle at all. Fix it.
firmware involvement")
--- kernel/power/hibernate.c | 1 + 1 file changed, 1 insertion(+)
kernel/power/hibernate.c +1 -0
@@ -339,6 +339,7 @@ int hibernation_snapshot(int platform_mode)pm_message_t msg;int error; +pm_suspend_clear_flags (); error =platform_begin (platform_mode);if (error) goto Close;
Signature · 1 line
1.8.5.2 (Apple Git-48)
PATCH 2/2 ACPI / PM: Runtime resume devices when waking from hibernate
In reply to Lukas WunnerCommit 58a1fbbb2ee8 ("PM / PCI / ACPI: Kick devices that might have been reset by firmware") added a runtime resume for devices that were runtime suspended when the system entered suspend-to-RAM.
Briefly, the motivation was to ensure that devices did not remain in a reset-power-on state after resume, potentially preventing deep SoC-wide low-power states from being entered on idle.
Currently we're not doing the same when leaving suspend-to-disk and this asymmetry is a problem if drivers rely on the automatic resume triggered by pm_complete_with_resume_check(). Fix it.
reset by firmware")
--- drivers/acpi/sleep.c | 1 + 1 file changed, 1 insertion(+)
drivers/acpi/sleep.c +1 -0
@@ -748,6 +748,7 @@ static int acpi_hibernation_enter(void)static void acpi_hibernation_leave (void ) { +pm_set_resume_via_firmware ();/* * If ACPI is not enabled by the BIOS and the boot kernel, we need to * enable it here.
Signature · 1 line
1.8.5.2 (Apple Git-48)
Quoted 6 lines · Lukas Wunner
I stumbled across these two issues while implementing runtime pm for Thunderbolt. Unfortunately hibernate is not working on my machine (no swap partition) so I could not test the patches beyond verifying that they compile. I merely had the impression that this is wrong when reading the code. Somebody please double-check if the patches are legitimate. If they are not then I apologize for the noise.
Both are legitimate in my view, so I've applied them and marked them for "stable".
The subject of the second one is slightly not to the point (as this is more about telling drivers that platform firmware has been involved in the resume operation, which may or may not be related to runtime resuming them etc), but then I can't invent a better one anyway.
Thanks,
Rafael