#
2e41e3ca |
|
02-May-2023 |
Kai-Heng Feng <kai.heng.feng@canonical.com> |
PM: suspend: Fix pm_suspend_target_state handling for !CONFIG_PM Move the pm_suspend_target_state definition for CONFIG_SUSPEND unset from the wakeup code into the headers so as to allow it to still be used elsewhere when CONFIG_SUSPEND is not set. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> [ rjw: Changelog and subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
cb3e7d62 |
|
24-Aug-2022 |
Mario Limonciello <mario.limonciello@amd.com> |
PM: wakeup: Add extra debugging statement for multiple active IRQs Since commit cb1f65c1e1424 ("PM: s2idle: ACPI: Fix wakeup interrupts handling") was introduced the kernel can now handle multiple simultaneous interrupts during wakeup. Ths uncovered some existing subtle firmware bugs where multiple IRQs are unintentionally active. To help with fixing those bugs add an extra message when PM debugging is enabled that can show the individual IRQs triggered as if a variety are fired they'll potentially be lost as /sys/power/pm_wakeup_irq only contains the first one that triggered the wakeup after resume is complete but all may be needed to demonstrate the whole picture. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215770 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> [ rjw: Added empty line after if () ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
09d3154a |
|
06-Jun-2022 |
Bjorn Helgaas <bhelgaas@google.com> |
PM: wakeup: Unify device_init_wakeup() for PM_SLEEP and !PM_SLEEP Previously the CONFIG_PM_SLEEP and !CONFIG_PM_SLEEP device_init_wakeup() implementations differed in confusing ways: - The PM_SLEEP version checked for a NULL device pointer and returned -EINVAL, while the !PM_SLEEP version did not and would simply dereference a NULL pointer. - When called with "false", the !PM_SLEEP version cleared "capable" and "enable" in the opposite order of the PM_SLEEP version. That was harmless because for !PM_SLEEP they're simple assignments, but it's unnecessary confusion. Use a simplified version of the PM_SLEEP implementation for both cases. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
55266546 |
|
19-May-2022 |
Zhang Rui <rui.zhang@intel.com> |
PM: wakeup: expose pm_wakeup_pending to modules intel_pch_thermal driver needs a long delay to cool itself (60 seconds in maximum) during suspend. When a wakeup event occures during the delay, it is better for the intel_pch_thermal driver to detect this and quit cooling because the suspend is likely to abort anyway. Thus expose pm_wakeup_pending to modules so that intel_pch_thermal driver can be aware of the wakeup events. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7dfe105d |
|
11-Feb-2022 |
Tom Rix <trix@redhat.com> |
PM: sleep: wakeup: Fix typos in comments Remove the second 'the'. Replace the second 'of' with 'the'. Replace 'couter' with 'counter'. Signed-off-by: Tom Rix <trix@redhat.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
cb1f65c1 |
|
04-Feb-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: s2idle: ACPI: Fix wakeup interrupts handling After commit e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") wakeup interrupts occurring immediately after the one discarded by acpi_s2idle_wake() may be missed. Moreover, if the SCI triggers again immediately after the rearming in acpi_s2idle_wake(), that wakeup may be missed too. The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup() when pm_wakeup_irq is 0, but that's not the case any more after the interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is cleared by the pm_wakeup_clear() call in s2idle_loop(). However, there may be wakeup interrupts occurring in that time frame and if that happens, they will be missed. To address that issue first move the clearing of pm_wakeup_irq to the point at which it is known that the interrupt causing acpi_s2idle_wake() to tun will be discarded, before rearming the SCI for wakeup. Moreover, because that only reduces the size of the time window in which the issue may manifest itself, allow pm_system_irq_wakeup() to register two second wakeup interrupts in a row and, when discarding the first one, replace it with the second one. [Of course, this assumes that only one wakeup interrupt can be discarded in one go, but currently that is the case and I am not aware of any plans to change that.] Fixes: e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
16b0dd40 |
|
26-Jun-2021 |
Jinchao Wang <wjc@cdjrlc.com> |
driver: base: Replace symbolic permissions with octal permissions Resolve following checkpatch issue, Replace symbolic permissions with octal permissions Signed-off-by: Jinchao Wang <wjc@cdjrlc.com> Link: https://lore.kernel.org/r/20210626094606.53152-1-wjc@cdjrlc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
beafe82b |
|
31-Mar-2021 |
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> |
PM: wakeup: fix kernel-doc warnings and fix typos Remove make W=1 warnings and fit 'Itereates' typos drivers/base/power/wakeup.c:403: warning: wrong kernel-doc identifier on line: * device_wakeup_arm_wake_irqs(void) drivers/base/power/wakeup.c:419: warning: wrong kernel-doc identifier on line: * device_wakeup_disarm_wake_irqs(void) drivers/base/power/wakeup.c:537: warning: Function parameter or member 'enable' not described in 'device_set_wakeup_enable' drivers/base/power/wakeup.c:592: warning: expecting prototype for wakup_source_activate(). Prototype was for wakeup_source_activate() instead drivers/base/power/wakeup.c:697: warning: expecting prototype for wakup_source_deactivate(). Prototype was for wakeup_source_deactivate() instead drivers/base/power/wakeup.c:795: warning: Function parameter or member 't' not described in 'pm_wakeup_timer_fn' drivers/base/power/wakeup.c:795: warning: Excess function parameter 'data' description in 'pm_wakeup_timer_fn' drivers/base/power/wakeup.c:1027: warning: Function parameter or member 'set' not described in 'pm_wakep_autosleep_enabled' drivers/base/power/wakeup.c:1027: warning: Excess function parameter 'enabled' description in 'pm_wakep_autosleep_enabled' Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
87de6594 |
|
22-Mar-2020 |
Neeraj Upadhyay <neeraju@codeaurora.org> |
PM: sleep: wakeup: Skip wakeup_source_sysfs_remove() if device is not there Skip wakeup_source_sysfs_remove() to fix a NULL pinter dereference via ws->dev, if the wakeup source is unregistered before registering the wakeup class from device_add(). Fixes: 2ca3d1ecb8c4 ("PM / wakeup: Register wakeup class kobj after device is added") Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ [ rjw: Subject & changelog, white space ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
99917e37 |
|
19-Mar-2020 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Revert "drivers: base: power: wakeup.c: Use built-in RCU list checking" This reverts commit 8ba88804bb3b877c841bc1864a8605111580cd0b as a better version is already in Rafael's tree, sorry about that. Reported-by: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8ba88804 |
|
28-Feb-2020 |
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> |
drivers: base: power: wakeup.c: Use built-in RCU list checking Pass cond argument to list_for_each_entry_rcu() to fix the following false positive lockdep warning and other uses of list_for_each_entry_rcu() in wakeup.c. [ 331.934648] ============================= [ 331.934650] WARNING: suspicious RCU usage [ 331.934653] 5.6.0-rc1+ #5 Not tainted [ 331.934655] ----------------------------- [ 331.934657] drivers/base/power/wakeup.c:408 RCU-list traversed in non-reader section!! [ 333.025156] ============================= [ 333.025161] WARNING: suspicious RCU usage [ 333.025168] 5.6.0-rc1+ #5 Not tainted [ 333.025173] ----------------------------- [ 333.025180] drivers/base/power/wakeup.c:424 RCU-list traversed in non-reader section!! Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Link: https://lore.kernel.org/r/20200228174745.9308-1-madhuparnabhowmik10@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2591e7b1 |
|
03-Mar-2020 |
Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> |
PM: sleep: wakeup: Use built-in RCU list checking Pass cond argument to list_for_each_entry_rcu() to fix the following false positive lockdep warning and other uses of list_for_each_entry_rcu() in wakeup.c. (CONFIG_PROVE_RCU_LIST = y) [ 331.934648] ============================= [ 331.934650] WARNING: suspicious RCU usage [ 331.934653] 5.6.0-rc1+ #5 Not tainted [ 331.934655] ----------------------------- [ 331.934657] drivers/base/power/wakeup.c:408 RCU-list traversed in non-reader section!! [ 333.025156] ============================= [ 333.025161] WARNING: suspicious RCU usage [ 333.025168] 5.6.0-rc1+ #5 Not tainted [ 333.025173] ----------------------------- [ 333.025180] drivers/base/power/wakeup.c:424 RCU-list traversed in non-reader section!! Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
e976eb4b |
|
09-Dec-2019 |
zhuguangqing <zhuguangqing@xiaomi.com> |
PM: wakeup: Show statistics for deleted wakeup sources again After commit 00ee22c28915 (PM / wakeup: Use seq_open() to show wakeup stats), print_wakeup_source_stats(m, &deleted_ws) is not called from wakeup_sources_stats_seq_show() any more. Because deleted_ws is one of the wakeup sources, it should be shown too, so add it to the end of all other wakeup sources. Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b4941adb |
|
24-Oct-2019 |
Ran Wang <ran.wang_1@nxp.com> |
PM: wakeup: Add routine to help fetch wakeup source object. Some user might want to go through all registered wakeup sources and doing things accordingly. For example, SoC PM driver might need to do HW programming to prevent powering down specific IP which wakeup source depending on. So add this API to help walk through all registered wakeup source objects on that list and return them one by one. Signed-off-by: Ran Wang <ran.wang_1@nxp.com> Tested-by: Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Li Yang <leoyang.li@nxp.com>
|
#
2ca3d1ec |
|
19-Aug-2019 |
Stephen Boyd <swboyd@chromium.org> |
PM / wakeup: Register wakeup class kobj after device is added The device_set_wakeup_enable() function can be called on a device that hasn't been registered with device_add() yet. This allows the device to be in a state where wakeup is enabled for it but the device isn't published to userspace in sysfs yet. After commit c8377adfa781 ("PM / wakeup: Show wakeup sources stats in sysfs"), calling device_set_wakeup_enable() will fail for a device that hasn't been registered with the driver core via device_add(). This is because we try to create sysfs entries for the device and associate a wakeup class kobject with it before the device has been registered. Let's follow a similar approach that device_set_wakeup_capable() takes here and register the wakeup class either from device_set_wakeup_enable() when the device is already registered, or from dpm_sysfs_add() when the device is being registered with the driver core via device_add(). Fixes: c8377adfa781 ("PM / wakeup: Show wakeup sources stats in sysfs") Reported-by: Qian Cai <cai@lca.pw> Reviewed-by: Tri Vo <trong@android.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ae367b79 |
|
13-Aug-2019 |
Stephen Boyd <swboyd@chromium.org> |
PM / wakeup: Fix sysfs registration error path We shouldn't call wakeup_source_destroy() from the error path in wakeup_source_register() because that calls __pm_relax() which takes a lock that isn't initialized until wakeup_source_add() is called. Add a new function, wakeup_source_free(), that just does the bare minimum to free a wakeup source that was created but hasn't been added yet and use it from the two places it's needed. This fixes the following problem seen on various x86 server boxes: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 12 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc4- Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS U19 12/27/2015 Call Trace: dump_stack+0x62/0x9a register_lock_class+0x95a/0x960 ? __platform_driver_probe+0xcd/0x230 ? __platform_create_bundle+0xc0/0xe0 ? i8042_init+0x4ec/0x578 ? do_one_initcall+0xfe/0x45a ? kernel_init_freeable+0x614/0x6a7 ? kernel_init+0x11/0x138 ? ret_from_fork+0x35/0x40 ? is_dynamic_key+0xf0/0xf0 ? rwlock_bug.part.0+0x60/0x60 ? __debug_check_no_obj_freed+0x8e/0x250 __lock_acquire.isra.13+0x5f/0x830 ? __debug_check_no_obj_freed+0x152/0x250 lock_acquire+0x107/0x220 ? __pm_relax.part.2+0x21/0xa0 _raw_spin_lock_irqsave+0x35/0x50 ? __pm_relax.part.2+0x21/0xa0 __pm_relax.part.2+0x21/0xa0 wakeup_source_destroy.part.3+0x18/0x190 wakeup_source_register+0x43/0x50 Fixes: c8377adfa781 ("PM / wakeup: Show wakeup sources stats in sysfs") Reported-by: Qian Cai <cai@lca.pw> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
c8377adf |
|
06-Aug-2019 |
Tri Vo <trong@android.com> |
PM / wakeup: Show wakeup sources stats in sysfs Add an ID and a device pointer to 'struct wakeup_source'. Use them to to expose wakeup sources statistics in sysfs under /sys/class/wakeup/wakeup<ID>/*. Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Co-developed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Tri Vo <trong@android.com> Tested-by: Kalesh Singh <kaleshsingh@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0d105d0f |
|
06-Aug-2019 |
Tri Vo <trong@android.com> |
PM / wakeup: Drop wakeup_source_init(), wakeup_source_prepare() wakeup_source_init() has no users. Remove it. As a result, wakeup_source_prepare() is only called from wakeup_source_create(). Merge wakeup_source_prepare() into wakeup_source_create() and remove it. Change wakeup_source_create() behavior so that assigning NULL to wakeup source's name throws an error. Signed-off-by: Tri Vo <trong@android.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2933954b |
|
15-Jul-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: sleep: Fix possible overflow in pm_system_cancel_wakeup() It is not actually guaranteed that pm_abort_suspend will be nonzero when pm_system_cancel_wakeup() is called which may lead to subtle issues, so make it use atomic_dec_if_positive() instead of atomic_dec() for the safety sake. Fixes: 33e4f80ee69b ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
#
25fa4d9d |
|
18-Jun-2019 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
drivers: base: power: remove wakeup_sources_stats_dentry variable wakeup_sources_stats_dentry is assigned when the debugfs file is created, but then never used ever again. So no need for it at all, just remove it and call debugfs_create_file() on its own. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5de363b6 |
|
02-Apr-2019 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
drivers: base: power: add proper SPDX identifiers on files that did not have them. There were a few files in the driver core power code that did not have SPDX identifiers on them, so fix that up. At the same time, remove the "free form" text that specified the license of the file, as that is impossible for any tool to properly parse. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
74a1dd86 |
|
25-Mar-2019 |
Stephen Boyd <swboyd@chromium.org> |
PM / wakeup: Use pm_pr_dbg() instead of pr_debug() These prints are useful if we're doing PM suspend debugging. Having them at pr_debug() level means that we need to either enable DEBUG in this file, or compile the kernel with dynamic debug capabilities. Both of these options have drawbacks like custom compilation or opting into all debug statements being included into the kernel image. Given that we already have infrastructure to collect PM debugging information with CONFIG_PM_DEBUG and friends, let's change the pr_debug usage here to be pm_pr_dbg() instead so we can collect the wakeup information in the kernel logs. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
623217a0 |
|
10-Mar-2019 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeup: Drop wakeup_source_drop() After commit d856f39ac1cc ("PM / wakeup: Rework wakeup source timer cancellation") wakeup_source_drop() is a trivial wrapper around __pm_relax() and it has no users except for wakeup_source_destroy() and wakeup_source_trash() which also has no users, so drop it along with the latter and make wakeup_source_destroy() call __pm_relax() directly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
1fad17fb |
|
08-Mar-2019 |
Viresh Kumar <viresh.kumar@linaro.org> |
PM / wakeup: Rework wakeup source timer cancellation If wakeup_source_add() is called right after wakeup_source_remove() for the same wakeup source, timer_setup() may be called for a potentially scheduled timer which is incorrect. To avoid that, move the wakeup source timer cancellation from wakeup_source_drop() to wakeup_source_remove(). Moreover, make wakeup_source_remove() clear the timer function after canceling the timer to let wakeup_source_not_registered() treat unregistered wakeup sources in the same way as the ones that have never been registered. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.4+ <stable@vger.kernel.org> # 4.4+ [ rjw: Subject, changelog, merged two patches together ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7a5bd127 |
|
04-Mar-2019 |
Joe Perches <joe@perches.com> |
PM: Add and use pr_fmt() Prefix all printk/pr_<level> messages with "PM: " to make the logging a bit more consistent. Miscellanea: o Convert a few printks to pr_<level> o Whitespace to align to open parentheses o Remove embedded "PM: " from pr_debugs as pr_fmt adds it Signed-off-by: Joe Perches <joe@perches.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
d1c6b41b |
|
23-Jan-2019 |
Yangtao Li <tiny.windzz@gmail.com> |
PM / wakeup: fix kerneldoc comment for pm_wakeup_dev_event() This brings the kernel doc in line with the function signature. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
bccaadab |
|
25-May-2018 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
PM / wakeup: Make events_lock a RAW_SPINLOCK The `events_lock' is acquired during suspend while interrupts are disabled even on RT. The lock is taken only for a very brief moment. Make it a RAW lock which avoids "sleeping while atomic" warnings on RT. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1d644226 |
|
21-May-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: wakeup: Use pr_debug() for the "aborting suspend" message The message printed by pm_wakeup_pending() on wakeup detection is not very useful if someone is not interested specifically in debugging wakeup, so turn it into a pm_debug() one. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
2ef7c01c |
|
25-Apr-2018 |
Doug Berger <opendmb@gmail.com> |
PM / wakeup: Only update last time for active wakeup sources When wakelock support was added, the wakeup_source_add() function was updated to set the last_time value of the wakeup source. This has the unintended side effect of producing confusing output from pm_print_active_wakeup_sources() when a wakeup source is added prior to a sleep that is blocked by a different wakeup source. The function pm_print_active_wakeup_sources() will search for the most recently active wakeup source when no active source is found. If a wakeup source is added after a different wakeup source blocks the system from going to sleep it may have a later last_time value than the blocking source and be output as the last active wakeup source even if it has never actually been active. It looks to me like the change to wakeup_source_add() was made to prevent the wakelock garbage collection from accidentally dropping a wakelock during the narrow window between adding the wakelock to the wakelock list in wakelock_lookup_add() and the activation of the wakeup source in pm_wake_lock(). This commit changes the behavior so that only the last_time of the wakeup source used by a wakelock is initialized prior to adding it to the wakeup source list. This preserves the meaning of the last_time value as the last time the wakeup source was active and allows a wakeup source that has never been active to have a last_time value of 0. Fixes: b86ff9820fd5 (PM / Sleep: Add user space interface for manipulating wakeup sources, v3) Signed-off-by: Doug Berger <opendmb@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
00ee22c2 |
|
25-Apr-2018 |
Mahendran Ganesh <opensource.ganesh@gmail.com> |
PM / wakeup: Use seq_open() to show wakeup stats single_open() interface requires that the whole output must fit into a single buffer. This will lead to timeout when system memory is not in a good situation. This patch use seq_open() to show wakeup stats. This method need only one page, so timeout will not be observed. Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0026cef0 |
|
11-Jan-2018 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM / wakeup: Print warn if device gets enabled as wakeup source during sleep In general, wakeup settings are not supposed to be changed during any of the system wide PM phases. The reason is simply that it would break guarantees provided by the PM core, to properly act on active wakeup sources. However, there are exceptions to when, in particular, disabling a device as wakeup source makes sense. For example, in cases when a driver realizes that its device is dead during system suspend. For these scenarios, we don't need to care about acting on the wakeup source correctly, because a dead device shouldn't deliver wakeup signals. To this reasoning and to help users to properly manage wakeup settings, let's print a warning in cases someone calls device_wakeup_enable() during system sleep. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> [ rjw: Message to be printed ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7bf4e594 |
|
04-Jan-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeup: Do not fail dev_pm_attach_wake_irq() unnecessarily Returning an error code from dev_pm_attach_wake_irq() if device_wakeup_attach_irq() called by it returns an error is pointless, because the wakeup source used by it may be deleted by user space via sysfs at any time and in particular right after dev_pm_attach_wake_irq() has returned. Moreover, it requires the callers of dev_pm_attach_wake_irq() to create that wakeup source via device_wakeup_enable() upfront, but that obviously is racy with respect to the sysfs-based manipulations of it. To avoid the race, modify device_wakeup_attach_irq() to check that the wakeup source it is going to use is there (and return early otherwise), make it void (as it cannot fail after that change) and make dev_pm_attach_wake_irq() simply call it for the device unconditionally. Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9dbc64a5 |
|
01-Jan-2018 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeup: Drop redundant check from device_init_wakeup() Since device_wakeup_disable() checks the device's power.can_wakeup flag, device_init_wakeup() doesn't need to do that before calling it, so drop that redundant check from device_init_wakeup(). No intentional changes in functionality. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
d97c2e0d |
|
25-Dec-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeup: Drop redundant check from device_set_wakeup_enable() Since both device_wakeup_enable() and device_wakeup_disable() check if dev is not NULL and whether or not power.can_wakeup is set for it, device_set_wakeup_enable() doesn't have to do that, so drop that check from it. No intentional changes in functionality. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
#
86ddd2db |
|
18-Dec-2017 |
Brian Norris <briannorris@chromium.org> |
PM / wakeup: only recommend "call"ing device_init_wakeup() once I'll admit admit it: I've written bad driver code that tries to configure a device's wake IRQ without having called device_init_wakeup() first. But do you really have to ask ask me twice? Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
841b86f3 |
|
23-Oct-2017 |
Kees Cook <keescook@chromium.org> |
treewide: Remove TIMER_FUNC_TYPE and TIMER_DATA_TYPE casts With all callbacks converted, and the timer callback prototype switched over, the TIMER_FUNC_TYPE cast is no longer needed, so remove it. Conversion was done with the following scripts: perl -pi -e 's|\(TIMER_FUNC_TYPE\)||g' \ $(git grep TIMER_FUNC_TYPE | cut -d: -f1 | sort -u) perl -pi -e 's|\(TIMER_DATA_TYPE\)||g' \ $(git grep TIMER_DATA_TYPE | cut -d: -f1 | sort -u) The now unused macros are also dropped from include/linux/timer.h. Signed-off-by: Kees Cook <keescook@chromium.org>
|
#
96428e98 |
|
16-Oct-2017 |
Kees Cook <keescook@chromium.org> |
PM / core: Convert timers to use timer_setup() In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Removes test of .data field, since that will be going away. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f02f4f9d |
|
09-Aug-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / s2idle: Rename freeze_state enum and related items Rename the freeze_state enum representing the suspend-to-idle state machine states to s2idle_states and rename the related variables and functions accordingly. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
820b9b0c |
|
01-Aug-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeup: Set power.can_wakeup if wakeup_sysfs_add() fails Currently, an error from wakeup_sysfs_add() in device_set_wakeup_capable() causes the device's power.can_wakeup flag to remain unset even though the device technically is capable of signaling wakeup. If wakeup_sysfs_add() fails user space may not be able to enable the device to wake up the system from sleep states, but at least for some devices that does not matter. For this reason, set or clear power.can_wakeup upfront and if wakeup_sysfs_add() returns an error, print a message to the log. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ea0212f4 |
|
25-Jun-2017 |
Thomas Gleixner <tglx@linutronix.de> |
PM / wakeirq: Convert to SRCU The wakeirq infrastructure uses RCU to protect the list of wakeirqs. That breaks the irq bus locking infrastructure, which is allows sleeping functions to be called so interrupt controllers behind slow busses, e.g. i2c, can be handled. The wakeirq functions hold rcu_read_lock and call into irq functions, which in case of interrupts using the irq bus locking will trigger a might_sleep() splat. Convert the wakeirq infrastructure to Sleepable RCU and unbreak it. Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling) Reported-by: Brian Norris <briannorris@chromium.org> Suggested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Brian Norris <briannorris@chromium.org> Cc: 4.2+ <stable@vger.kernel.org> # 4.2+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
33e4f80e |
|
12-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ during suspend-to-idle transitions and, consequently, any events signaled through it wake up the system from that state. However, on some systems some of the events signaled via the ACPI SCI while suspended to idle should not cause the system to wake up. In fact, quite often they should just be discarded. Arguably, systems should not resume entirely on such events, but in order to decide which events really should cause the system to resume and which are spurious, it is necessary to resume up to the point when ACPI SCIs are actually handled and processed, which is after executing dpm_resume_noirq() in the system resume path. For this reasons, add a loop around freeze_enter() in which the platforms can process events signaled via multiplexed IRQ lines like the ACPI SCI and add suspend-to-idle hooks that can be used for this purpose to struct platform_freeze_ops. In the ACPI case, the ->wake hook is used for checking if the SCI has triggered while suspended and deferring the interrupt-induced system wakeup until the events signaled through it are actually processed sufficiently to decide whether or not the system should resume. In turn, the ->sync hook allows all of the relevant event queues to be flushed so as to prevent events from being missed due to race conditions. In addition to that, some ACPI code processing wakeup events needs to be modified to use the "hard" version of wakeup triggers, so that it will cause a system resume to happen on device-induced wakeup events even if the "soft" mechanism to prevent the system from suspending is not enabled. However, to preserve the existing behavior with respect to suspend-to-RAM, this only is done in the suspend-to-idle case and only if an SCI has occurred while suspended. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f3b7eaae |
|
06-Jun-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
Revert "ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle" Revert commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle) as it turned out to be premature and triggered a number of different issues on various systems. That includes, but is not limited to, premature suspend-to-RAM aborts on Dell XPS 13 (9343) reported by Dominik. The issue the commit in question attempted to address is real and will need to be taken care of going forward, but evidently more work is needed for this purpose. Reported-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
60d4553b |
|
13-May-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeup: Fix up wakeup_source_report_event() Commit 8a537ece3d94 (PM / wakeup: Integrate mechanism to abort transitions in progress) modified wakeup_source_report_event() and wakeup_source_activate() to make it possible to call pm_system_wakeup() from the latter if so indicated by the caller of the former (via a new function argument added by that commit), but it overlooked the fact that in some situations wakeup_source_report_event() is called to signal a "hard" event (ie. such that should abort a system suspend in progress) after pm_stay_awake() has been called for the same wakeup source object, in which case the pm_system_wakeup() will not trigger. To work around this issue, modify wakeup_source_activate() and wakeup_source_report_event() again so that pm_system_wakeup() is called by the latter directly (if its last argument is true), in which case the additional argument does not need to be passed to wakeup_source_activate() any more, so drop it from there. Fixes: 8a537ece3d94 (PM / wakeup: Integrate mechanism to abort transitions in progress) Reported-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
eed4d47e |
|
26-Apr-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle The ACPI SCI (System Control Interrupt) is set up as a wakeup IRQ during suspend-to-idle transitions and, consequently, any events signaled through it wake up the system from that state. However, on some systems some of the events signaled via the ACPI SCI while suspended to idle should not cause the system to wake up. In fact, quite often they should just be discarded. Arguably, systems should not resume entirely on such events, but in order to decide which events really should cause the system to resume and which are spurious, it is necessary to resume up to the point when ACPI SCIs are actually handled and processed, which is after executing dpm_resume_noirq() in the system resume path. For this reasons, add a loop around freeze_enter() in which the platforms can process events signaled via multiplexed IRQ lines like the ACPI SCI and add suspend-to-idle hooks that can be used for this purpose to struct platform_freeze_ops. In the ACPI case, the ->wake hook is used for checking if the SCI has triggered while suspended and deferring the interrupt-induced system wakeup until the events signaled through it are actually processed sufficiently to decide whether or not the system should resume. In turn, the ->sync hook allows all of the relevant event queues to be flushed so as to prevent events from being missed due to race conditions. In addition to that, some ACPI code processing wakeup events needs to be modified to use the "hard" version of wakeup triggers, so that it will cause a system resume to happen on device-induced wakeup events even if the "soft" mechanism to prevent the system from suspending is not enabled (that also helps to catch device-induced wakeup events occurring during suspend transitions in progress). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
8a537ece |
|
26-Apr-2017 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeup: Integrate mechanism to abort transitions in progress The system wakeup framework is not very consistent with respect to the way it handles suspend-to-idle and generally wakeup events occurring during transitions to system low-power states. First off, system transitions in progress are aborted by the event reporting helpers like pm_wakeup_event() only if the wakeup_count sysfs attribute is in use (as documented), but there are cases in which system-wide transitions should be aborted even if that is not the case. For example, a wakeup signal from a designated wakeup device during system-wide PM transition, it should cause the transition to be aborted right away. Moreover, there is a freeze_wake() call in wakeup_source_activate(), but that really is only effective after suspend_freeze_state has been set to FREEZE_STATE_ENTER by freeze_enter(). However, it is very unlikely that wakeup_source_activate() will ever be called at that time, as it could only be triggered by a IRQF_NO_SUSPEND interrupt handler, so wakeups from suspend-to-idle don't really occur in wakeup_source_activate(). At the same time there is a way to abort a system suspend in progress (or wake up the system from suspend-to-idle), which is by calling pm_system_wakeup(), but in turn that doesn't cause any wakeup source objects to be activated, so it will not be covered by wakeup source statistics and will not prevent the system from suspending again immediately (in case autosleep is used, for example). Consequently, if anyone wants to abort system transitions in progress and allow the wakeup_count mechanism to work, they need to use both pm_system_wakeup() and pm_wakeup_event(), say, at the same time which is awkward. For the above reasons, make it possible to trigger pm_system_wakeup() from within wakeup_source_activate() and provide a new pm_wakeup_hard_event() helper to do so within the wakeup framework. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
174cd4b1 |
|
02-Feb-2017 |
Ingo Molnar <mingo@kernel.org> |
sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h> Fix up affected files that include this signal functionality via sched.h. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
8b0e1953 |
|
24-Dec-2016 |
Thomas Gleixner <tglx@linutronix.de> |
ktime: Cleanup ktime_set() usage ktime_set(S,N) was required for the timespec storage type and is still useful for situations where a Seconds and Nanoseconds part of a time value needs to be converted. For anything where the Seconds argument is 0, this is pointless and can be replaced with a simple assignment. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org>
|
#
2456e855 |
|
25-Dec-2016 |
Thomas Gleixner <tglx@linutronix.de> |
ktime: Get rid of the union ktime is a union because the initial implementation stored the time in scalar nanoseconds on 64 bit machine and in a endianess optimized timespec variant for 32bit machines. The Y2038 cleanup removed the timespec variant and switched everything to scalar nanoseconds. The union remained, but become completely pointless. Get rid of the union and just keep ktime_t as simple typedef of type s64. The conversion was done with coccinelle and some manual mopping up. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org>
|
#
9320f95c |
|
07-Dec-2016 |
xing wei <xing.wei@intel.com> |
PM / sleep: Print active wakeup sources when blocking on wakeup_count reads If there are any wakeup events being processed, read operation on /sys/power/wakeup_count will be blocked, so print the names of all active wakeup sources to help to find out who is preventing system suspend from triggering. While at it change pr_info() in pm_print_active_wakeup_sources() to pr_debug() to avoid excessive log noise. Signed-off-by: xing wei <xing.wei@intel.com> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4f48ec8a |
|
23-Jul-2016 |
Markus Elfring <elfring@users.sourceforge.net> |
PM-wakeup: Delete unnecessary checks before three function calls The following functions test whether their argument is NULL and then return immediately. * dev_pm_arm_wake_irq * dev_pm_disarm_wake_irq * wakeup_source_unregister Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Acked-by: Pavel Machek <pavel@ucw.cz> [ rjw: Minor whitespace adjustments ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
16669bef |
|
06-Apr-2016 |
Strashko, Grygorii <grygorii.strashko@ti.com> |
PM / wakeirq: fix wakeirq setting after wakup re-configuration from sysfs Now wakeirq stops working for device if wakeup option for this device will be reconfigured through sysfs, like: echo disabled > /sys/devices/platform/extcon_usb1/power/wakeup echo enabled > /sys/devices/platform/extcon_usb1/power/wakeup Once above set of commands is executed the device's wakeup_source opject will be recreated and dev->power.wakeup->wakeirq field will contain NULL. As result, device_wakeup_arm_wake_irqs() will not arm wakeirq for the affected device. Hece, lets try to fix it in the following way: check for dev->wakeirq field when device_wakeup_attach() is called and if !NULL re-attach wakeirq to the device Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7236214c |
|
09-Sep-2015 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
PM / wakeup: wakeup_source_create: use kstrdup_const Using kstrdup_const allows us to save a little runtime memory (and a string copy) in the common case where name is a string literal. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
a6f5f0dd |
|
15-Sep-2015 |
Alexandra Yates <alexandra.yates@linux.intel.com> |
PM / sleep: Report interrupt that caused system wakeup Add a sysfs attribute, /sys/power/pm_wakeup_irq, reporting the IRQ number of the first wakeup interrupt (that is, the first interrupt from an IRQ line armed for system wakeup) seen by the kernel during the most recent system suspend/resume cycle. This feature will be useful for system wakeup diagnostics of spurious wakeup interrupts. Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com> [ rjw: Fixed up pm_wakeup_irq definition ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
6d3dab7d |
|
07-Jul-2015 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / wakeirq: Avoid setting power.wakeirq too hastily If dev_pm_attach_wake_irq() fails, the device's power.wakeirq field should not be set to point to the struct wake_irq passed to that function, as that object will be freed going forward. For this reason, make dev_pm_attach_wake_irq() first call device_wakeup_attach_irq() and only set the device's power.wakeirq field if that's successful. That requires device_wakeup_attach_irq() to be called under the device's power.lock lock, but since dev_pm_attach_wake_irq() is the only caller of it, the requisite changes are easy to make. Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling) Reported-by: Felipe Balbi <balbi@ti.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
4990d4fe |
|
18-May-2015 |
Tony Lindgren <tony@atomide.com> |
PM / Wakeirq: Add automated device wake IRQ handling Turns out we can automate the handling for the device_may_wakeup() quite a bit by using the kernel wakeup source list as suggested by Rafael J. Wysocki <rjw@rjwysocki.net>. And as some hardware has separate dedicated wake-up interrupt in addition to the IO interrupt, we can automate the handling by adding a generic threaded interrupt handler that just calls the device PM runtime to wake up the device. This allows dropping code from device drivers as we currently are doing it in multiple ways, and often wrong. For most drivers, we should be able to drop the following boilerplate code from runtime_suspend and runtime_resume functions: ... device_init_wakeup(dev, true); ... if (device_may_wakeup(dev)) enable_irq_wake(irq); ... if (device_may_wakeup(dev)) disable_irq_wake(irq); ... device_init_wakeup(dev, false); ... We can replace it with just the following init and exit time code: ... device_init_wakeup(dev, true); dev_pm_set_wake_irq(dev, irq); ... dev_pm_clear_wake_irq(dev); device_init_wakeup(dev, false); ... And for hardware with dedicated wake-up interrupts: ... device_init_wakeup(dev, true); dev_pm_set_dedicated_wake_irq(dev, irq); ... dev_pm_clear_wake_irq(dev); device_init_wakeup(dev, false); ... Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7f436055 |
|
15-May-2015 |
Jin Qian <jinqian@android.com> |
PM / wakeup: add a dummy wakeup_source to record statistics After a wakeup_source is destroyed, we lost all information such as how long this wakeup_source has been active. Add a dummy wakeup_source to record such info. Signed-off-by: Jin Qian <jinqian@android.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b6ec9452 |
|
06-May-2015 |
Jin Qian <jinqian@android.com> |
PM / wakeup: validate wakeup source before activating it. A rogue wakeup source not registered in wakeup_sources list is not visible from wakeup_sources_stats_show. Check if the wakeup source is registered properly by looking at the timer struct. Signed-off-by: Jin Qian <jinqian@android.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9f6a240e |
|
15-Apr-2015 |
Joe Perches <joe@perches.com> |
power: wakeup: remove use of seq_printf return value The seq_printf return value, because it's frequently misused, will eventually be converted to void. See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to seq_has_overflowed() and make public") Signed-off-by: Joe Perches <joe@perches.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
432ec92b |
|
02-Mar-2015 |
Boris Brezillon <bbrezillon@kernel.org> |
PM / wakeup: export pm_system_wakeup symbol Export pm_system_wakeup function to allow irq handlers to deal with system wakeup. This is needed for shared IRQ lines where one of the handler is registered with IRQF_NO_SUSPEND, while the other ones want to configure it as a wakeup source. In this specific case, irq core does not handle the wakeup process and leave the decision to each irq handler. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
068765ba |
|
01-Sep-2014 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM / sleep: Mechanism for aborting system suspends unconditionally It sometimes may be necessary to abort a system suspend in progress or wake up the system from suspend-to-idle even if the pm_wakeup_event()/pm_stay_awake() mechanism is not enabled. For this purpose, introduce a new global variable pm_abort_suspend and make pm_wakeup_pending() check its value. Also add routines for manipulating that variable. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0c5ff0ef |
|
28-May-2014 |
Zhang Rui <rui.zhang@intel.com> |
PM / sleep: unregister wakeup source when disabling device wakeup When enabling a device' wakeup capability, a wakeup source is created for the device automatically. But the wakeup source is not unregistered when disabling the device' wakeup capability. This results in zombie wakeup sources, after devices/drivers are unregistered. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
bb177fed |
|
12-Jun-2013 |
Julius Werner <jwerner@chromium.org> |
PM / Sleep: Print last wakeup source on failed wakeup_count write Commit a938da06 introduced a useful little log message to tell users/debuggers which wakeup source aborted a suspend. However, this message is only printed if the abort happens during the in-kernel suspend path (after writing /sys/power/state). The full specification of the /sys/power/wakeup_count facility allows user-space power managers to double-check if wakeups have already happened before it actually tries to suspend (e.g. while it was running user-space pre-suspend hooks), by writing the last known wakeup_count value to /sys/power/wakeup_count. This patch changes the sysfs handler for that node to also print said log message if that write fails, so that we can figure out the offending wakeup source for both kinds of suspend aborts. Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
9350de06 |
|
31-May-2013 |
Bernie Thompson <bhthompson@chromium.org> |
PM / wakeup: Adjust messaging for wake events during suspend This adds in a new message to the wakeup code which adds an indication to the log that suspend was cancelled due to a wake event occouring during the suspend sequence. It also adjusts the message printed in suspend.c to reflect the potential that a suspend was aborted, as opposed to a device failing to suspend. Without these message adjustments one can end up with a kernel log that says that a device failed to suspend with no actual device suspend failures, which can be confusing to the log examiner. Signed-off-by: Bernie Thompson <bhthompson@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7e73c5ae |
|
06-Feb-2013 |
Zhang Rui <rui.zhang@intel.com> |
PM: Introduce suspend state PM_SUSPEND_FREEZE PM_SUSPEND_FREEZE state is a general state that does not need any platform specific support, it equals frozen processes + suspended devices + idle processors. Compared with PM_SUSPEND_MEMORY, PM_SUSPEND_FREEZE saves less power because the system is still in a running state. PM_SUSPEND_FREEZE has less resume latency because it does not touch BIOS, and the processors are in idle state. Compared with RTPM/idle, PM_SUSPEND_FREEZE saves more power as 1. the processor has longer sleep time because processes are frozen. The deeper c-state the processor supports, more power saving we can get. 2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get more power saving from the devices that does not have good RTPM support. This state is useful for 1) platforms that do not have STR, or have a broken STR. 2) platforms that have an extremely low power idle state, which can be used to replace STR. The following describes how PM_SUSPEND_FREEZE state works. 1. echo freeze > /sys/power/state 2. the processes are frozen. 3. all the devices are suspended. 4. all the processors are blocked by a wait queue 5. all the processors idles and enters (Deep) c-state. 6. an interrupt fires. 7. a processor is woken up and handles the irq. 8. if it is a general event, a) the irq handler runs and quites. b) goto step 4. 9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving, a) the irq handler runs and activate the wakeup source b) wakeup_source_activate() notifies the wait queue. c) system starts resuming from PM_SUSPEND_FREEZE 10. all the devices are resumed. 11. all the processes are unfrozen. 12. system is back to working. Known Issue: The wakeup of this new PM_SUSPEND_FREEZE state may behave differently from the previous suspend state. Take ACPI platform for example, there are some GPEs that only enabled when the system is in sleep state, to wake the system backk from S3/S4. But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE. This means we may lose some wake event. But on the other hand, as we do not disable all the Interrupts during PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are not available for S3/S4. The patches has been tested on an old Sony laptop, and here are the results: Average Power: 1. RPTM/idle for half an hour: 14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W 2. Freeze for half an hour: 11W, 10.4W, 9.4W, 11.3W 10.5W 3. RTPM/idle for three hours: 11.6W 4. Freeze for three hours: 10W 5. Suspend to Memory: 0.5~0.9W Average Resume Latency: 1. RTPM/idle with a black screen: (From pressing keyboard to screen back) Less than 0.2s 2. Freeze: (From pressing power button to screen back) 2.50s 3. Suspend to Memory: (From pressing power button to screen back) 4.33s >From the results, we can see that all the platforms should benefit from this patch, even if it does not have Low Power S0. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
49550709 |
|
06-Sep-2012 |
John Stultz <john.stultz@linaro.org> |
PM / wakeup: Use irqsave/irqrestore for events_lock Jon Medhurst (Tixy) recently noticed a problem with the events_lock usage. One of the Android patches that uses wakeup_sources calls wakeup_source_add() with irqs disabled. However, the event_lock usage in wakeup_source_add() uses spin_lock_irq()/spin_unlock_irq(), which reenables interrupts. This results in lockdep warnings. The fix is to use spin_lock_irqsave()/spin_lock_irqrestore() instead for the events_lock. References: https://bugs.launchpad.net/linaro-landing-team-arm/+bug/1037565 Reported-and-debugged-by: Jon Medhurst (Tixy) <tixy@linaro.org> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
a938da06 |
|
11-Aug-2012 |
Todd Poynor <toddpoynor@google.com> |
PM / Sleep: Print name of wakeup source that aborts suspend A driver or app may repeatedly request a wakeup source while the system is attempting to enter suspend, which may indicate a bug or at least point out a highly active system component that is responsible for decreased battery life on a mobile device. Even when the incidence of suspend abort is not severe, identifying wakeup sources that frequently abort suspend can be a useful clue for power management analysis. In some cases the existing stats can point out the offender where there is an unexpectedly high activation count that stands out from the others, but in other cases the wakeup source frequently taken just after the rest of the system thinks its time to suspend might not stand out in the overall stats. It is also often useful to have information about what's been happening recently, rather than totals of all activity for the system boot. It's suggested to dump a line about which wakeup source aborted suspend to aid analysis of these situations. Signed-off-by: Todd Poynor <toddpoynor@google.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
b86ff982 |
|
29-Apr-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Add user space interface for manipulating wakeup sources, v3 Android allows user space to manipulate wakelocks using two sysfs file located in /sys/power/, wake_lock and wake_unlock. Writing a wakelock name and optionally a timeout to the wake_lock file causes the wakelock whose name was written to be acquired (it is created before is necessary), optionally with the given timeout. Writing the name of a wakelock to wake_unlock causes that wakelock to be released. Implement an analogous interface for user space using wakeup sources. Add the /sys/power/wake_lock and /sys/power/wake_unlock files allowing user space to create, activate and deactivate wakeup sources, such that writing a name and optionally a timeout to wake_lock causes the wakeup source of that name to be activated, optionally with the given timeout. If that wakeup source doesn't exist, it will be created and then activated. Writing a name to wake_unlock causes the wakeup source of that name, if there is one, to be deactivated. Wakeup sources created with the help of wake_lock that haven't been used for more than 5 minutes are garbage collected and destroyed. Moreover, there can be only WL_NUMBER_LIMIT wakeup sources created with the help of wake_lock present at a time. The data type used to track wakeup sources created by user space is called "struct wakelock" to indicate the origins of this feature. This version of the patch includes an rbtree manipulation fix from John Stultz. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NeilBrown <neilb@suse.de>
|
#
55850945 |
|
29-Apr-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Add "prevent autosleep time" statistics to wakeup sources Android uses one wakelock statistics that is only necessary for opportunistic sleep. Namely, the prevent_suspend_time field accumulates the total time the given wakelock has been locked while "automatic suspend" was enabled. Add an analogous field, prevent_sleep_time, to wakeup sources and make it behave in a similar way. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
7483b4a4 |
|
29-Apr-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Implement opportunistic sleep, v2 Introduce a mechanism by which the kernel can trigger global transitions to a sleep state chosen by user space if there are no active wakeup sources. It consists of a new sysfs attribute, /sys/power/autosleep, that can be written one of the strings returned by reads from /sys/power/state, an ordered workqueue and a work item carrying out the "suspend" operations. If a string representing the system's sleep state is written to /sys/power/autosleep, the work item triggering transitions to that state is queued up and it requeues itself after every execution until user space writes "off" to /sys/power/autosleep. That work item enables the detection of wakeup events using the functions already defined in drivers/base/power/wakeup.c (with one small modification) and calls either pm_suspend(), or hibernate() to put the system into a sleep state. If a wakeup event is reported while the transition is in progress, it will abort the transition and the "system suspend" work item will be queued up again. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: NeilBrown <neilb@suse.de>
|
#
6791e36c |
|
29-Apr-2012 |
Arve Hjønnevåg <arve@android.com> |
PM / Sleep: Add wakeup_source_activate and wakeup_source_deactivate tracepoints Add tracepoints to wakeup_source_activate and wakeup_source_deactivate. Useful for checking that specific wakeup sources overlap as expected. Signed-off-by: Arve Hjønnevåg <arve@android.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
30e3ce6d |
|
29-Apr-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Change wakeup source statistics to follow Android Wakeup statistics used by Android are slightly different from what we have in wakeup sources at the moment and there aren't any known users of those statistics other than Android, so modify them to make it easier for Android to switch to wakeup sources. This removes the struct wakeup_source's hit_cout field, which is very rough and therefore not very useful, and adds two new fields, wakeup_count and expire_count. The first one tracks how many times the wakeup source is activated with events_check_enabled set (which roughly corresponds to the situations when a system power transition to a sleep state is in progress and would be aborted by this wakeup source if it were the only active one at that time) and the second one is the number of times the wakeup source has been activated with a timeout that expired. Additionally, the last_time field is now updated when the wakeup source is deactivated too (previously it was only updated during the wakeup source's activation), which seems to be what Android does with the analogous counter for wakelocks. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
60af1066 |
|
29-Apr-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Use wait queue to signal "no wakeup events in progress" The current wakeup source deactivation code doesn't do anything when the counter of wakeup events in progress goes down to zero, which requires pm_get_wakeup_count() to poll that counter periodically. Although this reduces the average time it takes to deactivate a wakeup source, it also may lead to a substantial amount of unnecessary polling if there are extended periods of wakeup activity. Thus it seems reasonable to use a wait queue for signaling the "no wakeup events in progress" condition and remove the polling. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: mark gross <markgross@thegnar.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8671bbc1 |
|
21-Feb-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Add more wakeup source initialization routines The existing wakeup source initialization routines are not particularly useful for wakeup sources that aren't created by wakeup_source_create(), because their users have to open code filling the objects with zeros and setting their names. For this reason, introduce routines that can be used for initializing, for example, static wakeup source objects. Requested-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
4782e165 |
|
17-Feb-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Make __pm_stay_awake() delete wakeup source timers If __pm_stay_awake() is called after __pm_wakeup_event() for the same wakep source object before its timer expires, it won't cancel the timer, so the wakeup source will be deactivated from the timer function as scheduled by __pm_wakeup_event(). In that case __pm_stay_awake() doesn't have any effect beyond incrementing the wakeup source's event_count field, although it should cancel the timer and make the wakeup source stay active until __pm_relax() is called for it. To fix this problem make __pm_stay_awake() delete the wakeup source's timer and ensure that it won't be deactivated from the timer funtion afterwards by clearing its timer_expires field. Reported-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
da863cdd |
|
17-Feb-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Fix race conditions related to wakeup source timer function If __pm_wakeup_event() has been used (with a nonzero timeout) to report a wakeup event and then __pm_relax() immediately followed by __pm_stay_awake() is called or __pm_wakeup_event() is called once again for the same wakeup source object before its timer expires, the timer function pm_wakeup_timer_fn() may still be run as a result of the previous __pm_wakeup_event() call. In either of those cases it may mistakenly deactivate the wakeup source that has just been activated. To prevent that from happening, make wakeup_source_deactivate() clear the wakeup source's timer_expires field and make pm_wakeup_timer_fn() check if timer_expires is different from zero and if it's not in future before calling wakeup_source_deactivate() (if timer_expires is 0, it means that the timer has just been deleted and if timer_expires is in future, it means that the timer has just been rescheduled to a different time). Reported-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
d94aff87 |
|
17-Feb-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Fix possible infinite loop during wakeup source destruction If wakeup_source_destroy() is called for an active wakeup source that is never deactivated, it will spin forever. To prevent that from happening, make wakeup_source_destroy() call __pm_relax() for the wakeup source object it is about to free instead of waiting until it will be deactivated by someone else. However, for this to work it also needs to make sure that the timer function will not be executed after the final __pm_relax(), so make it run del_timer_sync() on the wakeup source's timer beforehand. Additionally, update the kerneldoc comment to document the requirement that __pm_stay_awake() and __pm_wakeup_event() must not be run in parallel with wakeup_source_destroy(). Reported-by: Arve Hjønnevåg <arve@android.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
7c95149b |
|
10-Feb-2012 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Sleep: Initialize wakeup source locks in wakeup_source_add() Initialize wakeup source locks in wakeup_source_add() instead of wakeup_source_create(), because otherwise the locks of the wakeup sources that haven't been allocated with wakeup_source_create() aren't initialized and handled properly. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
1b6bc32f |
|
27-May-2011 |
Paul Gortmaker <paul.gortmaker@windriver.com> |
drivers/base: Add export.h for EXPORT_SYMBOL/THIS_MODULE as required. Most of these files were implicitly getting EXPORT_SYMBOL via device.h which was including module.h, but that path will be broken soon. [ with input from Stephen Rothwell <sfr@canb.auug.org.au> ] Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
#
8f88893c |
|
26-Sep-2011 |
Alan Stern <stern@rowland.harvard.edu> |
PM: Update the policy on default wakeup settings This patch (as1485) documents a change to the kernel's default wakeup policy. Devices that forward wakeup requests between buses should be enabled for wakeup by default. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
13e38136 |
|
11-May-2011 |
Eric Dumazet <eric.dumazet@gmail.com> |
PM / Wakeup: Remove useless synchronize_rcu() call wakeup_source_add() adds an item into wakeup_sources list. There is no need to call synchronize_rcu() at this point. Its only needed in wakeup_source_remove() Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
22110faf |
|
26-Apr-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Wakeup: Fix initialization of wakeup-related device sysfs files It turns out that some PCI devices are only found to be wakeup-capable during registration, in which case, when device_set_wakeup_capable() is called, device_is_registered() already returns 'true' for the given device, but dpm_sysfs_add() hasn't been called for it yet. This leads to situations in which the device's power.can_wakeup flag is not set as requested because of failing wakeup_sysfs_add() and its wakeup-related sysfs files are not created, although they should be present. This is a post-2.6.38 regression introduced by commit cb8f51bdadb7969139c2e39c2defd4cde98c1 (PM: Do not create wakeup sysfs files for devices that cannot wake up). To work around this problem initialize the device's power.entry field to an empty list head and make device_set_wakeup_capable() check if it is still empty before attempting to add the devices wakeup-related sysfs files with wakeup_sysfs_add(). Namely, if power.entry is still empty at this point, device_pm_add() hasn't been called yet for the device and its wakeup-related files will be created later, so device_set_wakeup_capable() doesn't have to create them. Reported-and-tested-by: Tino Keitel <tino.keitel@tikei.de> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
cb8f51bd |
|
08-Feb-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Do not create wakeup sysfs files for devices that cannot wake up Currently, wakeup sysfs attributes are created for all devices, regardless of whether or not they are wakeup-capable. This is excessive and complicates wakeup device identification from user space (i.e. to identify wakeup-capable devices user space has to read /sys/devices/.../power/wakeup for all devices and see if they are not empty). Fix this issue by avoiding to create wakeup sysfs files for devices that cannot wake up the system from sleep states (i.e. whose power.can_wakeup flags are unset during registration) and modify device_set_wakeup_capable() so that it adds (or removes) the relevant sysfs attributes if a device's wakeup capability status is changed. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
790c7885 |
|
31-Jan-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Wakeup: Don't update events_check_enabled in pm_get_wakeup_count() Since pm_save_wakeup_count() has just been changed to clear events_check_enabled unconditionally before checking if there are any new wakeup events registered since the last read from /sys/power/wakeup_count, the detection of wakeup events during suspend may be disabled, after it's been enabled, by writing a "wrong" value back to /sys/power/wakeup_count. For this reason, it is not necessary to update events_check_enabled in pm_get_wakeup_count() any more. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
378eef99 |
|
31-Jan-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Wakeup: Make pm_save_wakeup_count() work as documented According to Documentation/ABI/testing/sysfs-power, the /sys/power/wakeup_count interface should only make the kernel react to wakeup events during suspend if the last write to it has been successful. However, if /sys/power/wakeup_count is written to two times in a row, where the first write is successful and the second is not, the kernel will still react to wakeup events during suspend due to a bug in pm_save_wakeup_count(). Fix the bug by making pm_save_wakeup_count() clear events_check_enabled unconditionally before checking if there are any new wakeup events registered since the previous read from /sys/power/wakeup_count. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
023d3779 |
|
31-Jan-2011 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Wakeup: Combine atomic counters to avoid reordering issues The memory barrier in wakeup_source_deactivate() is supposed to prevent the callers of pm_wakeup_pending() and pm_get_wakeup_count() from seeing the new value of events_in_progress (0, in particular) and the old value of event_count at the same time. However, if wakeup_source_deactivate() is executed by CPU0 and, for instance, pm_wakeup_pending() is executed by CPU1, where both processors can reorder operations, the memory barrier in wakeup_source_deactivate() doesn't affect CPU1 which can reorder reads. In that case CPU1 may very well decide to fetch event_count before it's modified and events_in_progress after it's been updated, so pm_wakeup_pending() may fail to detect a wakeup event. This issue can be addressed by using a single atomic variable to store both events_in_progress and event_count, so that they can be updated together in a single atomic operation. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
a2867e08 |
|
03-Dec-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Wakeup: Replace pm_check_wakeup_events() with pm_wakeup_pending() To avoid confusion with the meaning and return value of pm_check_wakeup_events() replace it with pm_wakeup_pending() that will work the other way around (ie. return true when system-wide power transition should be aborted). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
9c034392 |
|
19-Oct-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Wakeup: Show wakeup sources statistics in debugfs There may be wakeup sources that aren't associated with any devices and their statistics information won't be available from sysfs. Also, for debugging purposes it is convenient to have all of the wakeup sources statistics available from one place. For these reasons, introduce new file "wakeup_sources" in debugfs containing those statistics. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
074037ec |
|
22-Sep-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM / Wakeup: Introduce wakeup source objects and event statistics (v3) Introduce struct wakeup_source for representing system wakeup sources within the kernel and for collecting statistics related to them. Make the recently introduced helper functions pm_wakeup_event(), pm_stay_awake() and pm_relax() use struct wakeup_source objects internally, so that wakeup statistics associated with wakeup devices can be collected and reported in a consistent way (the definition of pm_relax() is changed, which is harmless, because this function is not called directly by anyone yet). Introduce new wakeup-related sysfs device attributes in /sys/devices/.../power for reporting the device wakeup statistics. Change the global wakeup events counters event_count and events_in_progress into atomic variables, so that it is not necessary to acquire a global spinlock in pm_wakeup_event(), pm_stay_awake() and pm_relax(), which should allow us to avoid lock contention in these functions on SMP systems with many wakeup devices. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
4eb241e5 |
|
07-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Do not use dynamically allocated objects in pm_wakeup_event() Originally, pm_wakeup_event() uses struct delayed_work objects, allocated with GFP_ATOMIC, to schedule the execution of pm_relax() in future. However, as noted by Alan Stern, it is not necessary to do that, because all pm_wakeup_event() calls can use one static timer that will always be set to expire at the latest time passed to pm_wakeup_event(). The modifications are based on the example code posted by Alan. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
#
c125e96f |
|
05-Jul-2010 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Make it possible to avoid races between wakeup and system sleep One of the arguments during the suspend blockers discussion was that the mainline kernel didn't contain any mechanisms making it possible to avoid races between wakeup and system suspend. Generally, there are two problems in that area. First, if a wakeup event occurs exactly when /sys/power/state is being written to, it may be delivered to user space right before the freezer kicks in, so the user space consumer of the event may not be able to process it before the system is suspended. Second, if a wakeup event occurs after user space has been frozen, it is not generally guaranteed that the ongoing transition of the system into a sleep state will be aborted. To address these issues introduce a new global sysfs attribute, /sys/power/wakeup_count, associated with a running counter of wakeup events and three helper functions, pm_stay_awake(), pm_relax(), and pm_wakeup_event(), that may be used by kernel subsystems to control the behavior of this attribute and to request the PM core to abort system transitions into a sleep state already in progress. The /sys/power/wakeup_count file may be read from or written to by user space. Reads will always succeed (unless interrupted by a signal) and return the current value of the wakeup events counter. Writes, however, will only succeed if the written number is equal to the current value of the wakeup events counter. If a write is successful, it will cause the kernel to save the current value of the wakeup events counter and to abort the subsequent system transition into a sleep state if any wakeup events are reported after the write has returned. [The assumption is that before writing to /sys/power/state user space will first read from /sys/power/wakeup_count. Next, user space consumers of wakeup events will have a chance to acknowledge or veto the upcoming system transition to a sleep state. Finally, if the transition is allowed to proceed, /sys/power/wakeup_count will be written to and if that succeeds, /sys/power/state will be written to as well. Still, if any wakeup events are reported to the PM core by kernel subsystems after that point, the transition will be aborted.] Additionally, put a wakeup events counter into struct dev_pm_info and make these per-device wakeup event counters available via sysfs, so that it's possible to check the activity of various wakeup event sources within the kernel. To illustrate how subsystems can use pm_wakeup_event(), make the low-level PCI runtime PM wakeup-handling code use it. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Acked-by: markgross <markgross@thegnar.org> Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
|