kernel/drivers/base/power/wakeup.c, branch linux-4.1.y

power: wakeup: remove use of seq_printf return value

2015-04-15T23:35:24Z

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 Cc: "Rafael J. Wysocki" Cc: Pavel Machek Cc: Len Brown Cc: Greg Kroah-Hartman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

PM / wakeup: export pm_system_wakeup symbol

2015-03-04T21:10:19Z

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 Reviewed-by: Alexandre Belloni Acked-by: Nicolas Ferre Acked-by: Mark Rutland Signed-off-by: Rafael J. Wysocki

PM / sleep: Mechanism for aborting system suspends unconditionally

2014-09-01T11:47:49Z

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

PM / sleep: unregister wakeup source when disabling device wakeup

2014-05-30T11:39:29Z

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 Signed-off-by: Rafael J. Wysocki

PM / Sleep: Print last wakeup source on failed wakeup_count write

2013-06-20T22:35:12Z

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 Signed-off-by: Rafael J. Wysocki

PM / wakeup: Adjust messaging for wake events during suspend

2013-06-11T21:53:37Z

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 Signed-off-by: Rafael J. Wysocki

PM: Introduce suspend state PM_SUSPEND_FREEZE

2013-02-09T21:30:44Z

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 Signed-off-by: Rafael J. Wysocki

PM / wakeup: Use irqsave/irqrestore for events_lock

2012-09-06T21:19:06Z

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) Signed-off-by: John Stultz Signed-off-by: Rafael J. Wysocki

PM / Sleep: Print name of wakeup source that aborts suspend

2012-08-17T17:40:50Z

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 Signed-off-by: Rafael J. Wysocki

PM / Sleep: Add user space interface for manipulating wakeup sources, v3

2012-05-01T19:26:05Z

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 Acked-by: Greg Kroah-Hartman Reviewed-by: NeilBrown