2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* kernel/power/main.c - PM subsystem core functionality.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003 Patrick Mochel
|
|
|
|
* Copyright (c) 2003 Open Source Development Lab
|
|
|
|
*
|
|
|
|
* This file is released under the GPLv2
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2006-12-06 21:36:06 -07:00
|
|
|
#include <linux/module.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/suspend.h>
|
|
|
|
#include <linux/kobject.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/delay.h>
|
|
|
|
#include <linux/errno.h>
|
2008-10-15 22:01:21 -07:00
|
|
|
#include <linux/kmod.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/init.h>
|
2006-06-22 14:47:18 -07:00
|
|
|
#include <linux/console.h>
|
2006-09-25 23:32:48 -07:00
|
|
|
#include <linux/cpu.h>
|
2006-09-25 23:32:58 -07:00
|
|
|
#include <linux/resume-trace.h>
|
2006-12-06 21:34:23 -07:00
|
|
|
#include <linux/freezer.h>
|
2007-02-10 02:43:03 -07:00
|
|
|
#include <linux/vmstat.h>
|
2007-10-18 03:04:44 -07:00
|
|
|
#include <linux/syscalls.h>
|
ftrace: disable tracing for suspend to ram
I've been painstakingly debugging the issue with suspend to ram and
ftraced. The 2.6.28 code does not have this issue, but since the mcount
recording is not going to be in 27, this must be solved for the ftrace
daemon version.
The resume from suspend to ram would reboot because it was triple
faulting. Debugging further, I found that calling the mcount function
itself was not an issue, but it would fault when it incremented
preempt_count. preempt_count is on the tasks info structure that is on the
low memory address of the task's stack. For some reason, it could not
write to it. Resuming out of suspend to ram does quite a lot of funny
tricks to get to work, so it is not surprising at all that simply doing a
preempt_disable() would cause a fault.
Thanks to Rafael for suggesting to add a "while (1);" to find the place in
resuming that is causing the fault. I would place the loop somewhere in
the code, compile and reboot and see if it would either reboot (hit the
fault) or simply hang (hit the loop). Doing this over and over again, I
narrowed it down that it was happening in enable_nonboot_cpus.
At this point, I found that it is easier to simply disable tracing around
the suspend code, instead of searching for the particular function that
can not handle doing a preempt_disable.
This patch disables the tracer as it suspends and reenables it on resume.
I tested this patch on my Laptop, and it can resume fine with the patch.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-08-27 06:14:40 -07:00
|
|
|
#include <linux/ftrace.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
#include "power.h"
|
|
|
|
|
2006-12-06 21:34:35 -07:00
|
|
|
DEFINE_MUTEX(pm_mutex);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-12-13 15:38:03 -07:00
|
|
|
unsigned int pm_flags;
|
|
|
|
EXPORT_SYMBOL(pm_flags);
|
|
|
|
|
2007-11-19 15:49:18 -07:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
|
|
|
/* Routines for PM-transition notifications */
|
|
|
|
|
|
|
|
static BLOCKING_NOTIFIER_HEAD(pm_chain_head);
|
|
|
|
|
|
|
|
int register_pm_notifier(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return blocking_notifier_chain_register(&pm_chain_head, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(register_pm_notifier);
|
|
|
|
|
|
|
|
int unregister_pm_notifier(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return blocking_notifier_chain_unregister(&pm_chain_head, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(unregister_pm_notifier);
|
|
|
|
|
|
|
|
int pm_notifier_call_chain(unsigned long val)
|
|
|
|
{
|
|
|
|
return (blocking_notifier_call_chain(&pm_chain_head, val, NULL)
|
|
|
|
== NOTIFY_BAD) ? -EINVAL : 0;
|
|
|
|
}
|
|
|
|
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
#ifdef CONFIG_PM_DEBUG
|
|
|
|
int pm_test_level = TEST_NONE;
|
|
|
|
|
|
|
|
static int suspend_test(int level)
|
|
|
|
{
|
|
|
|
if (pm_test_level == level) {
|
|
|
|
printk(KERN_INFO "suspend debug: Waiting for 5 seconds.\n");
|
|
|
|
mdelay(5000);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const char * const pm_tests[__TEST_AFTER_LAST] = {
|
|
|
|
[TEST_NONE] = "none",
|
|
|
|
[TEST_CORE] = "core",
|
|
|
|
[TEST_CPUS] = "processors",
|
|
|
|
[TEST_PLATFORM] = "platform",
|
|
|
|
[TEST_DEVICES] = "devices",
|
|
|
|
[TEST_FREEZER] = "freezer",
|
|
|
|
};
|
|
|
|
|
2008-01-28 16:29:06 -07:00
|
|
|
static ssize_t pm_test_show(struct kobject *kobj, struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
{
|
|
|
|
char *s = buf;
|
|
|
|
int level;
|
|
|
|
|
|
|
|
for (level = TEST_FIRST; level <= TEST_MAX; level++)
|
|
|
|
if (pm_tests[level]) {
|
|
|
|
if (level == pm_test_level)
|
|
|
|
s += sprintf(s, "[%s] ", pm_tests[level]);
|
|
|
|
else
|
|
|
|
s += sprintf(s, "%s ", pm_tests[level]);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (s != buf)
|
|
|
|
/* convert the last space to a newline */
|
|
|
|
*(s-1) = '\n';
|
|
|
|
|
|
|
|
return (s - buf);
|
|
|
|
}
|
|
|
|
|
2008-01-28 16:29:06 -07:00
|
|
|
static ssize_t pm_test_store(struct kobject *kobj, struct kobj_attribute *attr,
|
|
|
|
const char *buf, size_t n)
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
{
|
|
|
|
const char * const *s;
|
|
|
|
int level;
|
|
|
|
char *p;
|
|
|
|
int len;
|
|
|
|
int error = -EINVAL;
|
|
|
|
|
|
|
|
p = memchr(buf, '\n', n);
|
|
|
|
len = p ? p - buf : n;
|
|
|
|
|
|
|
|
mutex_lock(&pm_mutex);
|
|
|
|
|
|
|
|
level = TEST_FIRST;
|
|
|
|
for (s = &pm_tests[level]; level <= TEST_MAX; s++, level++)
|
|
|
|
if (*s && len == strlen(*s) && !strncmp(buf, *s, len)) {
|
|
|
|
pm_test_level = level;
|
|
|
|
error = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&pm_mutex);
|
|
|
|
|
|
|
|
return error ? error : n;
|
|
|
|
}
|
|
|
|
|
|
|
|
power_attr(pm_test);
|
|
|
|
#else /* !CONFIG_PM_DEBUG */
|
|
|
|
static inline int suspend_test(int level) { return 0; }
|
|
|
|
#endif /* !CONFIG_PM_DEBUG */
|
|
|
|
|
2007-12-13 17:07:13 -07:00
|
|
|
#endif /* CONFIG_PM_SLEEP */
|
2008-01-28 16:29:06 -07:00
|
|
|
|
2007-07-29 14:27:18 -07:00
|
|
|
#ifdef CONFIG_SUSPEND
|
|
|
|
|
2008-07-23 21:28:33 -07:00
|
|
|
#ifdef CONFIG_PM_TEST_SUSPEND
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We test the system suspend code by setting an RTC wakealarm a short
|
|
|
|
* time in the future, then suspending. Suspending the devices won't
|
|
|
|
* normally take long ... some systems only need a few milliseconds.
|
|
|
|
*
|
|
|
|
* The time it takes is system-specific though, so when we test this
|
|
|
|
* during system bootup we allow a LOT of time.
|
|
|
|
*/
|
|
|
|
#define TEST_SUSPEND_SECONDS 5
|
|
|
|
|
|
|
|
static unsigned long suspend_test_start_time;
|
|
|
|
|
|
|
|
static void suspend_test_start(void)
|
|
|
|
{
|
|
|
|
/* FIXME Use better timebase than "jiffies", ideally a clocksource.
|
|
|
|
* What we want is a hardware counter that will work correctly even
|
|
|
|
* during the irqs-are-off stages of the suspend/resume cycle...
|
|
|
|
*/
|
|
|
|
suspend_test_start_time = jiffies;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void suspend_test_finish(const char *label)
|
|
|
|
{
|
|
|
|
long nj = jiffies - suspend_test_start_time;
|
|
|
|
unsigned msec;
|
|
|
|
|
|
|
|
msec = jiffies_to_msecs(abs(nj));
|
|
|
|
pr_info("PM: %s took %d.%03d seconds\n", label,
|
|
|
|
msec / 1000, msec % 1000);
|
|
|
|
|
|
|
|
/* Warning on suspend means the RTC alarm period needs to be
|
|
|
|
* larger -- the system was sooo slooowwww to suspend that the
|
|
|
|
* alarm (should have) fired before the system went to sleep!
|
|
|
|
*
|
|
|
|
* Warning on either suspend or resume also means the system
|
|
|
|
* has some performance issues. The stack dump of a WARN_ON
|
|
|
|
* is more likely to get the right attention than a printk...
|
|
|
|
*/
|
|
|
|
WARN_ON(msec > (TEST_SUSPEND_SECONDS * 1000));
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
static void suspend_test_start(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
static void suspend_test_finish(const char *label)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2007-07-29 14:27:18 -07:00
|
|
|
/* This is just an arbitrary number */
|
|
|
|
#define FREE_PAGE_NUMBER (100)
|
|
|
|
|
2007-10-18 03:04:41 -07:00
|
|
|
static struct platform_suspend_ops *suspend_ops;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/**
|
2007-10-18 03:04:40 -07:00
|
|
|
* suspend_set_ops - Set the global suspend method table.
|
2005-04-16 15:20:36 -07:00
|
|
|
* @ops: Pointer to ops structure.
|
|
|
|
*/
|
|
|
|
|
2007-10-18 03:04:40 -07:00
|
|
|
void suspend_set_ops(struct platform_suspend_ops *ops)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2006-12-06 21:34:35 -07:00
|
|
|
mutex_lock(&pm_mutex);
|
2007-10-18 03:04:40 -07:00
|
|
|
suspend_ops = ops;
|
2006-12-06 21:34:35 -07:00
|
|
|
mutex_unlock(&pm_mutex);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2007-04-30 15:09:54 -07:00
|
|
|
/**
|
2007-10-18 03:04:40 -07:00
|
|
|
* suspend_valid_only_mem - generic memory-only valid callback
|
2007-04-30 15:09:54 -07:00
|
|
|
*
|
2007-10-18 03:04:40 -07:00
|
|
|
* Platform drivers that implement mem suspend only and only need
|
2007-04-30 15:09:54 -07:00
|
|
|
* to check for that in their .valid callback can use this instead
|
|
|
|
* of rolling their own .valid callback.
|
|
|
|
*/
|
2007-10-18 03:04:40 -07:00
|
|
|
int suspend_valid_only_mem(suspend_state_t state)
|
2007-04-30 15:09:54 -07:00
|
|
|
{
|
|
|
|
return state == PM_SUSPEND_MEM;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/**
|
|
|
|
* suspend_prepare - Do prep work before entering low-power state.
|
|
|
|
*
|
2007-07-19 01:47:38 -07:00
|
|
|
* This is common code that is called for each state that we're entering.
|
|
|
|
* Run suspend notifiers, allocate a console and stop all processes.
|
2005-04-16 15:20:36 -07:00
|
|
|
*/
|
2007-07-19 01:47:38 -07:00
|
|
|
static int suspend_prepare(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2006-09-25 23:32:48 -07:00
|
|
|
int error;
|
2005-03-18 14:27:13 -07:00
|
|
|
unsigned int free_pages;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-18 03:04:40 -07:00
|
|
|
if (!suspend_ops || !suspend_ops->enter)
|
2005-04-16 15:20:36 -07:00
|
|
|
return -EPERM;
|
|
|
|
|
2008-01-10 17:22:23 -07:00
|
|
|
pm_prepare_console();
|
|
|
|
|
2007-07-19 01:47:36 -07:00
|
|
|
error = pm_notifier_call_chain(PM_SUSPEND_PREPARE);
|
|
|
|
if (error)
|
|
|
|
goto Finish;
|
|
|
|
|
2008-10-15 22:01:21 -07:00
|
|
|
error = usermodehelper_disable();
|
|
|
|
if (error)
|
|
|
|
goto Finish;
|
|
|
|
|
2008-01-15 21:17:00 -07:00
|
|
|
if (suspend_freeze_processes()) {
|
2005-04-16 15:20:36 -07:00
|
|
|
error = -EAGAIN;
|
|
|
|
goto Thaw;
|
|
|
|
}
|
|
|
|
|
2007-07-19 01:47:38 -07:00
|
|
|
free_pages = global_page_state(NR_FREE_PAGES);
|
|
|
|
if (free_pages < FREE_PAGE_NUMBER) {
|
2005-03-18 14:27:13 -07:00
|
|
|
pr_debug("PM: free some memory\n");
|
|
|
|
shrink_all_memory(FREE_PAGE_NUMBER - free_pages);
|
|
|
|
if (nr_free_pages() < FREE_PAGE_NUMBER) {
|
|
|
|
error = -ENOMEM;
|
|
|
|
printk(KERN_ERR "PM: No enough memory\n");
|
|
|
|
}
|
|
|
|
}
|
2007-02-10 02:43:31 -07:00
|
|
|
if (!error)
|
|
|
|
return 0;
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
Thaw:
|
2008-01-15 21:17:00 -07:00
|
|
|
suspend_thaw_processes();
|
2008-10-15 22:01:21 -07:00
|
|
|
usermodehelper_enable();
|
2007-07-19 01:47:36 -07:00
|
|
|
Finish:
|
|
|
|
pm_notifier_call_chain(PM_POST_SUSPEND);
|
2008-01-10 17:22:23 -07:00
|
|
|
pm_restore_console();
|
2005-04-16 15:20:36 -07:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2007-04-26 02:43:58 -07:00
|
|
|
/* 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();
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-19 01:47:38 -07:00
|
|
|
/**
|
|
|
|
* suspend_enter - enter the desired system sleep state.
|
|
|
|
* @state: state to enter
|
|
|
|
*
|
|
|
|
* This function should be called after devices have been suspended.
|
|
|
|
*/
|
2007-10-18 03:04:37 -07:00
|
|
|
static int suspend_enter(suspend_state_t state)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
int error = 0;
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 14:00:01 -07:00
|
|
|
device_pm_lock();
|
2007-04-26 02:43:58 -07:00
|
|
|
arch_suspend_disable_irqs();
|
|
|
|
BUG_ON(!irqs_disabled());
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
if ((error = device_power_down(PMSG_SUSPEND))) {
|
2007-12-07 18:08:38 -07:00
|
|
|
printk(KERN_ERR "PM: Some devices failed to power down\n");
|
2005-04-16 15:20:36 -07:00
|
|
|
goto Done;
|
|
|
|
}
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
|
|
|
|
if (!suspend_test(TEST_CORE))
|
|
|
|
error = suspend_ops->enter(state);
|
|
|
|
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 14:00:01 -07:00
|
|
|
device_power_up(PMSG_RESUME);
|
2005-04-16 15:20:36 -07:00
|
|
|
Done:
|
2007-04-26 02:43:58 -07:00
|
|
|
arch_suspend_enable_irqs();
|
|
|
|
BUG_ON(irqs_disabled());
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 14:00:01 -07:00
|
|
|
device_pm_unlock();
|
2005-04-16 15:20:36 -07:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
2007-07-19 01:47:38 -07:00
|
|
|
/**
|
2007-12-07 18:06:00 -07:00
|
|
|
* suspend_devices_and_enter - suspend devices and enter the desired system
|
|
|
|
* sleep state.
|
2007-07-19 01:47:38 -07:00
|
|
|
* @state: state to enter
|
|
|
|
*/
|
|
|
|
int suspend_devices_and_enter(suspend_state_t state)
|
|
|
|
{
|
ftrace: disable tracing for suspend to ram
I've been painstakingly debugging the issue with suspend to ram and
ftraced. The 2.6.28 code does not have this issue, but since the mcount
recording is not going to be in 27, this must be solved for the ftrace
daemon version.
The resume from suspend to ram would reboot because it was triple
faulting. Debugging further, I found that calling the mcount function
itself was not an issue, but it would fault when it incremented
preempt_count. preempt_count is on the tasks info structure that is on the
low memory address of the task's stack. For some reason, it could not
write to it. Resuming out of suspend to ram does quite a lot of funny
tricks to get to work, so it is not surprising at all that simply doing a
preempt_disable() would cause a fault.
Thanks to Rafael for suggesting to add a "while (1);" to find the place in
resuming that is causing the fault. I would place the loop somewhere in
the code, compile and reboot and see if it would either reboot (hit the
fault) or simply hang (hit the loop). Doing this over and over again, I
narrowed it down that it was happening in enable_nonboot_cpus.
At this point, I found that it is easier to simply disable tracing around
the suspend code, instead of searching for the particular function that
can not handle doing a preempt_disable.
This patch disables the tracer as it suspends and reenables it on resume.
I tested this patch on my Laptop, and it can resume fine with the patch.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-08-27 06:14:40 -07:00
|
|
|
int error, ftrace_save;
|
2007-07-19 01:47:38 -07:00
|
|
|
|
2007-10-18 03:04:40 -07:00
|
|
|
if (!suspend_ops)
|
2007-07-19 01:47:38 -07:00
|
|
|
return -ENOSYS;
|
|
|
|
|
2008-01-07 16:04:17 -07:00
|
|
|
if (suspend_ops->begin) {
|
|
|
|
error = suspend_ops->begin(state);
|
2007-07-19 01:47:38 -07:00
|
|
|
if (error)
|
2008-01-07 16:04:17 -07:00
|
|
|
goto Close;
|
2007-07-19 01:47:38 -07:00
|
|
|
}
|
|
|
|
suspend_console();
|
ftrace: disable tracing for suspend to ram
I've been painstakingly debugging the issue with suspend to ram and
ftraced. The 2.6.28 code does not have this issue, but since the mcount
recording is not going to be in 27, this must be solved for the ftrace
daemon version.
The resume from suspend to ram would reboot because it was triple
faulting. Debugging further, I found that calling the mcount function
itself was not an issue, but it would fault when it incremented
preempt_count. preempt_count is on the tasks info structure that is on the
low memory address of the task's stack. For some reason, it could not
write to it. Resuming out of suspend to ram does quite a lot of funny
tricks to get to work, so it is not surprising at all that simply doing a
preempt_disable() would cause a fault.
Thanks to Rafael for suggesting to add a "while (1);" to find the place in
resuming that is causing the fault. I would place the loop somewhere in
the code, compile and reboot and see if it would either reboot (hit the
fault) or simply hang (hit the loop). Doing this over and over again, I
narrowed it down that it was happening in enable_nonboot_cpus.
At this point, I found that it is easier to simply disable tracing around
the suspend code, instead of searching for the particular function that
can not handle doing a preempt_disable.
This patch disables the tracer as it suspends and reenables it on resume.
I tested this patch on my Laptop, and it can resume fine with the patch.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-08-27 06:14:40 -07:00
|
|
|
ftrace_save = __ftrace_enabled_save();
|
2008-07-23 21:28:33 -07:00
|
|
|
suspend_test_start();
|
2007-07-19 01:47:38 -07:00
|
|
|
error = device_suspend(PMSG_SUSPEND);
|
|
|
|
if (error) {
|
2007-12-07 18:08:38 -07:00
|
|
|
printk(KERN_ERR "PM: Some devices failed to suspend\n");
|
2008-06-12 14:24:06 -07:00
|
|
|
goto Recover_platform;
|
2007-07-19 01:47:38 -07:00
|
|
|
}
|
2008-07-23 21:28:33 -07:00
|
|
|
suspend_test_finish("suspend devices");
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
if (suspend_test(TEST_DEVICES))
|
2008-06-12 14:24:06 -07:00
|
|
|
goto Recover_platform;
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
|
2007-10-18 03:04:40 -07:00
|
|
|
if (suspend_ops->prepare) {
|
2007-10-18 03:04:41 -07:00
|
|
|
error = suspend_ops->prepare();
|
2007-07-19 01:47:38 -07:00
|
|
|
if (error)
|
|
|
|
goto Resume_devices;
|
|
|
|
}
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
|
|
|
|
if (suspend_test(TEST_PLATFORM))
|
|
|
|
goto Finish;
|
|
|
|
|
2007-07-19 01:47:38 -07:00
|
|
|
error = disable_nonboot_cpus();
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
if (!error && !suspend_test(TEST_CPUS))
|
2007-07-19 01:47:38 -07:00
|
|
|
suspend_enter(state);
|
|
|
|
|
|
|
|
enable_nonboot_cpus();
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
Finish:
|
2007-10-18 03:04:41 -07:00
|
|
|
if (suspend_ops->finish)
|
|
|
|
suspend_ops->finish();
|
2007-07-19 01:47:38 -07:00
|
|
|
Resume_devices:
|
2008-07-23 21:28:33 -07:00
|
|
|
suspend_test_start();
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-20 14:00:01 -07:00
|
|
|
device_resume(PMSG_RESUME);
|
2008-07-23 21:28:33 -07:00
|
|
|
suspend_test_finish("resume devices");
|
ftrace: disable tracing for suspend to ram
I've been painstakingly debugging the issue with suspend to ram and
ftraced. The 2.6.28 code does not have this issue, but since the mcount
recording is not going to be in 27, this must be solved for the ftrace
daemon version.
The resume from suspend to ram would reboot because it was triple
faulting. Debugging further, I found that calling the mcount function
itself was not an issue, but it would fault when it incremented
preempt_count. preempt_count is on the tasks info structure that is on the
low memory address of the task's stack. For some reason, it could not
write to it. Resuming out of suspend to ram does quite a lot of funny
tricks to get to work, so it is not surprising at all that simply doing a
preempt_disable() would cause a fault.
Thanks to Rafael for suggesting to add a "while (1);" to find the place in
resuming that is causing the fault. I would place the loop somewhere in
the code, compile and reboot and see if it would either reboot (hit the
fault) or simply hang (hit the loop). Doing this over and over again, I
narrowed it down that it was happening in enable_nonboot_cpus.
At this point, I found that it is easier to simply disable tracing around
the suspend code, instead of searching for the particular function that
can not handle doing a preempt_disable.
This patch disables the tracer as it suspends and reenables it on resume.
I tested this patch on my Laptop, and it can resume fine with the patch.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-08-27 06:14:40 -07:00
|
|
|
__ftrace_enabled_restore(ftrace_save);
|
2007-07-19 01:47:38 -07:00
|
|
|
resume_console();
|
2008-01-07 16:04:17 -07:00
|
|
|
Close:
|
|
|
|
if (suspend_ops->end)
|
|
|
|
suspend_ops->end();
|
2007-07-19 01:47:38 -07:00
|
|
|
return error;
|
2008-06-12 14:24:06 -07:00
|
|
|
|
|
|
|
Recover_platform:
|
|
|
|
if (suspend_ops->recover)
|
|
|
|
suspend_ops->recover();
|
|
|
|
goto Resume_devices;
|
2007-07-19 01:47:38 -07:00
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
2007-07-19 01:47:38 -07:00
|
|
|
static void suspend_finish(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2008-01-15 21:17:00 -07:00
|
|
|
suspend_thaw_processes();
|
2008-10-15 22:01:21 -07:00
|
|
|
usermodehelper_enable();
|
2007-07-19 01:47:36 -07:00
|
|
|
pm_notifier_call_chain(PM_POST_SUSPEND);
|
2008-01-10 17:22:23 -07:00
|
|
|
pm_restore_console();
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 05:47:56 -07:00
|
|
|
static const char * const pm_states[PM_SUSPEND_MAX] = {
|
2005-04-16 15:20:36 -07:00
|
|
|
[PM_SUSPEND_STANDBY] = "standby",
|
|
|
|
[PM_SUSPEND_MEM] = "mem",
|
|
|
|
};
|
|
|
|
|
2005-11-29 20:34:37 -07:00
|
|
|
static inline int valid_state(suspend_state_t state)
|
|
|
|
{
|
2007-05-09 02:33:18 -07:00
|
|
|
/* All states need lowlevel support and need to be valid
|
|
|
|
* to the lowlevel implementation, no valid callback
|
2007-04-30 15:09:55 -07:00
|
|
|
* implies that none are valid. */
|
2007-10-18 03:04:40 -07:00
|
|
|
if (!suspend_ops || !suspend_ops->valid || !suspend_ops->valid(state))
|
2005-11-29 20:34:37 -07:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* 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).
|
|
|
|
*/
|
|
|
|
static int enter_state(suspend_state_t state)
|
|
|
|
{
|
|
|
|
int error;
|
|
|
|
|
2005-11-29 20:34:37 -07:00
|
|
|
if (!valid_state(state))
|
2005-10-30 16:00:01 -07:00
|
|
|
return -ENODEV;
|
2007-10-18 03:04:44 -07:00
|
|
|
|
2006-12-06 21:34:35 -07:00
|
|
|
if (!mutex_trylock(&pm_mutex))
|
2005-04-16 15:20:36 -07:00
|
|
|
return -EBUSY;
|
|
|
|
|
2007-12-07 18:08:38 -07:00
|
|
|
printk(KERN_INFO "PM: Syncing filesystems ... ");
|
2007-10-18 03:04:44 -07:00
|
|
|
sys_sync();
|
|
|
|
printk("done.\n");
|
|
|
|
|
2005-05-09 08:07:00 -07:00
|
|
|
pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
error = suspend_prepare();
|
|
|
|
if (error)
|
2005-04-16 15:20:36 -07:00
|
|
|
goto Unlock;
|
|
|
|
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
if (suspend_test(TEST_FREEZER))
|
|
|
|
goto Finish;
|
|
|
|
|
2005-05-09 08:07:00 -07:00
|
|
|
pr_debug("PM: Entering %s sleep\n", pm_states[state]);
|
2007-07-19 01:47:38 -07:00
|
|
|
error = suspend_devices_and_enter(state);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
Finish:
|
2005-05-09 08:07:00 -07:00
|
|
|
pr_debug("PM: Finishing wakeup.\n");
|
2007-07-19 01:47:38 -07:00
|
|
|
suspend_finish();
|
2005-04-16 15:20:36 -07:00
|
|
|
Unlock:
|
2006-12-06 21:34:35 -07:00
|
|
|
mutex_unlock(&pm_mutex);
|
2005-04-16 15:20:36 -07:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* pm_suspend - Externally visible function for suspending system.
|
2007-05-09 02:33:18 -07:00
|
|
|
* @state: Enumerated value of state to enter.
|
2005-04-16 15:20:36 -07:00
|
|
|
*
|
|
|
|
* Determine whether or not value is within range, get state
|
|
|
|
* structure, and enter (above).
|
|
|
|
*/
|
|
|
|
|
|
|
|
int pm_suspend(suspend_state_t state)
|
|
|
|
{
|
2005-03-18 14:20:46 -07:00
|
|
|
if (state > PM_SUSPEND_ON && state <= PM_SUSPEND_MAX)
|
2005-04-16 15:20:36 -07:00
|
|
|
return enter_state(state);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2006-12-06 21:36:06 -07:00
|
|
|
EXPORT_SYMBOL(pm_suspend);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-07-29 14:27:18 -07:00
|
|
|
#endif /* CONFIG_SUSPEND */
|
|
|
|
|
2007-11-27 12:28:26 -07:00
|
|
|
struct kobject *power_kobj;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* state - control system power state.
|
|
|
|
*
|
|
|
|
* show() returns what states are supported, which is hard-coded to
|
|
|
|
* 'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and
|
|
|
|
* 'disk' (Suspend-to-Disk).
|
|
|
|
*
|
|
|
|
* store() accepts one of those strings, translates it into the
|
|
|
|
* proper enumerated value, and initiates a suspend transition.
|
|
|
|
*/
|
|
|
|
|
2007-11-02 05:47:53 -07:00
|
|
|
static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2007-07-29 14:27:18 -07:00
|
|
|
char *s = buf;
|
|
|
|
#ifdef CONFIG_SUSPEND
|
2005-04-16 15:20:36 -07:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < PM_SUSPEND_MAX; i++) {
|
2005-11-29 20:34:37 -07:00
|
|
|
if (pm_states[i] && valid_state(i))
|
|
|
|
s += sprintf(s,"%s ", pm_states[i]);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
2007-07-29 14:27:18 -07:00
|
|
|
#endif
|
2007-07-29 14:24:36 -07:00
|
|
|
#ifdef CONFIG_HIBERNATION
|
2007-05-09 02:33:18 -07:00
|
|
|
s += sprintf(s, "%s\n", "disk");
|
|
|
|
#else
|
|
|
|
if (s != buf)
|
|
|
|
/* convert the last space to a newline */
|
|
|
|
*(s-1) = '\n';
|
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
return (s - buf);
|
|
|
|
}
|
|
|
|
|
2007-11-02 05:47:53 -07:00
|
|
|
static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
|
|
|
|
const char *buf, size_t n)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2007-07-29 14:27:18 -07:00
|
|
|
#ifdef CONFIG_SUSPEND
|
2005-04-16 15:20:36 -07:00
|
|
|
suspend_state_t state = PM_SUSPEND_STANDBY;
|
2006-06-25 05:47:56 -07:00
|
|
|
const char * const *s;
|
2007-07-29 14:27:18 -07:00
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
char *p;
|
|
|
|
int len;
|
2007-07-29 14:27:18 -07:00
|
|
|
int error = -EINVAL;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
p = memchr(buf, '\n', n);
|
|
|
|
len = p ? p - buf : n;
|
|
|
|
|
2007-05-09 02:33:18 -07:00
|
|
|
/* First, check if we are requested to hibernate */
|
2007-05-16 22:11:19 -07:00
|
|
|
if (len == 4 && !strncmp(buf, "disk", len)) {
|
2007-05-09 02:33:18 -07:00
|
|
|
error = hibernate();
|
2007-07-29 14:27:18 -07:00
|
|
|
goto Exit;
|
2007-05-09 02:33:18 -07:00
|
|
|
}
|
|
|
|
|
2007-07-29 14:27:18 -07:00
|
|
|
#ifdef CONFIG_SUSPEND
|
2005-04-16 15:20:36 -07:00
|
|
|
for (s = &pm_states[state]; state < PM_SUSPEND_MAX; s++, state++) {
|
2007-05-16 22:11:19 -07:00
|
|
|
if (*s && len == strlen(*s) && !strncmp(buf, *s, len))
|
2005-04-16 15:20:36 -07:00
|
|
|
break;
|
|
|
|
}
|
2006-04-27 18:39:17 -07:00
|
|
|
if (state < PM_SUSPEND_MAX && *s)
|
2005-04-16 15:20:36 -07:00
|
|
|
error = enter_state(state);
|
2007-07-29 14:27:18 -07:00
|
|
|
#endif
|
|
|
|
|
|
|
|
Exit:
|
2005-04-16 15:20:36 -07:00
|
|
|
return error ? error : n;
|
|
|
|
}
|
|
|
|
|
|
|
|
power_attr(state);
|
|
|
|
|
2006-09-25 23:32:58 -07:00
|
|
|
#ifdef CONFIG_PM_TRACE
|
|
|
|
int pm_trace_enabled;
|
|
|
|
|
2007-11-02 05:47:53 -07:00
|
|
|
static ssize_t pm_trace_show(struct kobject *kobj, struct kobj_attribute *attr,
|
|
|
|
char *buf)
|
2006-09-25 23:32:58 -07:00
|
|
|
{
|
|
|
|
return sprintf(buf, "%d\n", pm_trace_enabled);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t
|
2007-11-02 05:47:53 -07:00
|
|
|
pm_trace_store(struct kobject *kobj, struct kobj_attribute *attr,
|
|
|
|
const char *buf, size_t n)
|
2006-09-25 23:32:58 -07:00
|
|
|
{
|
|
|
|
int val;
|
|
|
|
|
|
|
|
if (sscanf(buf, "%d", &val) == 1) {
|
|
|
|
pm_trace_enabled = !!val;
|
|
|
|
return n;
|
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
power_attr(pm_trace);
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
#endif /* CONFIG_PM_TRACE */
|
2006-09-25 23:32:58 -07:00
|
|
|
|
|
|
|
static struct attribute * g[] = {
|
|
|
|
&state_attr.attr,
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
#ifdef CONFIG_PM_TRACE
|
2006-09-25 23:32:58 -07:00
|
|
|
&pm_trace_attr.attr,
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
#endif
|
2007-12-13 17:07:13 -07:00
|
|
|
#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PM_DEBUG)
|
Suspend: Testing facility (rev. 2)
Introduce sysfs attribute /sys/power/pm_test allowing one to test the suspend
core code. Namely, writing one of the strings:
freezer
devices
platform
processors
core
to this file causes the suspend code to work in one of the test modes defined as
follows:
freezer
- test the freezing of processes
devices
- test the freezing of processes and suspending of devices
platform
- test the freezing of processes, suspending of devices and platform global
control methods(*)
processors
- test the freezing of processes, suspending of devices, platform global
control methods and the disabling of nonboot CPUs
core
- test the freezing of processes, suspending of devices, platform global
control methods, the disabling of nonboot CPUs and suspending of
platform/system devices
(*) These are ACPI global control methods on ACPI systems
Then, if a suspend is started by normal means, the suspend core will perform
its normal operations up to the point indicated by given test level. Next, it
will wait for 5 seconds and carry out the resume operations needed to transition
the system back to the fully functional state.
Writing "none" to /sys/power/pm_test turns the testing off.
When open for reading, /sys/power/pm_test contains a space-separated list of all
available tests (including "none" that represents the normal functionality) in
which the current test level is indicated by square brackets.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
2007-11-19 15:41:19 -07:00
|
|
|
&pm_test_attr.attr,
|
|
|
|
#endif
|
2006-09-25 23:32:58 -07:00
|
|
|
NULL,
|
|
|
|
};
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
static struct attribute_group attr_group = {
|
|
|
|
.attrs = g,
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
static int __init pm_init(void)
|
|
|
|
{
|
2007-11-27 12:28:26 -07:00
|
|
|
power_kobj = kobject_create_and_add("power", NULL);
|
|
|
|
if (!power_kobj)
|
2007-11-01 10:39:50 -07:00
|
|
|
return -ENOMEM;
|
2007-11-27 12:28:26 -07:00
|
|
|
return sysfs_create_group(power_kobj, &attr_group);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
core_initcall(pm_init);
|
2008-07-23 21:28:33 -07:00
|
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_PM_TEST_SUSPEND
|
|
|
|
|
|
|
|
#include <linux/rtc.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* To test system suspend, we need a hands-off mechanism to resume the
|
|
|
|
* system. RTCs wake alarms are a common self-contained mechanism.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void __init test_wakealarm(struct rtc_device *rtc, suspend_state_t state)
|
|
|
|
{
|
|
|
|
static char err_readtime[] __initdata =
|
|
|
|
KERN_ERR "PM: can't read %s time, err %d\n";
|
|
|
|
static char err_wakealarm [] __initdata =
|
|
|
|
KERN_ERR "PM: can't set %s wakealarm, err %d\n";
|
|
|
|
static char err_suspend[] __initdata =
|
|
|
|
KERN_ERR "PM: suspend test failed, error %d\n";
|
|
|
|
static char info_test[] __initdata =
|
|
|
|
KERN_INFO "PM: test RTC wakeup from '%s' suspend\n";
|
|
|
|
|
|
|
|
unsigned long now;
|
|
|
|
struct rtc_wkalrm alm;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
/* this may fail if the RTC hasn't been initialized */
|
|
|
|
status = rtc_read_time(rtc, &alm.time);
|
|
|
|
if (status < 0) {
|
|
|
|
printk(err_readtime, rtc->dev.bus_id, status);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
rtc_tm_to_time(&alm.time, &now);
|
|
|
|
|
|
|
|
memset(&alm, 0, sizeof alm);
|
|
|
|
rtc_time_to_tm(now + TEST_SUSPEND_SECONDS, &alm.time);
|
|
|
|
alm.enabled = true;
|
|
|
|
|
|
|
|
status = rtc_set_alarm(rtc, &alm);
|
|
|
|
if (status < 0) {
|
|
|
|
printk(err_wakealarm, rtc->dev.bus_id, status);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (state == PM_SUSPEND_MEM) {
|
|
|
|
printk(info_test, pm_states[state]);
|
|
|
|
status = pm_suspend(state);
|
|
|
|
if (status == -ENODEV)
|
|
|
|
state = PM_SUSPEND_STANDBY;
|
|
|
|
}
|
|
|
|
if (state == PM_SUSPEND_STANDBY) {
|
|
|
|
printk(info_test, pm_states[state]);
|
|
|
|
status = pm_suspend(state);
|
|
|
|
}
|
|
|
|
if (status < 0)
|
|
|
|
printk(err_suspend, status);
|
2008-07-25 19:44:38 -07:00
|
|
|
|
|
|
|
/* Some platforms can't detect that the alarm triggered the
|
|
|
|
* wakeup, or (accordingly) disable it after it afterwards.
|
|
|
|
* It's supposed to give oneshot behavior; cope.
|
|
|
|
*/
|
|
|
|
alm.enabled = false;
|
|
|
|
rtc_set_alarm(rtc, &alm);
|
2008-07-23 21:28:33 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __init has_wakealarm(struct device *dev, void *name_ptr)
|
|
|
|
{
|
|
|
|
struct rtc_device *candidate = to_rtc_device(dev);
|
|
|
|
|
|
|
|
if (!candidate->ops->set_alarm)
|
|
|
|
return 0;
|
|
|
|
if (!device_may_wakeup(candidate->dev.parent))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
*(char **)name_ptr = dev->bus_id;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Kernel options like "test_suspend=mem" force suspend/resume sanity tests
|
|
|
|
* at startup time. They're normally disabled, for faster boot and because
|
|
|
|
* we can't know which states really work on this particular system.
|
|
|
|
*/
|
|
|
|
static suspend_state_t test_state __initdata = PM_SUSPEND_ON;
|
|
|
|
|
|
|
|
static char warn_bad_state[] __initdata =
|
|
|
|
KERN_WARNING "PM: can't test '%s' suspend state\n";
|
|
|
|
|
|
|
|
static int __init setup_test_suspend(char *value)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
/* "=mem" ==> "mem" */
|
|
|
|
value++;
|
|
|
|
for (i = 0; i < PM_SUSPEND_MAX; i++) {
|
|
|
|
if (!pm_states[i])
|
|
|
|
continue;
|
|
|
|
if (strcmp(pm_states[i], value) != 0)
|
|
|
|
continue;
|
|
|
|
test_state = (__force suspend_state_t) i;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
printk(warn_bad_state, value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
__setup("test_suspend", setup_test_suspend);
|
|
|
|
|
|
|
|
static int __init test_suspend(void)
|
|
|
|
{
|
|
|
|
static char warn_no_rtc[] __initdata =
|
|
|
|
KERN_WARNING "PM: no wakealarm-capable RTC driver is ready\n";
|
|
|
|
|
|
|
|
char *pony = NULL;
|
|
|
|
struct rtc_device *rtc = NULL;
|
|
|
|
|
|
|
|
/* PM is initialized by now; is that state testable? */
|
|
|
|
if (test_state == PM_SUSPEND_ON)
|
|
|
|
goto done;
|
|
|
|
if (!valid_state(test_state)) {
|
|
|
|
printk(warn_bad_state, pm_states[test_state]);
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* RTCs have initialized by now too ... can we use one? */
|
|
|
|
class_find_device(rtc_class, NULL, &pony, has_wakealarm);
|
|
|
|
if (pony)
|
|
|
|
rtc = rtc_class_open(pony);
|
|
|
|
if (!rtc) {
|
|
|
|
printk(warn_no_rtc);
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* go for it */
|
|
|
|
test_wakealarm(rtc, test_state);
|
|
|
|
rtc_class_close(rtc);
|
|
|
|
done:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
late_initcall(test_suspend);
|
|
|
|
|
|
|
|
#endif /* CONFIG_PM_TEST_SUSPEND */
|