2007-10-18 17:04:39 +07:00
|
|
|
#ifndef _LINUX_SUSPEND_H
|
|
|
|
#define _LINUX_SUSPEND_H
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
#include <linux/swap.h>
|
|
|
|
#include <linux/notifier.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/pm.h>
|
2007-05-07 04:50:42 +07:00
|
|
|
#include <linux/mm.h>
|
2011-12-07 05:18:12 +07:00
|
|
|
#include <linux/freezer.h>
|
2007-10-18 17:04:39 +07:00
|
|
|
#include <asm/errno.h>
|
|
|
|
|
2011-09-22 03:47:55 +07:00
|
|
|
#ifdef CONFIG_VT
|
2008-04-28 16:15:03 +07:00
|
|
|
extern void pm_set_vt_switch(int);
|
2007-10-18 17:04:39 +07:00
|
|
|
#else
|
2008-04-28 16:15:03 +07:00
|
|
|
static inline void pm_set_vt_switch(int do_switch)
|
|
|
|
{
|
|
|
|
}
|
2011-09-22 03:47:55 +07:00
|
|
|
#endif
|
2008-04-28 16:15:03 +07:00
|
|
|
|
2011-09-22 03:47:55 +07:00
|
|
|
#ifdef CONFIG_VT_CONSOLE_SLEEP
|
|
|
|
extern int pm_prepare_console(void);
|
|
|
|
extern void pm_restore_console(void);
|
|
|
|
#else
|
2008-04-28 16:15:03 +07:00
|
|
|
static inline int pm_prepare_console(void)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void pm_restore_console(void)
|
|
|
|
{
|
|
|
|
}
|
2007-10-18 17:04:39 +07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
typedef int __bitwise suspend_state_t;
|
|
|
|
|
|
|
|
#define PM_SUSPEND_ON ((__force suspend_state_t) 0)
|
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>
2013-02-06 19:00:36 +07:00
|
|
|
#define PM_SUSPEND_FREEZE ((__force suspend_state_t) 1)
|
|
|
|
#define PM_SUSPEND_STANDBY ((__force suspend_state_t) 2)
|
2007-10-18 17:04:39 +07:00
|
|
|
#define PM_SUSPEND_MEM ((__force suspend_state_t) 3)
|
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>
2013-02-06 19:00:36 +07:00
|
|
|
#define PM_SUSPEND_MIN PM_SUSPEND_FREEZE
|
2007-10-18 17:04:39 +07:00
|
|
|
#define PM_SUSPEND_MAX ((__force suspend_state_t) 4)
|
|
|
|
|
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
|
|
|
enum suspend_stat_step {
|
|
|
|
SUSPEND_FREEZE = 1,
|
|
|
|
SUSPEND_PREPARE,
|
|
|
|
SUSPEND_SUSPEND,
|
2012-01-30 02:38:29 +07:00
|
|
|
SUSPEND_SUSPEND_LATE,
|
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
|
|
|
SUSPEND_SUSPEND_NOIRQ,
|
|
|
|
SUSPEND_RESUME_NOIRQ,
|
2012-01-30 02:38:29 +07:00
|
|
|
SUSPEND_RESUME_EARLY,
|
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
|
|
|
SUSPEND_RESUME
|
|
|
|
};
|
|
|
|
|
|
|
|
struct suspend_stats {
|
|
|
|
int success;
|
|
|
|
int fail;
|
|
|
|
int failed_freeze;
|
|
|
|
int failed_prepare;
|
|
|
|
int failed_suspend;
|
2012-01-30 02:38:29 +07:00
|
|
|
int failed_suspend_late;
|
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 failed_suspend_noirq;
|
|
|
|
int failed_resume;
|
2012-01-30 02:38:29 +07:00
|
|
|
int failed_resume_early;
|
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 failed_resume_noirq;
|
|
|
|
#define REC_FAILED_NUM 2
|
|
|
|
int last_failed_dev;
|
|
|
|
char failed_devs[REC_FAILED_NUM][40];
|
|
|
|
int last_failed_errno;
|
|
|
|
int errno[REC_FAILED_NUM];
|
|
|
|
int last_failed_step;
|
|
|
|
enum suspend_stat_step failed_steps[REC_FAILED_NUM];
|
|
|
|
};
|
|
|
|
|
|
|
|
extern struct suspend_stats suspend_stats;
|
|
|
|
|
|
|
|
static inline void dpm_save_failed_dev(const char *name)
|
|
|
|
{
|
|
|
|
strlcpy(suspend_stats.failed_devs[suspend_stats.last_failed_dev],
|
|
|
|
name,
|
|
|
|
sizeof(suspend_stats.failed_devs[0]));
|
|
|
|
suspend_stats.last_failed_dev++;
|
|
|
|
suspend_stats.last_failed_dev %= REC_FAILED_NUM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void dpm_save_failed_errno(int err)
|
|
|
|
{
|
|
|
|
suspend_stats.errno[suspend_stats.last_failed_errno] = err;
|
|
|
|
suspend_stats.last_failed_errno++;
|
|
|
|
suspend_stats.last_failed_errno %= REC_FAILED_NUM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void dpm_save_failed_step(enum suspend_stat_step step)
|
|
|
|
{
|
|
|
|
suspend_stats.failed_steps[suspend_stats.last_failed_step] = step;
|
|
|
|
suspend_stats.last_failed_step++;
|
|
|
|
suspend_stats.last_failed_step %= REC_FAILED_NUM;
|
|
|
|
}
|
|
|
|
|
2007-10-18 17:04:39 +07:00
|
|
|
/**
|
2007-10-18 17:04:40 +07:00
|
|
|
* struct platform_suspend_ops - Callbacks for managing platform dependent
|
|
|
|
* system sleep states.
|
2007-10-18 17:04:39 +07:00
|
|
|
*
|
|
|
|
* @valid: Callback to determine if given system sleep state is supported by
|
|
|
|
* the platform.
|
|
|
|
* Valid (ie. supported) states are advertised in /sys/power/state. Note
|
|
|
|
* that it still may be impossible to enter given system sleep state if the
|
|
|
|
* conditions aren't right.
|
2007-10-18 17:04:40 +07:00
|
|
|
* There is the %suspend_valid_only_mem function available that can be
|
|
|
|
* assigned to this if the platform only supports mem sleep.
|
2007-10-18 17:04:39 +07:00
|
|
|
*
|
2008-01-08 06:04:17 +07:00
|
|
|
* @begin: Initialise a transition to given system sleep state.
|
|
|
|
* @begin() is executed right prior to suspending devices. The information
|
|
|
|
* conveyed to the platform code by @begin() should be disregarded by it as
|
|
|
|
* soon as @end() is executed. If @begin() fails (ie. returns nonzero),
|
2007-10-18 17:04:39 +07:00
|
|
|
* @prepare(), @enter() and @finish() will not be called by the PM core.
|
|
|
|
* This callback is optional. However, if it is implemented, the argument
|
2008-01-08 06:04:17 +07:00
|
|
|
* passed to @enter() is redundant and should be ignored.
|
2007-10-18 17:04:39 +07:00
|
|
|
*
|
|
|
|
* @prepare: Prepare the platform for entering the system sleep state indicated
|
2008-01-08 06:04:17 +07:00
|
|
|
* by @begin().
|
2007-10-18 17:04:39 +07:00
|
|
|
* @prepare() is called right after devices have been suspended (ie. the
|
|
|
|
* appropriate .suspend() method has been executed for each device) and
|
2009-04-20 01:08:42 +07:00
|
|
|
* before device drivers' late suspend callbacks are executed. It returns
|
|
|
|
* 0 on success or a negative error code otherwise, in which case the
|
|
|
|
* system cannot enter the desired sleep state (@prepare_late(), @enter(),
|
2010-07-08 04:43:45 +07:00
|
|
|
* and @wake() will not be called in that case).
|
2009-04-20 01:08:42 +07:00
|
|
|
*
|
|
|
|
* @prepare_late: Finish preparing the platform for entering the system sleep
|
|
|
|
* state indicated by @begin().
|
|
|
|
* @prepare_late is called before disabling nonboot CPUs and after
|
|
|
|
* device drivers' late suspend callbacks have been executed. It returns
|
|
|
|
* 0 on success or a negative error code otherwise, in which case the
|
2010-07-08 04:43:45 +07:00
|
|
|
* system cannot enter the desired sleep state (@enter() will not be
|
|
|
|
* executed).
|
2007-10-18 17:04:39 +07:00
|
|
|
*
|
2008-01-08 06:04:17 +07:00
|
|
|
* @enter: Enter the system sleep state indicated by @begin() or represented by
|
|
|
|
* the argument if @begin() is not implemented.
|
2007-10-18 17:04:39 +07:00
|
|
|
* This callback is mandatory. It returns 0 on success or a negative
|
|
|
|
* error code otherwise, in which case the system cannot enter the desired
|
|
|
|
* sleep state.
|
|
|
|
*
|
2009-04-20 01:08:42 +07:00
|
|
|
* @wake: Called when the system has just left a sleep state, right after
|
|
|
|
* the nonboot CPUs have been enabled and before device drivers' early
|
|
|
|
* resume callbacks are executed.
|
|
|
|
* This callback is optional, but should be implemented by the platforms
|
|
|
|
* that implement @prepare_late(). If implemented, it is always called
|
2010-07-08 04:43:45 +07:00
|
|
|
* after @prepare_late and @enter(), even if one of them fails.
|
2009-04-20 01:08:42 +07:00
|
|
|
*
|
|
|
|
* @finish: Finish wake-up of the platform.
|
|
|
|
* @finish is called right prior to calling device drivers' regular suspend
|
|
|
|
* callbacks.
|
2007-10-18 17:04:39 +07:00
|
|
|
* This callback is optional, but should be implemented by the platforms
|
|
|
|
* that implement @prepare(). If implemented, it is always called after
|
2010-07-08 04:43:45 +07:00
|
|
|
* @enter() and @wake(), even if any of them fails. It is executed after
|
|
|
|
* a failing @prepare.
|
2008-01-08 06:04:17 +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
|
|
|
* @suspend_again: Returns whether the system should suspend again (true) or
|
|
|
|
* not (false). If the platform wants to poll sensors or execute some
|
|
|
|
* code during suspended without invoking userspace and most of devices,
|
|
|
|
* suspend_again callback is the place assuming that periodic-wakeup or
|
|
|
|
* alarm-wakeup is already setup. This allows to execute some codes while
|
|
|
|
* being kept suspended in the view of userland and devices.
|
|
|
|
*
|
2008-01-08 06:04:17 +07:00
|
|
|
* @end: Called by the PM core right after resuming devices, to indicate to
|
|
|
|
* the platform that the system has returned to the working state or
|
|
|
|
* the transition to the sleep state has been aborted.
|
|
|
|
* This callback is optional, but should be implemented by the platforms
|
2009-04-20 01:08:42 +07:00
|
|
|
* that implement @begin(). Accordingly, platforms implementing @begin()
|
|
|
|
* should also provide a @end() which cleans up transitions aborted before
|
2008-01-08 06:04:17 +07:00
|
|
|
* @enter().
|
2008-06-13 04:24:06 +07:00
|
|
|
*
|
|
|
|
* @recover: Recover the platform from a suspend failure.
|
|
|
|
* Called by the PM core if the suspending of devices fails.
|
|
|
|
* This callback is optional and should only be implemented by platforms
|
|
|
|
* which require special recovery actions in that situation.
|
2007-10-18 17:04:39 +07:00
|
|
|
*/
|
2007-10-18 17:04:40 +07:00
|
|
|
struct platform_suspend_ops {
|
2007-10-18 17:04:39 +07:00
|
|
|
int (*valid)(suspend_state_t state);
|
2008-01-08 06:04:17 +07:00
|
|
|
int (*begin)(suspend_state_t state);
|
2007-10-18 17:04:41 +07:00
|
|
|
int (*prepare)(void);
|
2009-04-20 01:08:42 +07:00
|
|
|
int (*prepare_late)(void);
|
2007-10-18 17:04:39 +07:00
|
|
|
int (*enter)(suspend_state_t state);
|
2009-04-20 01:08:42 +07:00
|
|
|
void (*wake)(void);
|
2007-10-18 17:04:41 +07:00
|
|
|
void (*finish)(void);
|
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 (*suspend_again)(void);
|
2008-01-08 06:04:17 +07:00
|
|
|
void (*end)(void);
|
2008-06-13 04:24:06 +07:00
|
|
|
void (*recover)(void);
|
2007-10-18 17:04:39 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
#ifdef CONFIG_SUSPEND
|
|
|
|
/**
|
2007-10-18 17:04:40 +07:00
|
|
|
* suspend_set_ops - set platform dependent suspend operations
|
|
|
|
* @ops: The new suspend operations to set.
|
2007-10-18 17:04:39 +07:00
|
|
|
*/
|
2010-11-16 20:14:02 +07:00
|
|
|
extern void suspend_set_ops(const struct platform_suspend_ops *ops);
|
2007-10-18 17:04:40 +07:00
|
|
|
extern int suspend_valid_only_mem(suspend_state_t state);
|
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>
2013-02-06 19:00:36 +07:00
|
|
|
extern void freeze_wake(void);
|
2007-10-18 17:04:39 +07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* arch_suspend_disable_irqs - disable IRQs for suspend
|
|
|
|
*
|
|
|
|
* Disables IRQs (in the default case). This is a weak symbol in the common
|
|
|
|
* code and thus allows architectures to override it if more needs to be
|
|
|
|
* done. Not called for suspend to disk.
|
|
|
|
*/
|
|
|
|
extern void arch_suspend_disable_irqs(void);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* arch_suspend_enable_irqs - enable IRQs after suspend
|
|
|
|
*
|
|
|
|
* Enables IRQs (in the default case). This is a weak symbol in the common
|
|
|
|
* code and thus allows architectures to override it if more needs to be
|
|
|
|
* done. Not called for suspend to disk.
|
|
|
|
*/
|
|
|
|
extern void arch_suspend_enable_irqs(void);
|
|
|
|
|
|
|
|
extern int pm_suspend(suspend_state_t state);
|
|
|
|
#else /* !CONFIG_SUSPEND */
|
|
|
|
#define suspend_valid_only_mem NULL
|
|
|
|
|
2010-11-16 20:14:02 +07:00
|
|
|
static inline void suspend_set_ops(const struct platform_suspend_ops *ops) {}
|
2007-10-18 17:04:39 +07:00
|
|
|
static inline int pm_suspend(suspend_state_t state) { return -ENOSYS; }
|
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>
2013-02-06 19:00:36 +07:00
|
|
|
static inline void freeze_wake(void) {}
|
2007-10-18 17:04:39 +07:00
|
|
|
#endif /* !CONFIG_SUSPEND */
|
2005-04-17 05:20:36 +07:00
|
|
|
|
[PATCH] swsusp: Improve handling of highmem
Currently swsusp saves the contents of highmem pages by copying them to the
normal zone which is quite inefficient (eg. it requires two normal pages
to be used for saving one highmem page). This may be improved by using
highmem for saving the contents of saveable highmem pages.
Namely, during the suspend phase of the suspend-resume cycle we try to
allocate as many free highmem pages as there are saveable highmem pages.
If there are not enough highmem image pages to store the contents of all of
the saveable highmem pages, some of them will be stored in the "normal"
memory. Next, we allocate as many free "normal" pages as needed to store
the (remaining) image data. We use a memory bitmap to mark the allocated
free pages (ie. highmem as well as "normal" image pages).
Now, we use another memory bitmap to mark all of the saveable pages
(highmem as well as "normal") and the contents of the saveable pages are
copied into the image pages. Then, the second bitmap is used to save the
pfns corresponding to the saveable pages and the first one is used to save
their data.
During the resume phase the pfns of the pages that were saveable during the
suspend are loaded from the image and used to mark the "unsafe" page
frames. Next, we try to allocate as many free highmem page frames as to
load all of the image data that had been in the highmem before the suspend
and we allocate so many free "normal" page frames that the total number of
allocated free pages (highmem and "normal") is equal to the size of the
image. While doing this we have to make sure that there will be some extra
free "normal" and "safe" page frames for two lists of PBEs constructed
later.
Now, the image data are loaded, if possible, into their "original" page
frames. The image data that cannot be written into their "original" page
frames are loaded into "safe" page frames and their "original" kernel
virtual addresses, as well as the addresses of the "safe" pages containing
their copies, are stored in one of two lists of PBEs.
One list of PBEs is for the copies of "normal" suspend pages (ie. "normal"
pages that were saveable during the suspend) and it is used in the same way
as previously (ie. by the architecture-dependent parts of swsusp). The
other list of PBEs is for the copies of highmem suspend pages. The pages
in this list are restored (in a reversible way) right before the
arch-dependent code is called.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-07 11:34:18 +07:00
|
|
|
/* struct pbe is used for creating lists of pages that should be restored
|
|
|
|
* atomically during the resume from disk, because the page frames they have
|
|
|
|
* occupied before the suspend are in use.
|
|
|
|
*/
|
2006-09-26 13:32:51 +07:00
|
|
|
struct pbe {
|
[PATCH] swsusp: Improve handling of highmem
Currently swsusp saves the contents of highmem pages by copying them to the
normal zone which is quite inefficient (eg. it requires two normal pages
to be used for saving one highmem page). This may be improved by using
highmem for saving the contents of saveable highmem pages.
Namely, during the suspend phase of the suspend-resume cycle we try to
allocate as many free highmem pages as there are saveable highmem pages.
If there are not enough highmem image pages to store the contents of all of
the saveable highmem pages, some of them will be stored in the "normal"
memory. Next, we allocate as many free "normal" pages as needed to store
the (remaining) image data. We use a memory bitmap to mark the allocated
free pages (ie. highmem as well as "normal" image pages).
Now, we use another memory bitmap to mark all of the saveable pages
(highmem as well as "normal") and the contents of the saveable pages are
copied into the image pages. Then, the second bitmap is used to save the
pfns corresponding to the saveable pages and the first one is used to save
their data.
During the resume phase the pfns of the pages that were saveable during the
suspend are loaded from the image and used to mark the "unsafe" page
frames. Next, we try to allocate as many free highmem page frames as to
load all of the image data that had been in the highmem before the suspend
and we allocate so many free "normal" page frames that the total number of
allocated free pages (highmem and "normal") is equal to the size of the
image. While doing this we have to make sure that there will be some extra
free "normal" and "safe" page frames for two lists of PBEs constructed
later.
Now, the image data are loaded, if possible, into their "original" page
frames. The image data that cannot be written into their "original" page
frames are loaded into "safe" page frames and their "original" kernel
virtual addresses, as well as the addresses of the "safe" pages containing
their copies, are stored in one of two lists of PBEs.
One list of PBEs is for the copies of "normal" suspend pages (ie. "normal"
pages that were saveable during the suspend) and it is used in the same way
as previously (ie. by the architecture-dependent parts of swsusp). The
other list of PBEs is for the copies of highmem suspend pages. The pages
in this list are restored (in a reversible way) right before the
arch-dependent code is called.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-07 11:34:18 +07:00
|
|
|
void *address; /* address of the copy */
|
|
|
|
void *orig_address; /* original address of a page */
|
2006-01-06 15:13:05 +07:00
|
|
|
struct pbe *next;
|
2006-09-26 13:32:51 +07:00
|
|
|
};
|
2005-04-17 05:20:36 +07:00
|
|
|
|
|
|
|
/* mm/page_alloc.c */
|
|
|
|
extern void mark_free_pages(struct zone *zone);
|
|
|
|
|
2007-05-09 16:33:18 +07:00
|
|
|
/**
|
2007-10-18 17:04:43 +07:00
|
|
|
* struct platform_hibernation_ops - hibernation platform support
|
2007-05-09 16:33:18 +07:00
|
|
|
*
|
2008-01-08 06:08:44 +07:00
|
|
|
* The methods in this structure allow a platform to carry out special
|
|
|
|
* operations required by it during a hibernation transition.
|
2007-05-09 16:33:18 +07:00
|
|
|
*
|
2008-06-13 04:24:06 +07:00
|
|
|
* All the methods below, except for @recover(), must be implemented.
|
2007-05-09 16:33:18 +07:00
|
|
|
*
|
2008-01-08 06:08:44 +07:00
|
|
|
* @begin: Tell the platform driver that we're starting hibernation.
|
2007-10-18 17:04:42 +07:00
|
|
|
* Called right after shrinking memory and before freezing devices.
|
|
|
|
*
|
2008-01-08 06:08:44 +07:00
|
|
|
* @end: Called by the PM core right after resuming devices, to indicate to
|
|
|
|
* the platform that the system has returned to the working state.
|
|
|
|
*
|
2007-10-18 17:04:42 +07:00
|
|
|
* @pre_snapshot: Prepare the platform for creating the hibernation image.
|
|
|
|
* Called right after devices have been frozen and before the nonboot
|
|
|
|
* CPUs are disabled (runs with IRQs on).
|
|
|
|
*
|
|
|
|
* @finish: Restore the previous state of the platform after the hibernation
|
|
|
|
* image has been created *or* put the platform into the normal operation
|
|
|
|
* mode after the hibernation (the same method is executed in both cases).
|
|
|
|
* Called right after the nonboot CPUs have been enabled and before
|
|
|
|
* thawing devices (runs with IRQs on).
|
|
|
|
*
|
|
|
|
* @prepare: Prepare the platform for entering the low power state.
|
|
|
|
* Called right after the hibernation image has been saved and before
|
|
|
|
* devices are prepared for entering the low power state.
|
|
|
|
*
|
|
|
|
* @enter: Put the system into the low power state after the hibernation image
|
|
|
|
* has been saved to disk.
|
|
|
|
* Called after the nonboot CPUs have been disabled and all of the low
|
|
|
|
* level devices have been shut down (runs with IRQs off).
|
|
|
|
*
|
2007-10-18 17:04:55 +07:00
|
|
|
* @leave: Perform the first stage of the cleanup after the system sleep state
|
|
|
|
* indicated by @set_target() has been left.
|
|
|
|
* Called right after the control has been passed from the boot kernel to
|
|
|
|
* the image kernel, before the nonboot CPUs are enabled and before devices
|
|
|
|
* are resumed. Executed with interrupts disabled.
|
|
|
|
*
|
2007-10-18 17:04:42 +07:00
|
|
|
* @pre_restore: Prepare system for the restoration from a hibernation image.
|
|
|
|
* Called right after devices have been frozen and before the nonboot
|
|
|
|
* CPUs are disabled (runs with IRQs on).
|
|
|
|
*
|
|
|
|
* @restore_cleanup: Clean up after a failing image restoration.
|
|
|
|
* Called right after the nonboot CPUs have been enabled and before
|
|
|
|
* thawing devices (runs with IRQs on).
|
2008-06-13 04:24:06 +07:00
|
|
|
*
|
|
|
|
* @recover: Recover the platform from a failure to suspend devices.
|
|
|
|
* Called by the PM core if the suspending of devices during hibernation
|
|
|
|
* fails. This callback is optional and should only be implemented by
|
|
|
|
* platforms which require special recovery actions in that situation.
|
2007-05-09 16:33:18 +07:00
|
|
|
*/
|
2007-10-18 17:04:43 +07:00
|
|
|
struct platform_hibernation_ops {
|
2008-01-08 06:08:44 +07:00
|
|
|
int (*begin)(void);
|
|
|
|
void (*end)(void);
|
2007-10-18 17:04:42 +07:00
|
|
|
int (*pre_snapshot)(void);
|
|
|
|
void (*finish)(void);
|
2007-05-09 16:33:18 +07:00
|
|
|
int (*prepare)(void);
|
|
|
|
int (*enter)(void);
|
2007-10-18 17:04:55 +07:00
|
|
|
void (*leave)(void);
|
swsusp: introduce restore platform operations
At least on some machines it is necessary to prepare the ACPI firmware for the
restoration of the system memory state from the hibernation image if the
"platform" mode of hibernation has been used. Namely, in that cases we need
to disable the GPEs before replacing the "boot" kernel with the "frozen"
kernel (cf. http://bugzilla.kernel.org/show_bug.cgi?id=7887). After the
restore they will be re-enabled by hibernation_ops->finish(), but if the
restore fails, they have to be re-enabled by the restore code explicitly.
For this purpose we can introduce two additional hibernation operations,
called pre_restore() and restore_cleanup() and call them from the restore code
path. Still, they should be called if the "platform" mode of hibernation has
been used, so we need to pass the information about the hibernation mode from
the "frozen" kernel to the "boot" kernel in the image header.
Apparently, we can't drop the disabling of GPEs before the restore because of
Bug #7887 . We also can't do it unconditionally, because the GPEs wouldn't
have been enabled after a successful restore if the suspend had been done in
the 'shutdown' or 'reboot' mode.
In principle we could (and probably should) unconditionally disable the GPEs
before each snapshot creation *and* before the restore, but then we'd have to
unconditionally enable them after the snapshot creation as well as after the
restore (or restore failure) Still, for this purpose we'd need to modify
acpi_enter_sleep_state_prep() and acpi_leave_sleep_state() and we'd have to
introduce some mechanism synchronizing the disablind/enabling of the GPEs with
the device drivers' .suspend()/.resume() routines and with
disable_/enable_nonboot_cpus(). However, this would have affected the
suspend (ie. s2ram) code as well as the hibernation, which I'd like to avoid
in this patch series.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-19 15:47:30 +07:00
|
|
|
int (*pre_restore)(void);
|
|
|
|
void (*restore_cleanup)(void);
|
2008-06-13 04:24:06 +07:00
|
|
|
void (*recover)(void);
|
2007-05-09 16:33:18 +07:00
|
|
|
};
|
|
|
|
|
2007-07-30 04:24:36 +07:00
|
|
|
#ifdef CONFIG_HIBERNATION
|
2007-05-07 04:50:43 +07:00
|
|
|
/* kernel/power/snapshot.c */
|
2007-05-08 16:23:49 +07:00
|
|
|
extern void __register_nosave_region(unsigned long b, unsigned long e, int km);
|
2008-08-15 14:40:19 +07:00
|
|
|
static inline void __init register_nosave_region(unsigned long b, unsigned long e)
|
2007-05-08 16:23:49 +07:00
|
|
|
{
|
|
|
|
__register_nosave_region(b, e, 0);
|
|
|
|
}
|
2008-08-15 14:40:19 +07:00
|
|
|
static inline void __init register_nosave_region_late(unsigned long b, unsigned long e)
|
2007-05-08 16:23:49 +07:00
|
|
|
{
|
|
|
|
__register_nosave_region(b, e, 1);
|
|
|
|
}
|
2007-05-07 04:50:43 +07:00
|
|
|
extern int swsusp_page_is_forbidden(struct page *);
|
|
|
|
extern void swsusp_set_page_free(struct page *);
|
|
|
|
extern void swsusp_unset_page_free(struct page *);
|
|
|
|
extern unsigned long get_safe_page(gfp_t gfp_mask);
|
2007-05-09 16:33:18 +07:00
|
|
|
|
2010-11-10 03:48:49 +07:00
|
|
|
extern void hibernation_set_ops(const struct platform_hibernation_ops *ops);
|
2007-05-09 16:33:18 +07:00
|
|
|
extern int hibernate(void);
|
2009-01-20 02:54:54 +07:00
|
|
|
extern bool system_entering_hibernation(void);
|
2007-07-30 04:24:36 +07:00
|
|
|
#else /* CONFIG_HIBERNATION */
|
2011-04-12 03:54:42 +07:00
|
|
|
static inline void register_nosave_region(unsigned long b, unsigned long e) {}
|
|
|
|
static inline void register_nosave_region_late(unsigned long b, unsigned long e) {}
|
2007-05-07 04:50:43 +07:00
|
|
|
static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
|
|
|
|
static inline void swsusp_set_page_free(struct page *p) {}
|
|
|
|
static inline void swsusp_unset_page_free(struct page *p) {}
|
2007-05-09 16:33:18 +07:00
|
|
|
|
2010-11-10 03:48:49 +07:00
|
|
|
static inline void hibernation_set_ops(const struct platform_hibernation_ops *ops) {}
|
2007-05-09 16:33:18 +07:00
|
|
|
static inline int hibernate(void) { return -ENOSYS; }
|
2009-06-10 06:28:19 +07:00
|
|
|
static inline bool system_entering_hibernation(void) { return false; }
|
|
|
|
#endif /* CONFIG_HIBERNATION */
|
|
|
|
|
2011-07-26 07:13:11 +07:00
|
|
|
/* Hibernation and suspend events */
|
|
|
|
#define PM_HIBERNATION_PREPARE 0x0001 /* Going to hibernate */
|
|
|
|
#define PM_POST_HIBERNATION 0x0002 /* Hibernation finished */
|
|
|
|
#define PM_SUSPEND_PREPARE 0x0003 /* Going to suspend the system */
|
|
|
|
#define PM_POST_SUSPEND 0x0004 /* Suspend finished */
|
|
|
|
#define PM_RESTORE_PREPARE 0x0005 /* Going to restore a saved image */
|
|
|
|
#define PM_POST_RESTORE 0x0006 /* Restore failed */
|
|
|
|
|
2011-12-07 05:24:38 +07:00
|
|
|
extern struct mutex pm_mutex;
|
|
|
|
|
2007-07-30 04:27:18 +07:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
2005-04-17 05:20:36 +07:00
|
|
|
void save_processor_state(void);
|
|
|
|
void restore_processor_state(void);
|
2005-10-31 05:59:56 +07:00
|
|
|
|
2007-07-19 15:47:36 +07:00
|
|
|
/* kernel/power/main.c */
|
2007-11-20 05:49:18 +07:00
|
|
|
extern int register_pm_notifier(struct notifier_block *nb);
|
|
|
|
extern int unregister_pm_notifier(struct notifier_block *nb);
|
2007-07-19 15:47:36 +07:00
|
|
|
|
|
|
|
#define pm_notifier(fn, pri) { \
|
|
|
|
static struct notifier_block fn##_nb = \
|
|
|
|
{ .notifier_call = fn, .priority = pri }; \
|
|
|
|
register_pm_notifier(&fn##_nb); \
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/* drivers/base/power/wakeup.c */
|
|
|
|
extern bool events_check_enabled;
|
|
|
|
|
2010-12-04 04:58:31 +07:00
|
|
|
extern bool pm_wakeup_pending(void);
|
2012-04-30 03:53:22 +07:00
|
|
|
extern bool pm_get_wakeup_count(unsigned int *count, bool block);
|
2010-09-23 03:09:10 +07:00
|
|
|
extern bool pm_save_wakeup_count(unsigned int count);
|
2012-04-30 03:53:32 +07:00
|
|
|
extern void pm_wakep_autosleep_enabled(bool set);
|
2013-06-13 02:55:22 +07:00
|
|
|
extern void pm_print_active_wakeup_sources(void);
|
2011-12-07 05:24:38 +07:00
|
|
|
|
|
|
|
static inline void lock_system_sleep(void)
|
|
|
|
{
|
PM / Hibernate: Rewrite unlock_system_sleep() to fix s2disk regression
Commit 33e638b, "PM / Sleep: Use the freezer_count() functions in
[un]lock_system_sleep() APIs" introduced an undesirable change in the
behaviour of unlock_system_sleep() since freezer_count() internally calls
try_to_freeze() - which we don't need in unlock_system_sleep().
And commit bcda53f, "PM / Sleep: Replace mutex_[un]lock(&pm_mutex) with
[un]lock_system_sleep()" made these APIs wide-spread. This caused a
regression in suspend-to-disk where snapshot_read() and snapshot_write()
were getting frozen due to the try_to_freeze embedded in
unlock_system_sleep(), since these functions were invoked when the freezing
condition was still in effect.
Fix this by rewriting unlock_system_sleep() by open-coding freezer_count()
and dropping the try_to_freeze() part. Not only will this fix the
regression but this will also ensure that the API only does what it is
intended to do, and nothing more, under the hood.
While at it, make the code more correct and robust by ensuring that the
PF_FREEZER_SKIP flag gets cleared with pm_mutex held, to avoid a race with
the freezer.
Also, to be on the safer side, open-code freezer_do_not_count() as well
(inside lock_system_sleep()), to ensure that any unrelated modification to
freezer[_do_not]_count() does not break things again!
Reported-and-tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-01-20 05:25:33 +07:00
|
|
|
current->flags |= PF_FREEZER_SKIP;
|
2011-12-07 05:24:38 +07:00
|
|
|
mutex_lock(&pm_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void unlock_system_sleep(void)
|
|
|
|
{
|
PM / Hibernate: Rewrite unlock_system_sleep() to fix s2disk regression
Commit 33e638b, "PM / Sleep: Use the freezer_count() functions in
[un]lock_system_sleep() APIs" introduced an undesirable change in the
behaviour of unlock_system_sleep() since freezer_count() internally calls
try_to_freeze() - which we don't need in unlock_system_sleep().
And commit bcda53f, "PM / Sleep: Replace mutex_[un]lock(&pm_mutex) with
[un]lock_system_sleep()" made these APIs wide-spread. This caused a
regression in suspend-to-disk where snapshot_read() and snapshot_write()
were getting frozen due to the try_to_freeze embedded in
unlock_system_sleep(), since these functions were invoked when the freezing
condition was still in effect.
Fix this by rewriting unlock_system_sleep() by open-coding freezer_count()
and dropping the try_to_freeze() part. Not only will this fix the
regression but this will also ensure that the API only does what it is
intended to do, and nothing more, under the hood.
While at it, make the code more correct and robust by ensuring that the
PF_FREEZER_SKIP flag gets cleared with pm_mutex held, to avoid a race with
the freezer.
Also, to be on the safer side, open-code freezer_do_not_count() as well
(inside lock_system_sleep()), to ensure that any unrelated modification to
freezer[_do_not]_count() does not break things again!
Reported-and-tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-01-20 05:25:33 +07:00
|
|
|
/*
|
|
|
|
* Don't use freezer_count() because we don't want the call to
|
|
|
|
* try_to_freeze() here.
|
|
|
|
*
|
|
|
|
* Reason:
|
|
|
|
* Fundamentally, we just don't need it, because freezing condition
|
|
|
|
* doesn't come into effect until we release the pm_mutex lock,
|
|
|
|
* since the freezer always works with pm_mutex held.
|
|
|
|
*
|
|
|
|
* More importantly, in the case of hibernation,
|
|
|
|
* unlock_system_sleep() gets called in snapshot_read() and
|
|
|
|
* snapshot_write() when the freezing condition is still in effect.
|
|
|
|
* Which means, if we use try_to_freeze() here, it would make them
|
|
|
|
* enter the refrigerator, thus causing hibernation to lockup.
|
|
|
|
*/
|
|
|
|
current->flags &= ~PF_FREEZER_SKIP;
|
2011-12-07 05:24:38 +07:00
|
|
|
mutex_unlock(&pm_mutex);
|
|
|
|
}
|
|
|
|
|
2007-07-30 04:27:18 +07:00
|
|
|
#else /* !CONFIG_PM_SLEEP */
|
2007-07-19 15:47:36 +07:00
|
|
|
|
|
|
|
static inline int register_pm_notifier(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int unregister_pm_notifier(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define pm_notifier(fn, pri) do { (void)(fn); } while (0)
|
2010-10-05 03:07:32 +07:00
|
|
|
|
2010-12-04 04:58:31 +07:00
|
|
|
static inline bool pm_wakeup_pending(void) { return false; }
|
2009-11-18 05:06:22 +07:00
|
|
|
|
|
|
|
static inline void lock_system_sleep(void) {}
|
|
|
|
static inline void unlock_system_sleep(void) {}
|
|
|
|
|
2011-12-07 05:24:38 +07:00
|
|
|
#endif /* !CONFIG_PM_SLEEP */
|
kexec jump: save/restore device state
This patch implements devices state save/restore before after kexec.
This patch together with features in kexec_jump patch can be used for
following:
- A simple hibernation implementation without ACPI support. You can kexec a
hibernating kernel, save the memory image of original system and shutdown
the system. When resuming, you restore the memory image of original system
via ordinary kexec load then jump back.
- Kernel/system debug through making system snapshot. You can make system
snapshot, jump back, do some thing and make another system snapshot.
- Cooperative multi-kernel/system. With kexec jump, you can switch between
several kernels/systems quickly without boot process except the first time.
This appears like swap a whole kernel/system out/in.
- A general method to call program in physical mode (paging turning
off). This can be used to invoke BIOS code under Linux.
The following user-space tools can be used with kexec jump:
- kexec-tools needs to be patched to support kexec jump. The patches
and the precompiled kexec can be download from the following URL:
source: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-src_git_kh10.tar.bz2
patches: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec-tools-patches_git_kh10.tar.bz2
binary: http://khibernation.sourceforge.net/download/release_v10/kexec-tools/kexec_git_kh10
- makedumpfile with patches are used as memory image saving tool, it
can exclude free pages from original kernel memory image file. The
patches and the precompiled makedumpfile can be download from the
following URL:
source: http://khibernation.sourceforge.net/download/release_v10/makedumpfile/makedumpfile-src_cvs_kh10.tar.bz2
patches: http://khibernation.sourceforge.net/download/release_v10/makedumpfile/makedumpfile-patches_cvs_kh10.tar.bz2
binary: http://khibernation.sourceforge.net/download/release_v10/makedumpfile/makedumpfile_cvs_kh10
- An initramfs image can be used as the root file system of kexeced
kernel. An initramfs image built with "BuildRoot" can be downloaded
from the following URL:
initramfs image: http://khibernation.sourceforge.net/download/release_v10/initramfs/rootfs_cvs_kh10.gz
All user space tools above are included in the initramfs image.
Usage example of simple hibernation:
1. Compile and install patched kernel with following options selected:
CONFIG_X86_32=y
CONFIG_RELOCATABLE=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PM=y
CONFIG_HIBERNATION=y
CONFIG_KEXEC_JUMP=y
2. Build an initramfs image contains kexec-tool and makedumpfile, or
download the pre-built initramfs image, called rootfs.gz in
following text.
3. Prepare a partition to save memory image of original kernel, called
hibernating partition in following text.
4. Boot kernel compiled in step 1 (kernel A).
5. In the kernel A, load kernel compiled in step 1 (kernel B) with
/sbin/kexec. The shell command line can be as follow:
/sbin/kexec --load-preserve-context /boot/bzImage --mem-min=0x100000
--mem-max=0xffffff --initrd=rootfs.gz
6. Boot the kernel B with following shell command line:
/sbin/kexec -e
7. The kernel B will boot as normal kexec. In kernel B the memory
image of kernel A can be saved into hibernating partition as
follow:
jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep kexec_jump_back_entry | cut -d '='`
echo $jump_back_entry > kexec_jump_back_entry
cp /proc/vmcore dump.elf
Then you can shutdown the machine as normal.
8. Boot kernel compiled in step 1 (kernel C). Use the rootfs.gz as
root file system.
9. In kernel C, load the memory image of kernel A as follow:
/sbin/kexec -l --args-none --entry=`cat kexec_jump_back_entry` dump.elf
10. Jump back to the kernel A as follow:
/sbin/kexec -e
Then, kernel A is resumed.
Implementation point:
To support jumping between two kernels, before jumping to (executing)
the new kernel and jumping back to the original kernel, the devices
are put into quiescent state, and the state of devices and CPU is
saved. After jumping back from kexeced kernel and jumping to the new
kernel, the state of devices and CPU are restored accordingly. The
devices/CPU state save/restore code of software suspend is called to
implement corresponding function.
Known issues:
- Because the segment number supported by sys_kexec_load is limited,
hibernation image with many segments may not be load. This is
planned to be eliminated by adding a new flag to sys_kexec_load to
make a image can be loaded with multiple sys_kexec_load invoking.
Now, only the i386 architecture is supported.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-26 09:45:10 +07:00
|
|
|
|
2012-06-21 05:19:33 +07:00
|
|
|
#ifdef CONFIG_PM_SLEEP_DEBUG
|
|
|
|
extern bool pm_print_times_enabled;
|
|
|
|
#else
|
|
|
|
#define pm_print_times_enabled (false)
|
|
|
|
#endif
|
|
|
|
|
2012-04-30 03:53:22 +07:00
|
|
|
#ifdef CONFIG_PM_AUTOSLEEP
|
|
|
|
|
|
|
|
/* kernel/power/autosleep.c */
|
|
|
|
void queue_up_suspend_work(void);
|
|
|
|
|
|
|
|
#else /* !CONFIG_PM_AUTOSLEEP */
|
|
|
|
|
|
|
|
static inline void queue_up_suspend_work(void) {}
|
|
|
|
|
|
|
|
#endif /* !CONFIG_PM_AUTOSLEEP */
|
|
|
|
|
2011-08-18 01:42:24 +07:00
|
|
|
#ifdef CONFIG_ARCH_SAVE_PAGE_KEYS
|
|
|
|
/*
|
|
|
|
* The ARCH_SAVE_PAGE_KEYS functions can be used by an architecture
|
|
|
|
* to save/restore additional information to/from the array of page
|
|
|
|
* frame numbers in the hibernation image. For s390 this is used to
|
|
|
|
* save and restore the storage key for each page that is included
|
|
|
|
* in the hibernation image.
|
|
|
|
*/
|
|
|
|
unsigned long page_key_additional_pages(unsigned long pages);
|
|
|
|
int page_key_alloc(unsigned long pages);
|
|
|
|
void page_key_free(void);
|
|
|
|
void page_key_read(unsigned long *pfn);
|
|
|
|
void page_key_memorize(unsigned long *pfn);
|
|
|
|
void page_key_write(void *address);
|
|
|
|
|
|
|
|
#else /* !CONFIG_ARCH_SAVE_PAGE_KEYS */
|
|
|
|
|
|
|
|
static inline unsigned long page_key_additional_pages(unsigned long pages)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline int page_key_alloc(unsigned long pages)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void page_key_free(void) {}
|
|
|
|
static inline void page_key_read(unsigned long *pfn) {}
|
|
|
|
static inline void page_key_memorize(unsigned long *pfn) {}
|
|
|
|
static inline void page_key_write(void *address) {}
|
|
|
|
|
|
|
|
#endif /* !CONFIG_ARCH_SAVE_PAGE_KEYS */
|
|
|
|
|
2007-10-18 17:04:39 +07:00
|
|
|
#endif /* _LINUX_SUSPEND_H */
|