2009-06-10 06:27:12 +07:00
|
|
|
/*
|
|
|
|
* kernel/power/suspend.c - Suspend to RAM and standby functionality.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003 Patrick Mochel
|
|
|
|
* Copyright (c) 2003 Open Source Development Lab
|
|
|
|
* Copyright (c) 2009 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
|
|
|
|
*
|
|
|
|
* This file is released under the GPLv2.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/init.h>
|
2011-05-26 23:48:41 +07:00
|
|
|
#include <linux/kmod.h>
|
2009-06-10 06:27:12 +07:00
|
|
|
#include <linux/console.h>
|
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/syscalls.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 15:04:11 +07:00
|
|
|
#include <linux/gfp.h>
|
2010-05-29 03:32:14 +07:00
|
|
|
#include <linux/io.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/suspend.h>
|
2011-03-15 06:43:46 +07:00
|
|
|
#include <linux/syscore_ops.h>
|
2011-01-06 01:49:01 +07:00
|
|
|
#include <trace/events/power.h>
|
2009-06-10 06:27:12 +07:00
|
|
|
|
|
|
|
#include "power.h"
|
|
|
|
|
|
|
|
const char *const pm_states[PM_SUSPEND_MAX] = {
|
|
|
|
[PM_SUSPEND_STANDBY] = "standby",
|
|
|
|
[PM_SUSPEND_MEM] = "mem",
|
|
|
|
};
|
|
|
|
|
2010-11-16 20:14:02 +07:00
|
|
|
static const struct platform_suspend_ops *suspend_ops;
|
2009-06-10 06:27:12 +07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* suspend_set_ops - Set the global suspend method table.
|
|
|
|
* @ops: Pointer to ops structure.
|
|
|
|
*/
|
2010-11-16 20:14:02 +07:00
|
|
|
void suspend_set_ops(const struct platform_suspend_ops *ops)
|
2009-06-10 06:27:12 +07:00
|
|
|
{
|
|
|
|
mutex_lock(&pm_mutex);
|
|
|
|
suspend_ops = ops;
|
|
|
|
mutex_unlock(&pm_mutex);
|
|
|
|
}
|
2011-06-27 06:01:07 +07:00
|
|
|
EXPORT_SYMBOL_GPL(suspend_set_ops);
|
2009-06-10 06:27:12 +07:00
|
|
|
|
|
|
|
bool valid_state(suspend_state_t state)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* All states need lowlevel support and need to be valid to the lowlevel
|
|
|
|
* implementation, no valid callback implies that none are valid.
|
|
|
|
*/
|
|
|
|
return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* suspend_valid_only_mem - generic memory-only valid callback
|
|
|
|
*
|
|
|
|
* Platform drivers that implement mem suspend only and only need
|
|
|
|
* to check for that in their .valid callback can use this instead
|
|
|
|
* of rolling their own .valid callback.
|
|
|
|
*/
|
|
|
|
int suspend_valid_only_mem(suspend_state_t state)
|
|
|
|
{
|
|
|
|
return state == PM_SUSPEND_MEM;
|
|
|
|
}
|
2011-06-27 06:01:07 +07:00
|
|
|
EXPORT_SYMBOL_GPL(suspend_valid_only_mem);
|
2009-06-10 06:27:12 +07:00
|
|
|
|
|
|
|
static int suspend_test(int level)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_PM_DEBUG
|
|
|
|
if (pm_test_level == level) {
|
|
|
|
printk(KERN_INFO "suspend debug: Waiting for 5 seconds.\n");
|
|
|
|
mdelay(5000);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
#endif /* !CONFIG_PM_DEBUG */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* suspend_prepare - Do prep work before entering low-power state.
|
|
|
|
*
|
|
|
|
* This is common code that is called for each state that we're entering.
|
|
|
|
* Run suspend notifiers, allocate a console and stop all processes.
|
|
|
|
*/
|
|
|
|
static int suspend_prepare(void)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (!suspend_ops || !suspend_ops->enter)
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
pm_prepare_console();
|
|
|
|
|
|
|
|
error = pm_notifier_call_chain(PM_SUSPEND_PREPARE);
|
|
|
|
if (error)
|
|
|
|
goto Finish;
|
|
|
|
|
|
|
|
error = usermodehelper_disable();
|
|
|
|
if (error)
|
|
|
|
goto Finish;
|
|
|
|
|
|
|
|
error = suspend_freeze_processes();
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-11 04:01:26 +07:00
|
|
|
if (error) {
|
|
|
|
suspend_stats.failed_freeze++;
|
|
|
|
dpm_save_failed_step(SUSPEND_FREEZE);
|
|
|
|
} else
|
2009-06-10 06:27:12 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
suspend_thaw_processes();
|
|
|
|
usermodehelper_enable();
|
|
|
|
Finish:
|
|
|
|
pm_notifier_call_chain(PM_POST_SUSPEND);
|
|
|
|
pm_restore_console();
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* default implementation */
|
|
|
|
void __attribute__ ((weak)) arch_suspend_disable_irqs(void)
|
|
|
|
{
|
|
|
|
local_irq_disable();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* default implementation */
|
|
|
|
void __attribute__ ((weak)) arch_suspend_enable_irqs(void)
|
|
|
|
{
|
|
|
|
local_irq_enable();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
PM / Suspend: Add .suspend_again() callback to suspend_ops
A system or a device may need to control suspend/wakeup events. It may
want to wakeup the system after a predefined amount of time or at a
predefined event decided while entering suspend for polling or delayed
work. Then, it may want to enter suspend again if its predefined wakeup
condition is the only wakeup reason and there is no outstanding events;
thus, it does not wakeup the userspace unnecessary or unnecessary
devices and keeps suspended as long as possible (saving the power).
Enabling a system to wakeup after a specified time can be easily
achieved by using RTC. However, to enter suspend again immediately
without invoking userland and unrelated devices, we need additional
features in the suspend framework.
Such need comes from:
1. Monitoring a critical device status without interrupts that can
wakeup the system. (in-suspend polling)
An example is ambient temperature monitoring that needs to shut down
the system or a specific device function if it is too hot or cold. The
temperature of a specific device may be needed to be monitored as well;
e.g., a charger monitors battery temperature in order to stop charging
if overheated.
2. Execute critical "delayed work" at suspend.
A driver or a system/board may have a delayed work (or any similar
things) that it wants to execute at the requested time.
For example, some chargers want to check the battery voltage some
time (e.g., 30 seconds) after the battery is fully charged and the
charger has stopped. Then, the charger restarts charging if the voltage
has dropped more than a threshold, which is smaller than "restart-charger"
voltage, which is a threshold to restart charging regardless of the
time passed.
This patch allows to add "suspend_again" callback at struct
platform_suspend_ops and let the "suspend_again" callback return true if
the system is required to enter suspend again after the current instance
of wakeup. Device-wise suspend_again implemented at dev_pm_ops or
syscore is not done because: a) suspend_again feature is usually under
platform-wise decision and controls the behavior of the whole platform
and b) There are very limited devices related to the usage cases of
suspend_again; chargers and temperature sensors are mentioned so far.
With suspend_again callback registered at struct platform_suspend_ops
suspend_ops in kernel/power/suspend.c with suspend_set_ops by the
platform, the suspend framework tries to enter suspend again by
looping suspend_enter() if suspend_again has returned true and there has
been no errors in the suspending sequence or pending wakeups (by
pm_wakeup_pending).
Tested at Exynos4-NURI.
[rjw: Fixed up kerneldoc comment for suspend_enter().]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-12 20:57:05 +07:00
|
|
|
* suspend_enter - enter the desired system sleep state.
|
|
|
|
* @state: State to enter
|
|
|
|
* @wakeup: Returns information that suspend should not be entered again.
|
2009-06-10 06:27:12 +07:00
|
|
|
*
|
PM / Suspend: Add .suspend_again() callback to suspend_ops
A system or a device may need to control suspend/wakeup events. It may
want to wakeup the system after a predefined amount of time or at a
predefined event decided while entering suspend for polling or delayed
work. Then, it may want to enter suspend again if its predefined wakeup
condition is the only wakeup reason and there is no outstanding events;
thus, it does not wakeup the userspace unnecessary or unnecessary
devices and keeps suspended as long as possible (saving the power).
Enabling a system to wakeup after a specified time can be easily
achieved by using RTC. However, to enter suspend again immediately
without invoking userland and unrelated devices, we need additional
features in the suspend framework.
Such need comes from:
1. Monitoring a critical device status without interrupts that can
wakeup the system. (in-suspend polling)
An example is ambient temperature monitoring that needs to shut down
the system or a specific device function if it is too hot or cold. The
temperature of a specific device may be needed to be monitored as well;
e.g., a charger monitors battery temperature in order to stop charging
if overheated.
2. Execute critical "delayed work" at suspend.
A driver or a system/board may have a delayed work (or any similar
things) that it wants to execute at the requested time.
For example, some chargers want to check the battery voltage some
time (e.g., 30 seconds) after the battery is fully charged and the
charger has stopped. Then, the charger restarts charging if the voltage
has dropped more than a threshold, which is smaller than "restart-charger"
voltage, which is a threshold to restart charging regardless of the
time passed.
This patch allows to add "suspend_again" callback at struct
platform_suspend_ops and let the "suspend_again" callback return true if
the system is required to enter suspend again after the current instance
of wakeup. Device-wise suspend_again implemented at dev_pm_ops or
syscore is not done because: a) suspend_again feature is usually under
platform-wise decision and controls the behavior of the whole platform
and b) There are very limited devices related to the usage cases of
suspend_again; chargers and temperature sensors are mentioned so far.
With suspend_again callback registered at struct platform_suspend_ops
suspend_ops in kernel/power/suspend.c with suspend_set_ops by the
platform, the suspend framework tries to enter suspend again by
looping suspend_enter() if suspend_again has returned true and there has
been no errors in the suspending sequence or pending wakeups (by
pm_wakeup_pending).
Tested at Exynos4-NURI.
[rjw: Fixed up kerneldoc comment for suspend_enter().]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-12 20:57:05 +07:00
|
|
|
* This function should be called after devices have been suspended.
|
2009-06-10 06:27:12 +07:00
|
|
|
*/
|
PM / Suspend: Add .suspend_again() callback to suspend_ops
A system or a device may need to control suspend/wakeup events. It may
want to wakeup the system after a predefined amount of time or at a
predefined event decided while entering suspend for polling or delayed
work. Then, it may want to enter suspend again if its predefined wakeup
condition is the only wakeup reason and there is no outstanding events;
thus, it does not wakeup the userspace unnecessary or unnecessary
devices and keeps suspended as long as possible (saving the power).
Enabling a system to wakeup after a specified time can be easily
achieved by using RTC. However, to enter suspend again immediately
without invoking userland and unrelated devices, we need additional
features in the suspend framework.
Such need comes from:
1. Monitoring a critical device status without interrupts that can
wakeup the system. (in-suspend polling)
An example is ambient temperature monitoring that needs to shut down
the system or a specific device function if it is too hot or cold. The
temperature of a specific device may be needed to be monitored as well;
e.g., a charger monitors battery temperature in order to stop charging
if overheated.
2. Execute critical "delayed work" at suspend.
A driver or a system/board may have a delayed work (or any similar
things) that it wants to execute at the requested time.
For example, some chargers want to check the battery voltage some
time (e.g., 30 seconds) after the battery is fully charged and the
charger has stopped. Then, the charger restarts charging if the voltage
has dropped more than a threshold, which is smaller than "restart-charger"
voltage, which is a threshold to restart charging regardless of the
time passed.
This patch allows to add "suspend_again" callback at struct
platform_suspend_ops and let the "suspend_again" callback return true if
the system is required to enter suspend again after the current instance
of wakeup. Device-wise suspend_again implemented at dev_pm_ops or
syscore is not done because: a) suspend_again feature is usually under
platform-wise decision and controls the behavior of the whole platform
and b) There are very limited devices related to the usage cases of
suspend_again; chargers and temperature sensors are mentioned so far.
With suspend_again callback registered at struct platform_suspend_ops
suspend_ops in kernel/power/suspend.c with suspend_set_ops by the
platform, the suspend framework tries to enter suspend again by
looping suspend_enter() if suspend_again has returned true and there has
been no errors in the suspending sequence or pending wakeups (by
pm_wakeup_pending).
Tested at Exynos4-NURI.
[rjw: Fixed up kerneldoc comment for suspend_enter().]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-12 20:57:05 +07:00
|
|
|
static int suspend_enter(suspend_state_t state, bool *wakeup)
|
2009-06-10 06:27:12 +07:00
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (suspend_ops->prepare) {
|
|
|
|
error = suspend_ops->prepare();
|
|
|
|
if (error)
|
2010-07-08 04:43:45 +07:00
|
|
|
goto Platform_finish;
|
2009-06-10 06:27:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
error = dpm_suspend_noirq(PMSG_SUSPEND);
|
|
|
|
if (error) {
|
|
|
|
printk(KERN_ERR "PM: Some devices failed to power down\n");
|
2010-07-08 04:43:45 +07:00
|
|
|
goto Platform_finish;
|
2009-06-10 06:27:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (suspend_ops->prepare_late) {
|
|
|
|
error = suspend_ops->prepare_late();
|
|
|
|
if (error)
|
2010-07-08 04:43:45 +07:00
|
|
|
goto Platform_wake;
|
2009-06-10 06:27:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (suspend_test(TEST_PLATFORM))
|
|
|
|
goto Platform_wake;
|
|
|
|
|
|
|
|
error = disable_nonboot_cpus();
|
|
|
|
if (error || suspend_test(TEST_CPUS))
|
|
|
|
goto Enable_cpus;
|
|
|
|
|
|
|
|
arch_suspend_disable_irqs();
|
|
|
|
BUG_ON(!irqs_disabled());
|
|
|
|
|
2011-04-27 00:15:07 +07:00
|
|
|
error = syscore_suspend();
|
2009-06-10 06:27:12 +07:00
|
|
|
if (!error) {
|
PM / Suspend: Add .suspend_again() callback to suspend_ops
A system or a device may need to control suspend/wakeup events. It may
want to wakeup the system after a predefined amount of time or at a
predefined event decided while entering suspend for polling or delayed
work. Then, it may want to enter suspend again if its predefined wakeup
condition is the only wakeup reason and there is no outstanding events;
thus, it does not wakeup the userspace unnecessary or unnecessary
devices and keeps suspended as long as possible (saving the power).
Enabling a system to wakeup after a specified time can be easily
achieved by using RTC. However, to enter suspend again immediately
without invoking userland and unrelated devices, we need additional
features in the suspend framework.
Such need comes from:
1. Monitoring a critical device status without interrupts that can
wakeup the system. (in-suspend polling)
An example is ambient temperature monitoring that needs to shut down
the system or a specific device function if it is too hot or cold. The
temperature of a specific device may be needed to be monitored as well;
e.g., a charger monitors battery temperature in order to stop charging
if overheated.
2. Execute critical "delayed work" at suspend.
A driver or a system/board may have a delayed work (or any similar
things) that it wants to execute at the requested time.
For example, some chargers want to check the battery voltage some
time (e.g., 30 seconds) after the battery is fully charged and the
charger has stopped. Then, the charger restarts charging if the voltage
has dropped more than a threshold, which is smaller than "restart-charger"
voltage, which is a threshold to restart charging regardless of the
time passed.
This patch allows to add "suspend_again" callback at struct
platform_suspend_ops and let the "suspend_again" callback return true if
the system is required to enter suspend again after the current instance
of wakeup. Device-wise suspend_again implemented at dev_pm_ops or
syscore is not done because: a) suspend_again feature is usually under
platform-wise decision and controls the behavior of the whole platform
and b) There are very limited devices related to the usage cases of
suspend_again; chargers and temperature sensors are mentioned so far.
With suspend_again callback registered at struct platform_suspend_ops
suspend_ops in kernel/power/suspend.c with suspend_set_ops by the
platform, the suspend framework tries to enter suspend again by
looping suspend_enter() if suspend_again has returned true and there has
been no errors in the suspending sequence or pending wakeups (by
pm_wakeup_pending).
Tested at Exynos4-NURI.
[rjw: Fixed up kerneldoc comment for suspend_enter().]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-12 20:57:05 +07:00
|
|
|
*wakeup = pm_wakeup_pending();
|
|
|
|
if (!(suspend_test(TEST_CORE) || *wakeup)) {
|
2009-06-10 06:27:12 +07:00
|
|
|
error = suspend_ops->enter(state);
|
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>
2010-07-06 03:43:53 +07:00
|
|
|
events_check_enabled = false;
|
|
|
|
}
|
2011-03-15 06:43:46 +07:00
|
|
|
syscore_resume();
|
2009-06-10 06:27:12 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
arch_suspend_enable_irqs();
|
|
|
|
BUG_ON(irqs_disabled());
|
|
|
|
|
|
|
|
Enable_cpus:
|
|
|
|
enable_nonboot_cpus();
|
|
|
|
|
|
|
|
Platform_wake:
|
|
|
|
if (suspend_ops->wake)
|
|
|
|
suspend_ops->wake();
|
|
|
|
|
|
|
|
dpm_resume_noirq(PMSG_RESUME);
|
|
|
|
|
2010-07-08 04:43:45 +07:00
|
|
|
Platform_finish:
|
2009-06-10 06:27:12 +07:00
|
|
|
if (suspend_ops->finish)
|
|
|
|
suspend_ops->finish();
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* suspend_devices_and_enter - suspend devices and enter the desired system
|
|
|
|
* sleep state.
|
|
|
|
* @state: state to enter
|
|
|
|
*/
|
|
|
|
int suspend_devices_and_enter(suspend_state_t state)
|
|
|
|
{
|
|
|
|
int error;
|
PM / Suspend: Add .suspend_again() callback to suspend_ops
A system or a device may need to control suspend/wakeup events. It may
want to wakeup the system after a predefined amount of time or at a
predefined event decided while entering suspend for polling or delayed
work. Then, it may want to enter suspend again if its predefined wakeup
condition is the only wakeup reason and there is no outstanding events;
thus, it does not wakeup the userspace unnecessary or unnecessary
devices and keeps suspended as long as possible (saving the power).
Enabling a system to wakeup after a specified time can be easily
achieved by using RTC. However, to enter suspend again immediately
without invoking userland and unrelated devices, we need additional
features in the suspend framework.
Such need comes from:
1. Monitoring a critical device status without interrupts that can
wakeup the system. (in-suspend polling)
An example is ambient temperature monitoring that needs to shut down
the system or a specific device function if it is too hot or cold. The
temperature of a specific device may be needed to be monitored as well;
e.g., a charger monitors battery temperature in order to stop charging
if overheated.
2. Execute critical "delayed work" at suspend.
A driver or a system/board may have a delayed work (or any similar
things) that it wants to execute at the requested time.
For example, some chargers want to check the battery voltage some
time (e.g., 30 seconds) after the battery is fully charged and the
charger has stopped. Then, the charger restarts charging if the voltage
has dropped more than a threshold, which is smaller than "restart-charger"
voltage, which is a threshold to restart charging regardless of the
time passed.
This patch allows to add "suspend_again" callback at struct
platform_suspend_ops and let the "suspend_again" callback return true if
the system is required to enter suspend again after the current instance
of wakeup. Device-wise suspend_again implemented at dev_pm_ops or
syscore is not done because: a) suspend_again feature is usually under
platform-wise decision and controls the behavior of the whole platform
and b) There are very limited devices related to the usage cases of
suspend_again; chargers and temperature sensors are mentioned so far.
With suspend_again callback registered at struct platform_suspend_ops
suspend_ops in kernel/power/suspend.c with suspend_set_ops by the
platform, the suspend framework tries to enter suspend again by
looping suspend_enter() if suspend_again has returned true and there has
been no errors in the suspending sequence or pending wakeups (by
pm_wakeup_pending).
Tested at Exynos4-NURI.
[rjw: Fixed up kerneldoc comment for suspend_enter().]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-12 20:57:05 +07:00
|
|
|
bool wakeup = false;
|
2009-06-10 06:27:12 +07:00
|
|
|
|
|
|
|
if (!suspend_ops)
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2011-01-06 01:49:01 +07:00
|
|
|
trace_machine_suspend(state);
|
2009-06-10 06:27:12 +07:00
|
|
|
if (suspend_ops->begin) {
|
|
|
|
error = suspend_ops->begin(state);
|
|
|
|
if (error)
|
|
|
|
goto Close;
|
|
|
|
}
|
|
|
|
suspend_console();
|
|
|
|
suspend_test_start();
|
|
|
|
error = dpm_suspend_start(PMSG_SUSPEND);
|
|
|
|
if (error) {
|
|
|
|
printk(KERN_ERR "PM: Some devices failed to suspend\n");
|
|
|
|
goto Recover_platform;
|
|
|
|
}
|
|
|
|
suspend_test_finish("suspend devices");
|
|
|
|
if (suspend_test(TEST_DEVICES))
|
|
|
|
goto Recover_platform;
|
|
|
|
|
PM / Suspend: Add .suspend_again() callback to suspend_ops
A system or a device may need to control suspend/wakeup events. It may
want to wakeup the system after a predefined amount of time or at a
predefined event decided while entering suspend for polling or delayed
work. Then, it may want to enter suspend again if its predefined wakeup
condition is the only wakeup reason and there is no outstanding events;
thus, it does not wakeup the userspace unnecessary or unnecessary
devices and keeps suspended as long as possible (saving the power).
Enabling a system to wakeup after a specified time can be easily
achieved by using RTC. However, to enter suspend again immediately
without invoking userland and unrelated devices, we need additional
features in the suspend framework.
Such need comes from:
1. Monitoring a critical device status without interrupts that can
wakeup the system. (in-suspend polling)
An example is ambient temperature monitoring that needs to shut down
the system or a specific device function if it is too hot or cold. The
temperature of a specific device may be needed to be monitored as well;
e.g., a charger monitors battery temperature in order to stop charging
if overheated.
2. Execute critical "delayed work" at suspend.
A driver or a system/board may have a delayed work (or any similar
things) that it wants to execute at the requested time.
For example, some chargers want to check the battery voltage some
time (e.g., 30 seconds) after the battery is fully charged and the
charger has stopped. Then, the charger restarts charging if the voltage
has dropped more than a threshold, which is smaller than "restart-charger"
voltage, which is a threshold to restart charging regardless of the
time passed.
This patch allows to add "suspend_again" callback at struct
platform_suspend_ops and let the "suspend_again" callback return true if
the system is required to enter suspend again after the current instance
of wakeup. Device-wise suspend_again implemented at dev_pm_ops or
syscore is not done because: a) suspend_again feature is usually under
platform-wise decision and controls the behavior of the whole platform
and b) There are very limited devices related to the usage cases of
suspend_again; chargers and temperature sensors are mentioned so far.
With suspend_again callback registered at struct platform_suspend_ops
suspend_ops in kernel/power/suspend.c with suspend_set_ops by the
platform, the suspend framework tries to enter suspend again by
looping suspend_enter() if suspend_again has returned true and there has
been no errors in the suspending sequence or pending wakeups (by
pm_wakeup_pending).
Tested at Exynos4-NURI.
[rjw: Fixed up kerneldoc comment for suspend_enter().]
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-06-12 20:57:05 +07:00
|
|
|
do {
|
|
|
|
error = suspend_enter(state, &wakeup);
|
|
|
|
} while (!error && !wakeup
|
|
|
|
&& suspend_ops->suspend_again && suspend_ops->suspend_again());
|
2009-06-10 06:27:12 +07:00
|
|
|
|
|
|
|
Resume_devices:
|
|
|
|
suspend_test_start();
|
|
|
|
dpm_resume_end(PMSG_RESUME);
|
|
|
|
suspend_test_finish("resume devices");
|
|
|
|
resume_console();
|
|
|
|
Close:
|
|
|
|
if (suspend_ops->end)
|
|
|
|
suspend_ops->end();
|
2011-01-06 01:49:01 +07:00
|
|
|
trace_machine_suspend(PWR_EVENT_EXIT);
|
2009-06-10 06:27:12 +07:00
|
|
|
return error;
|
|
|
|
|
|
|
|
Recover_platform:
|
|
|
|
if (suspend_ops->recover)
|
|
|
|
suspend_ops->recover();
|
|
|
|
goto Resume_devices;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* suspend_finish - Do final work before exiting suspend sequence.
|
|
|
|
*
|
|
|
|
* Call platform code to clean up, restart processes, and free the
|
|
|
|
* console that we've allocated. This is not called for suspend-to-disk.
|
|
|
|
*/
|
|
|
|
static void suspend_finish(void)
|
|
|
|
{
|
|
|
|
suspend_thaw_processes();
|
|
|
|
usermodehelper_enable();
|
|
|
|
pm_notifier_call_chain(PM_POST_SUSPEND);
|
|
|
|
pm_restore_console();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* enter_state - Do common work of entering low-power state.
|
|
|
|
* @state: pm_state structure for state we're entering.
|
|
|
|
*
|
|
|
|
* Make sure we're the only ones trying to enter a sleep state. Fail
|
|
|
|
* if someone has beat us to it, since we don't want anything weird to
|
|
|
|
* happen when we wake up.
|
|
|
|
* Then, do the setup for suspend, enter the state, and cleaup (after
|
|
|
|
* we've woken up).
|
|
|
|
*/
|
|
|
|
int enter_state(suspend_state_t state)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
|
|
|
if (!valid_state(state))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (!mutex_trylock(&pm_mutex))
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
printk(KERN_INFO "PM: Syncing filesystems ... ");
|
|
|
|
sys_sync();
|
|
|
|
printk("done.\n");
|
|
|
|
|
|
|
|
pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
|
|
|
|
error = suspend_prepare();
|
|
|
|
if (error)
|
|
|
|
goto Unlock;
|
|
|
|
|
|
|
|
if (suspend_test(TEST_FREEZER))
|
|
|
|
goto Finish;
|
|
|
|
|
|
|
|
pr_debug("PM: Entering %s sleep\n", pm_states[state]);
|
2011-05-11 02:09:53 +07:00
|
|
|
pm_restrict_gfp_mask();
|
2009-06-10 06:27:12 +07:00
|
|
|
error = suspend_devices_and_enter(state);
|
2011-05-11 02:09:53 +07:00
|
|
|
pm_restore_gfp_mask();
|
2009-06-10 06:27:12 +07:00
|
|
|
|
|
|
|
Finish:
|
|
|
|
pr_debug("PM: Finishing wakeup.\n");
|
|
|
|
suspend_finish();
|
|
|
|
Unlock:
|
|
|
|
mutex_unlock(&pm_mutex);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_suspend - Externally visible function for suspending system.
|
|
|
|
* @state: Enumerated value of state to enter.
|
|
|
|
*
|
|
|
|
* Determine whether or not value is within range, get state
|
|
|
|
* structure, and enter (above).
|
|
|
|
*/
|
|
|
|
int pm_suspend(suspend_state_t state)
|
|
|
|
{
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-11 04:01:26 +07:00
|
|
|
int ret;
|
2011-09-22 01:55:04 +07:00
|
|
|
if (state > PM_SUSPEND_ON && state < PM_SUSPEND_MAX) {
|
PM / Suspend: Add statistics debugfs file for suspend to RAM
Record S3 failure time about each reason and the latest two failed
devices' names in S3 progress.
We can check it through 'suspend_stats' entry in debugfs.
The motivation of the patch:
We are enabling power features on Medfield. Comparing with PC/notebook,
a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far
more frequently. If it can't enter suspend-2-ram in time, the power
might be used up soon.
We often find sometimes, a device suspend fails. Then, system retries
s3 over and over again. As display is off, testers and developers
don't know what happens.
Some testers and developers complain they don't know if system
tries suspend-2-ram, and what device fails to suspend. They need
such info for a quick check. The patch adds suspend_stats under
debugfs for users to check suspend to RAM statistics quickly.
If not using this patch, we have other methods to get info about
what device fails. One is to turn on CONFIG_PM_DEBUG, but users
would get too much info and testers need recompile the system.
In addition, dynamic debug is another good tool to dump debug info.
But it still doesn't match our utilization scenario closely.
1) user need write a user space parser to process the syslog output;
2) Our testing scenario is we leave the mobile for at least hours.
Then, check its status. No serial console available during the
testing. One is because console would be suspended, and the other
is serial console connecting with spi or HSU devices would consume
power. These devices are powered off at suspend-2-ram.
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-08-11 04:01:26 +07:00
|
|
|
ret = enter_state(state);
|
|
|
|
if (ret) {
|
|
|
|
suspend_stats.fail++;
|
|
|
|
dpm_save_failed_errno(ret);
|
|
|
|
} else
|
|
|
|
suspend_stats.success++;
|
|
|
|
return ret;
|
|
|
|
}
|
2009-06-10 06:27:12 +07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(pm_suspend);
|