From: "Rafael J. Wysocki" <firstname.lastname@example.org> To: Linux PM <email@example.com> Cc: Linux ACPI <firstname.lastname@example.org>, LKML <email@example.com>, Len Brown <firstname.lastname@example.org>, Srinivas Pandruvada <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Rajneesh Bhardwaj <email@example.com>, "David E. Box" <firstname.lastname@example.org> Subject: [PATCH 0/8] PM / ACPI: sleep: Simplify the suspend-to-idle control flow Date: Tue, 16 Jul 2019 18:08:29 +0200 [thread overview] Message-ID: <71085220.z6FKkvYQPX@kreacher> (raw) Hi All, The rationale for these changes is explained in the changelog of patch [6/8] as follows: "After commit 33e4f80ee69b ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle") the "noirq" phases of device suspend and resume may run for multiple times during suspend-to-idle, if there are spurious system wakeup events while suspended. However, this is complicated and fragile and actually unnecessary. The main reason for doing this is that on some systems the EC may signal system wakeup events (power button events, for example) as well as events that should not cause the system to resume (spurious system wakeup events). Thus, in order to determine whether or not a given event signaled by the EC while suspended is a proper system wakeup one, the EC GPE needs to be dispatched and to start with that was achieved by allowing the ACPI SCI action handler to run, which was only possible after calling resume_device_irqs(). However, dispatching the EC GPE this way turned out to take too much time in some cases and some EC events might be missed due to that, so commit 68e22011856f ("ACPI: EC: Dispatch the EC GPE directly on s2idle wake") started to dispatch the EC GPE right after a wakeup event has been detected, so in fact the full ACPI SCI action handler doesn't need to run any more to deal with the wakeups coming from the EC. Use this observation to simplify the suspend-to-idle control flow so that the "noirq" phases of device suspend and resume are each run only once in every suspend-to-idle cycle, which is reported to significantly reduce power drawn by some systems when suspended to idle (by allowing them to reach a deep platform-wide low-power state through the suspend-to-idle flow)." A bonus is that after the essential changes the s2idle flow can be integrated back into the generic suspend/resume one (patch [7/8]) and some simplifications can be made in drivers/base/power/main.c after that (patch [8/8]). Patches [1-5/8] are pre-requisite and the changes made by the first three of them really take effect after applying patch [6/8]. Patch [4/8], in turn, is a fix and patch [5/8] is an extra simplification. Please refer to the changelogs for details. For easier testing, this series is available from the git branch at: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-s2idle-rework Thanks, Rafael
next reply other threads:[~2019-07-16 16:27 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-16 16:08 Rafael J. Wysocki [this message] 2019-07-16 16:10 ` [PATCH 1/8] PCI: irq: Introduce rearm_wake_irq() Rafael J. Wysocki 2019-07-16 16:11 ` [PATCH 2/8] ACPICA: Return u32 from acpi_dispatch_gpe() Rafael J. Wysocki 2019-07-16 16:12 ` [PATCH 3/8] ACPI: EC: Return bool from acpi_ec_dispatch_gpe() Rafael J. Wysocki 2019-07-16 16:14 ` [PATCH 4/8] PM: sleep: Fix possible overflow in pm_system_cancel_wakeup() Rafael J. Wysocki 2019-07-16 16:15 ` [PATCH 5/8] ACPI: PM: Set s2idle_wakeup earlier and clear it later Rafael J. Wysocki 2019-07-16 16:17 ` [PATCH 6/8] PM: sleep: Simplify suspend-to-idle control flow Rafael J. Wysocki 2019-07-16 16:20 ` [PATCH 7/8] PM: sleep: Integrate suspend-to-idle with generig suspend flow Rafael J. Wysocki 2019-07-16 16:21 ` [PATCH 8/8] PM: sleep: Drop dpm_noirq_begin() and dpm_noirq_end() Rafael J. Wysocki 2019-07-22 9:46 ` [PATCH 0/8] PM / ACPI: sleep: Simplify the suspend-to-idle control flow Thomas Gleixner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=71085220.z6FKkvYQPX@kreacher \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 0/8] PM / ACPI: sleep: Simplify the suspend-to-idle control flow' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).