Android PM extensions

This adds /sys/power/wake_lock and /sys/power/wake_unlock. Writing a string to wake_lock creates a wake lock the first time is sees a string and locks it. Optionally, the string can be followed by a timeout.
To unlock the wake lock, write the same string to wake_unlock.

Quoted 5 lines · Arve Hjønnevåg

This adds /sys/power/wake_lock and /sys/power/wake_unlock. Writing a string to wake_lock creates a wake lock the first time is sees a string and locks it. Optionally, the string can be followed by a timeout.
To unlock the wake lock, write the same string to wake_unlock.

What happens if a process takes a lock and then dies?

Instead of using sysfs, how about using a device for this purpose which the caller has to keep open as long as they want to hold the lock.

Quoted 5 lines

This adds /sys/power/wake_lock and /sys/power/wake_unlock. Writing a string to wake_lock creates a wake lock the first time is sees a string and locks it. Optionally, the string can be followed by a timeout.
To unlock the wake lock, write the same string to wake_unlock.

What happens if a process takes a lock and then dies?
Instead of using sysfs, how about using a device for this purpose which the caller has to keep open as long as they want to hold the lock.

If EARLYSUSPEND is enabled then writes to /sys/power/state no longer blocks, and the kernel will try to enter the requested state every time no wakelocks are held. Write "on" to resume normal operation.

kernel/power/main.c +3 -0

@@ -388,6 +388,9 @@ static void suspend_finish(void)
 
 
 static const char * const pm_states[PM_SUSPEND_MAX] = {
+#ifdef CONFIG_EARLYSUSPEND
+	[PM_SUSPEND_ON]		= "on",
+#endif
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };

@@ -505,7 +508,11 @@ static ssize_t state_store(struct kobject
 *kobj, struct kobj_attribute *attr,

Hi!

Quoted 3 lines

If EARLYSUSPEND is enabled then writes to /sys/power/state no longer blocks, and the kernel will try to enter the requested state every time no wakelocks are held. Write "on" to resume normal operation.

No, please don't break compatibility like this. You changed semantics of 'mem'...

Just add another two states, for example "auto-mem" and "auto-standby", and make them enter mem/standby when required.

Quoted 6 lines

No, please don't break compatibility like this. You changed semantics of 'mem'...

Just add another two states, for example "auto-mem" and "auto-standby", and make them enter mem/standby when required.

What would you want to happen if someone writes "mem"? If we just call enter_state, it will fail and return an error if a wakelock is locked. We can call request_suspend_state and then wait for another thread to write "on", but this still requires user-space changes to work correctly. If the goal is to allow the kernel to be compiled with wakelock and early suspend support while preserving the old behaviour if wakelocks are not used, then the first option is better.

Quoted 7 lines · Arve Hj?nnev?g

Quoted 6 lines

No, please don't break compatibility like this. You changed semantics of 'mem'...

Just add another two states, for example "auto-mem" and "auto-standby", and make them enter mem/standby when required.

Quoted 7 lines

What would you want to happen if someone writes "mem"? If we just call enter_state, it will fail and return an error if a wakelock is locked. We can call request_suspend_state and then wait for another thread to write "on", but this still requires user-space changes to work correctly. If the goal is to allow the kernel to be compiled with wakelock and early suspend support while preserving the old behaviour if wakelocks are not used, then the first option is better.

This is exactly what I am complaining about in another thread. The code should be written so that when the user writes "mem", the system goes into suspend even if some wakelocks are locked.

Quoted 9 lines · Pavel Machek

Hi!

Quoted 3 lines

If EARLYSUSPEND is enabled then writes to /sys/power/state no longer blocks, and the kernel will try to enter the requested state every time no wakelocks are held. Write "on" to resume normal operation.

No, please don't break compatibility like this. You changed semantics of 'mem'...

Quoted 3 lines

Just add another two states, for example "auto-mem" and "auto-standby", and make them enter mem/standby when required.

What would you want to happen if someone writes "mem"? If we just call enter_state, it will fail and return an error if a wakelock is locked.

We can call request_suspend_state and then wait for another thread to write "on", but this still requires user-space changes to work correctly. If the goal is to allow the kernel to be compiled with wakelock and early suspend support while preserving the old behaviour if wakelocks are not used, then the first option is better.

Yes, goal is that compiling in wakelock / early suspend support has no effect on existing functionality.

Signed-off-by Arve Hjønnevåg <[email protected]>

---
 kernel/power/Kconfig        |   12 +++
 kernel/power/Makefile       |    1 +
 kernel/power/earlysuspend.c |  178 +++++++++++++++++++++++++++++++++++++++++++
 kernel/power/power.h        |    6 ++
 4 files changed, 197 insertions(+), 0 deletions(-)
 create mode 100644 kernel/power/earlysuspend.c

kernel/power/Kconfig +12 -0

index 6e3da6e..50690d8 100644
@@ -119,6 +119,9 @@ config SUSPEND_FREEZER
 config HAS_WAKELOCK
 	bool
 
+config HAS_EARLYSUSPEND
+	bool
+
 config WAKELOCK
 	bool "Wake lock"
 	depends on PM && RTC_CLASS

@@ -135,6 +138,15 @@ config WAKELOCK_STAT
 	---help---
 	  Report wake lock stats in /proc/wakelocks
 
+config EARLYSUSPEND
+	bool "Early suspend"
+	depends on WAKELOCK
+	default y
+	select HAS_EARLYSUSPEND
+	---help---
+	  Call early suspend handlers when the user requested sleep state
+	  changes.
+
 config HIBERNATION
 	bool "Hibernation (aka 'suspend to disk')"
 	depends on PM && SWAP && ARCH_HIBERNATION_POSSIBLE

kernel/power/Makefile +1 -0

index 401ddfe..f0f7b15 100644
@@ -6,6 +6,7 @@ endif
 obj-y				:= main.o
 obj-$(CONFIG_PM_SLEEP)		+= process.o console.o
 obj-$(CONFIG_WAKELOCK)		+= wakelock.o
+obj-$(CONFIG_EARLYSUSPEND)	+= earlysuspend.o
 obj-$(CONFIG_HIBERNATION)	+= swsusp.o disk.o snapshot.o swap.o user.o
 
 obj-$(CONFIG_MAGIC_SYSRQ)	+= poweroff.o

kernel/power/earlysuspend.c new file +19 -0

new file mode 100644
index 0000000..84bed51
@@ -0,0 +1,178 @@
+/* kernel/power/earlysuspend.c
+ *
+ * Copyright (C) 2005-2008 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/earlysuspend.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/rtc.h>

kernel/power/earlysuspend.c new file +15 -0

+static int debug_mask = DEBUG_USER_STATE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+static DEFINE_MUTEX(early_suspend_lock);
+static LIST_HEAD(early_suspend_handlers);
+static void early_suspend(struct work_struct *work);
+static void late_resume(struct work_struct *work);
+static DECLARE_WORK(early_suspend_work, early_suspend);
+static DECLARE_WORK(late_resume_work, late_resume);
+static DEFINE_SPINLOCK(state_lock);
+enum {
+	SUSPEND_REQUESTED = 0x1,
+	SUSPENDED = 0x2,
+	SUSPEND_REQUESTED_AND_SUSPENDED = SUSPEND_REQUESTED | SUSPENDED,
+};

kernel/power/earlysuspend.c new file +33 -0

+		if (e->level > handler->level)
+			break;
+	}
+	list_add_tail(&handler->link, pos);
+	if ((state & SUSPENDED) && handler->suspend)
+		handler->suspend(handler);
+	mutex_unlock(&early_suspend_lock);
+}
+EXPORT_SYMBOL(register_early_suspend);
+
+void unregister_early_suspend(struct early_suspend *handler)
+{
+	mutex_lock(&early_suspend_lock);
+	list_del(&handler->link);
+	mutex_unlock(&early_suspend_lock);
+}
+EXPORT_SYMBOL(unregister_early_suspend);
+
+static void early_suspend(struct work_struct *work)
+{
+	struct early_suspend *pos;
+	unsigned long irqflags;
+	int abort = 0;
+
+	mutex_lock(&early_suspend_lock);
+	spin_lock_irqsave(&state_lock, irqflags);
+	if (state == SUSPEND_REQUESTED)
+		state |= SUSPENDED;
+	else
+		abort = 1;
+	spin_unlock_irqrestore(&state_lock, irqflags);
+
+	if (abort) {

kernel/power/earlysuspend.c new file +7 -0

+abort:
+	spin_lock_irqsave(&state_lock, irqflags);
+	if (state == SUSPEND_REQUESTED_AND_SUSPENDED)
+		wake_unlock(&main_wake_lock);
+	spin_unlock_irqrestore(&state_lock, irqflags);
+}
+

kernel/power/earlysuspend.c new file +43 -0

+			pos->resume(pos);
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("late_resume: done\n");
+abort:
+	mutex_unlock(&early_suspend_lock);
+}
+
+void request_suspend_state(suspend_state_t new_state)
+{
+	unsigned long irqflags;
+	int old_sleep;
+
+	spin_lock_irqsave(&state_lock, irqflags);
+	old_sleep = state & SUSPEND_REQUESTED;
+	if (debug_mask & DEBUG_USER_STATE) {
+		struct timespec ts;
+		struct rtc_time tm;
+		getnstimeofday(&ts);
+		rtc_time_to_tm(ts.tv_sec, &tm);
+		pr_info("request_suspend_state: %s (%d->%d) at %lld "
+			"(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n",
+			new_state != PM_SUSPEND_ON ? "sleep" : "wakeup",
+			requested_suspend_state, new_state,
+			ktime_to_ns(ktime_get()),
+			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
+	}
+	if (!old_sleep && new_state != PM_SUSPEND_ON) {
+		state |= SUSPEND_REQUESTED;
+		queue_work(suspend_work_queue, &early_suspend_work);
+	} else if (old_sleep && new_state == PM_SUSPEND_ON) {
+		state &= ~SUSPEND_REQUESTED;
+		wake_lock(&main_wake_lock);
+		queue_work(suspend_work_queue, &late_resume_work);
+	}
+	requested_suspend_state = new_state;
+	spin_unlock_irqrestore(&state_lock, irqflags);
+}
+
+suspend_state_t get_suspend_state(void)
+{
+	return requested_suspend_state;
+}

kernel/power/power.h +6 -0

index 1527174..7ce9637 100644
@@ -230,3 +230,9 @@ extern struct workqueue_struct *suspend_work_queue;
 extern struct wake_lock main_wake_lock;
 extern suspend_state_t requested_suspend_state;
 #endif
+
+#ifdef CONFIG_EARLYSUSPEND
+/* kernel/power/earlysuspend.c */
+void request_suspend_state(suspend_state_t state);
+suspend_state_t get_suspend_state(void);
+#endif

Signature · 1 line

1.6.1

kernel/power/earlysuspend.c line 29

Quoted 4 lines

kernel/power/earlysuspend.c new file +4 -0

+enum {
+     DEBUG_USER_STATE = 1U << 0,
+     DEBUG_SUSPEND = 1U << 2,
+};

Is there a reason DEBUG_SUSPEND isn't 1U << 1? If so, it might be good to document that here.

kernel/power/earlysuspend.c line 105

Quoted 4 lines

kernel/power/earlysuspend.c new file +4 -0

+     if (debug_mask & DEBUG_SUSPEND)
+             pr_info("early_suspend: sync\n");
+
+     sys_sync();

Why the sync here?

kernel/power/earlysuspend.c line 122

Quoted 2 lines

kernel/power/earlysuspend.c new file +2 -0

+     if (state == SUSPENDED)
+             state &= ~SUSPENDED;

Why not just say state = 0?

Just one comment here - you're adding new procfs entries. IIRC, sysfs is strongly preferred now.

Signed-off-by Arve Hjønnevåg <[email protected]>

---
 include/linux/earlysuspend.h |   56 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)
 create mode 100755 include/linux/earlysuspend.h

include/linux/earlysuspend.h new file +11 -0

new file mode 100755
index 0000000..8343b81
@@ -0,0 +1,56 @@
+/* include/linux/earlysuspend.h
+ *
+ * Copyright (C) 2007-2008 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

Quoted 7 lines

include/linux/earlysuspend.h new file +7 -0

+
+/* The early_suspend structure defines suspend and resume hooks to be called
+ * when the user visible sleep state of the system changes, and a level to
+ * control the order. They can be used to turn off the screen and input
+ * devices that are not used for wakeup.
+ * Suspend handlers are called in low to high level order, resume handlers are
+ * called in the opposite order. If, when calling register_early_suspend,

Quoted 4 lines

+ * the suspend handlers have already been called without a matching call to the
+ * resume handlers, the suspend handler will be called directly from
+ * register_early_suspend. This direct call can violate the normal level order.
+ */

Registering can happen while we're suspending and resuming? That potential variation in ordering sounds dangerous as far as opportunities for race conditions goes.

include/linux/earlysuspend.h line 43

Quoted 6 lines

include/linux/earlysuspend.h new file +6 -0

+struct early_suspend {
+#ifdef CONFIG_HAS_EARLYSUSPEND
+     struct list_head link;
+     int level;
+     void (*suspend)(struct early_suspend *h);
+     void (*resume)(struct early_suspend *h);

Could these functions ever potentially fail in way that you'd want callers to know? If so, you might want a non void return value.

Signed-off-by Arve Hjønnevåg <[email protected]>

---
 include/linux/wakelock.h |   91 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 91 insertions(+), 0 deletions(-)
 create mode 100755 include/linux/wakelock.h

include/linux/wakelock.h new file +14 -0

new file mode 100755
index 0000000..a096d24
@@ -0,0 +1,91 @@
+/* include/linux/wakelock.h
+ *
+ * Copyright (C) 2007-2008 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */

include/linux/wakelock.h new file +17 -0

+ */
+
+enum {
+	WAKE_LOCK_SUSPEND, /* Prevent suspend */
+	WAKE_LOCK_IDLE,    /* Prevent low power idle */
+	WAKE_LOCK_TYPE_COUNT
+};
+
+struct wake_lock {
+#ifdef CONFIG_HAS_WAKELOCK
+	struct list_head    link;
+	int                 flags;
+	const char         *name;
+	unsigned long       expires;
+#ifdef CONFIG_WAKELOCK_STAT
+	struct {
+		int             count;

include/linux/wakelock.h new file +16 -0

+ */
+int wake_lock_active(struct wake_lock *lock);
+
+/* has_wake_lock returns 0 if no wake locks of the specified type are active,
+ * and non-zero if one or more wake locks are held. Specifically it returns
+ * -1 if one or more wake locks with no timeout are active or the
+ * number of jiffies until all active wake locks time out.
+ */
+long has_wake_lock(int type);
+
+#else
+
+static inline void wake_lock_init(struct wake_lock *lock, int type,
+					const char *name) {}
+static inline void wake_lock_destroy(struct wake_lock *lock) {}
+static inline void wake_lock(struct wake_lock *lock) {}

Quoted 3 lines

+/* A wake_lock prevents the system from entering suspend or other low power
+ * states when active. If the type is set to WAKE_LOCK_SUSPEND, the wake_lock
+ * prevents a full system suspend. If the type is WAKE_LOCK_IDLE, low power

Does this include hibernation? If so, you might like to say 'sleep' instead of suspend.

Quoted 2 lines

+ * states that cause large interrupt latencies or that disable a set of
+ * interrupts will not entered from idle until the wake_locks are released.

This makes me wonder if 'wake_locks' is an appropriate name - you're locking against sleeping rather than waking.

If CONFIG_HAS_WAKELOCK and CONFIG_WAKELOCK_STAT are both off, you've got an empty struct wake_lock definition. It wouldn't have any users, would it? (And therefore doesn't need to be defined at all).

Quoted 3 lines

+/* wake_lock_active returns a non-zero value if the wake_lock is currently
+ * locked. If the wake_lock has a timeout, it does not check the timeout
+ * but if the timeout had aready been checked it will return 0.

s/aready/already/

What does it mean for the timeout to already have been checked? Is that the same as the timeout having already expired?

The following patch series adds two apis, wakelock and earlysuspend. The Android platform uses the earlysuspend api to turn the screen and some input devices on and off. The wakelock code determines when to enter the full suspend state.

These apis could also be useful to other platforms where the goal is to enter full suspend whenever possible.

Would you be able to provide some more documentation? In particular, I'm wondering what's 'early' about earlysuspend. It might also be good to something to Documentation/power explaining what the apis are, when/how they're supposed to be used and such like.

In the Kconfig files, I'm also missing the point to HAS_EARLYSUSPEND and HAS_WAKELOCK - they're bools that depends only on and WAKELOCK respectively, so shouldn't you be able to just use the later symbols in ifdefs?

There are a few inlined #ifdefs (#ifdef CONFIG_WAKELOCK_STAT, eg) - the convention as I understand it is to keep #ifdefs out of .c files as much as possible, #ifdef'ing functions in header files instead.

Would you be able to provide some more documentation?

Quoted 1 line · Nigel Cunningham

Would you be able to provide some more documentation?

Would something like this help:
Documentation/power/wakelocks.txt

Wakelocks
=========

A wake_lock prevents the system from entering suspend or other low power states when active. If the type is set to WAKE_LOCK_SUSPEND, the wake_lock prevents a full system suspend. If the type is WAKE_LOCK_IDLE, low power states that cause large interrupt latencies or that disable a set of interrupts will not entered from idle until the wake_locks are released.

What do you mean by "prevents a full system suspend"? Does it mean that attempts to suspend the system will fail? Or will they just block until all these locks are released?

Is there in fact any reason to add a new way for drivers to prevent a full system suspend? They can already cause a suspend to fail by returning an error from their suspend method, or cause a suspend to block by sleeping in their suspend method.

Quoted 7 lines · Arve Hj?nnev?g

Quoted 1 line · Nigel Cunningham

Would you be able to provide some more documentation?

Would something like this help:
Documentation/power/wakelocks.txt

Quoted 8 lines

Wakelocks
=========

A wake_lock prevents the system from entering suspend or other low power states when active. If the type is set to WAKE_LOCK_SUSPEND, the wake_lock prevents a full system suspend. If the type is WAKE_LOCK_IDLE, low power states that cause large interrupt latencies or that disable a set of interrupts will not entered from idle until the wake_locks are released.

Apart from the grammatical errors in this document and the over-engineering it describes, the writeup is terribly ambiguous. What do you mean by "prevents a full system suspend"? Does it mean that attempts to suspend the system will fail? Or will they just block until all these locks are released?

AFAICT, this is something very different. It is attempt to do autosuspend right. Imagine burning cd... right now you can suspend, and it will just stop the burn.

Wakelocks code allows you to tell the machine 'feel free to suspend when you have nothing to do'... so the machine will burn the cd and then suspend.

Documentation/power/wakelocks.txt
Wakelocks
=========

A wakelock prevents the system from entering suspend or other low-power states when active.

If the type is set to WAKE_LOCK_SUSPEND, the wakelock
prevents a full system suspend. If the type is WAKE_LOCK_IDLE, low-power states that cause large interrupt latencies or that disable a set of interrupts will not be entered from idle until the wakelocks are released.

Wakelocks can be used to allow user-space to decide which keys should wake the system. The sequence of events can look like this:

- The Keypad driver gets an interrupt. It then locks the keypad-scan wakelock and starts scanning the keypad.

- The keypad-scan code detects a key change and reports it to the input-event driver.
- The input-event driver sees the key change, enqueues an event, and locks the input-event-queue wakelock.
- The keypad-scan code detects that no keys are held and unlocks the keypad-scan wakelock.

- The user-space input-event thread returns from select/poll, locks the process-input-events wakelock and then calls read in the input-event device.
- The input-event driver dequeues the key-event and, since the queue is now empty, it unlocks the input-event-queue wakelock.

- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

Quoted 2 lines · Arve Hjønnevåg

A wakelock prevents the system from entering suspend or other low-power states when active.

I wish your writing was clearer. "when active" could mean "when the system is active" or "when the wakelock is active". Try to be less ambiguous. For example: "When a wakelock is locked, it blocks the system from entering suspend or other low-power states."

Quoted 4 lines

If the type is set to WAKE_LOCK_SUSPEND, the wakelock
prevents a full system suspend. If the type is WAKE_LOCK_IDLE, low-power states that cause large interrupt latencies or that disable a set of interrupts will not be entered from idle until the wakelocks are released.

Here you talk about "will not be entered from idle", whereas above you mention "when active". So which is it? Does a wakelock affect an active system or an idle system?

Quoted 2 lines

- The Keypad driver gets an interrupt. It then locks the keypad-scan wakelock and starts scanning the keypad.

Is the system asleep to begin with? If it is, how does the keypad driver get this interrupt unless the system first wakes up?

Conversely, what happens if the PM core has just started a system suspend? Does locking the wakelock force the suspend to be aborted?

Quoted 7 lines

- The keypad-scan code detects a key change and reports it to the input-event driver.
- The input-event driver sees the key change, enqueues an event, and locks the input-event-queue wakelock.
- The keypad-scan code detects that no keys are held and unlocks the keypad-scan wakelock.

What use is the keypad-scan wakelock? Isn't the fact that the keypad driver's interrupt handler is running already sufficient to prevent or delay a system suspend?

Quoted 4 lines

- The user-space input-event thread returns from select/poll, locks the process-input-events wakelock and then calls read in the input-event device.
- The input-event driver dequeues the key-event and, since the queue is now empty, it unlocks the input-event-queue wakelock.

Does the input-event-queue wakelock always prevent the system from suspending whenever the input queue is nonempty?

Does that mean if I
type ahead while a program is running, I can't suspend the computer until the program processes the keystrokes?

Does the wakelock mechanism distinguish between suspend or power-state transitions that happen automatically and transitions requested directly by userspace?

This would be a little more understandable if
the wakelocks only prevent the system from suspending itself and don't prevent me from suspending the system.

Quoted 4 lines

- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

This makes no sense. If the system wasn't asleep to begin with, how could the key wake it up? And if the system _was_ asleep to begin with, how could all of this happen without waking the system up?

User-space API
==============

Write "lockname" or "lockname timeout" to /sys/power/wake_lock lock and if needed create a wakelock. The timeout here is specified nanoseconds. Write "lockname" to /sys/power/wake_unlock to unlock a user wakelock.

Do not use randomly generated wakelock names as there is no api to free a user-space wakelock.

Quoted 5 lines

Quoted 4 lines

- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

Quoted 3 lines

This makes no sense. If the system wasn't asleep to begin with, how could the key wake it up? And if the system _was_ asleep to begin with, how could all of this happen without waking the system up?

What I mean here is that the screen turns on and the system does not immediately go back to sleep. The user-space framework has its own idea of whether the system is awake or not. I can change this to "fully wake up" or "turn on the screen".

Quoted 8 lines

Quoted 7 lines

Quoted 3 lines

- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

This makes no sense. If the system wasn't asleep to begin with, how could the key wake it up? And if the system _was_ asleep to begin with, how could all of this happen without waking the system up?

Quoted 4 lines

What I mean here is that the screen turns on and the system does not immediately go back to sleep. The user-space framework has its own idea of whether the system is awake or not. I can change this to "fully wake up" or "turn on the screen".

"turn on the screen", please. (But I still don't quite get it; screen should be at full control of userspace, so why is kernel interaction needed?) Pavel

Quoted 13 lines · Pavel Machek

Quoted 12 lines

Quoted 7 lines

Quoted 3 lines

- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

This makes no sense. If the system wasn't asleep to begin with, how could the key wake it up? And if the system _was_ asleep to begin with, how could all of this happen without waking the system up?

What I mean here is that the screen turns on and the system does not immediately go back to sleep. The user-space framework has its own idea of whether the system is awake or not. I can change this to "fully wake up" or "turn on the screen".

Quoted 4 lines

"turn on the screen", please. (But I still don't quite get it; screen should be at full control of userspace, so why is kernel interaction needed?) Pavel

Turning on the screen is only on thing userspace can do. What exactly happens is beyon the scope of the kernel interface.
The right term is probably something like "break out of auto-suspend" or "wake from auto suspend".

Quoted 2 lines

Does the input-event-queue wakelock always prevent the system from suspending whenever the input queue is nonempty?

Yes.

Quoted 3 lines

Does that mean if I
type ahead while a program is running, I can't suspend the computer until the program processes the keystrokes?

The actual suspend will not happen until all the keys are processed, but user-space can turn the screen off at any time.

Quoted 3 lines

Does the wakelock mechanism distinguish between suspend or power-state transitions that happen automatically and transitions requested directly by userspace?

No.

When the user decides to suspend, we use the early-suspend api to tell the kernel to turn of the screen and possibly some other devices. Wakelocks are useful without early-suspend, but it must always enter suspend when the last wakelock is unlocked.

Quoted 4 lines

Quoted 3 lines

- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

Quoted 3 lines

This makes no sense. If the system wasn't asleep to begin with, how could the key wake it up? And if the system _was_ asleep to begin with, how could all of this happen without waking the system up?

What I mean here is that the screen turns on and the system does not immediately go back to sleep. The user-space framework has its own idea of whether the system is awake or not. I can change this to "fully wake up" or "turn on the screen".

Personally, I think we need to be able to suspend computers even when there are some unconsumed type-ahead characters in the input buffer. But that's merely an implementation detail.

Quoted 5 lines

Quoted 3 lines

Does the wakelock mechanism distinguish between suspend or power-state transitions that happen automatically and transitions requested directly by userspace?

No.

And I think this is a big mistake. It makes sense to have locks for blocking auto suspend, but it does not make sense to prevent the user from putting his own computer to sleep.

For example: Suppose some program happens to hold a wakelock, perhaps because of a simple bug, when the user closes the laptop lid and throws the laptop into a backpack. We don't want the computer to remain awake under those circumstances!

In fact, it would be a good idea to inform drivers (by passing a particular pm_message_t argument to the suspend method) whether a particular suspend was initiated by the user or as an auto suspend. In some cases a driver might very well want to allow one while preventing the other.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

Quoted 8 lines

Quoted 3 lines

This makes no sense. If the system wasn't asleep to begin with, how could the key wake it up? And if the system _was_ asleep to begin with, how could all of this happen without waking the system up?

What I mean here is that the screen turns on and the system does not immediately go back to sleep. The user-space framework has its own idea of whether the system is awake or not. I can change this to "fully wake up" or "turn on the screen".

So what this example really shows is how wakelocks can be used to prevent auto suspend from kicking back in the moment a keystroke is received, before userspace has even had a chance to decide whether or not to turn auto suspend off. That's how you should describe it -- not as a way of preventing keystrokes from waking the system up.

In fact, you have made the discussion very confusing by using the same terms ("suspend", "wake up", and so) for at least three different
concepts: full system suspend, early-suspend, and this new userspace framework's idea of suspend. Not to mention this other notion of turning off the screen (and perhaps a few other devices) while leaving the system as a whole running. In the future, please use different words when talking about different concepts.

Quoted 3 lines · Alan Stern

Personally, I think we need to be able to suspend computers even when there are some unconsumed type-ahead characters in the input buffer. But that's merely an implementation detail.

For us, the key that will turn the screen back on could be in this buffer.

Quoted 3 lines

And I think this is a big mistake. It makes sense to have locks for blocking auto suspend, but it does not make sense to prevent the user from putting his own computer to sleep.

If we go to sleep while the keypad wakelock is locked, then the keypad can no longer wake the system up. Note that this is specific to a keypad driver that scans the keypad matrix in software. A keyboard that generates an interrupt on every key change does not need its own wakelock.

Also, consider the case where the user presses the power button to go to sleep. Before this sleep request has finished a phone call comes in. The driver gets an interrupt, enqueues the message and locks a wakelock to make sure user-space gets a chance to process the message. If we ignore this wakelock, the phone will either not ring at all, or it will ring later when the device wakes up for some other reason.

There is a class of applications where we do want the behaviour you describe, but so far all of them also require the screen to stay on.

This is handled entirely by our user-space framework which also has other options (like keeping the keypad backlight on).

Quoted 4 lines

For example: Suppose some program happens to hold a wakelock, perhaps because of a simple bug, when the user closes the laptop lid and throws the laptop into a backpack. We don't want the computer to remain awake under those circumstances!

If the program hold the wakelock because of a bug we don't want the computer on, but if it operating correctly we do.

Since we don't have
a good way to detect if the program locked the wakelock because of a bug, we assume it is correct and honor the request. We have debugging interfaces to report how often and for how long wakelocks are locked. We also do not allow applications to use wakelocks unless they have the required permission.

Quoted 5 lines

In fact, it would be a good idea to inform drivers (by passing a particular pm_message_t argument to the suspend method) whether a particular suspend was initiated by the user or as an auto suspend. In some cases a driver might very well want to allow one while preventing the other.

I'm not sure this would be useful. We don't have any drivers that only need their wakelock to prevent auto suspend.

And, every pm_suspend
call is the result of unlocking the last wakelock.

Quoted 5 lines

So what this example really shows is how wakelocks can be used to prevent auto suspend from kicking back in the moment a keystroke is received, before userspace has even had a chance to decide whether or not to turn auto suspend off. That's how you should describe it -- not as a way of preventing keystrokes from waking the system up.

I was trying to show that user-space decides which keys allow the system to wake up. From the kernels point of view, every key causes a wakeup, but if user-space decides that the key should not wake the system, the system will go back to sleep as soon as possible (when all wakelocks are unlocked).

The user-space notion of suspend matches the early-suspend state.

I
consider early-suspend another stage, not a different concept. The difference between early-suspend and suspend is similar to the difference between device suspend and sysdev suspend. What would you call the the first stage of suspend that we have added?

Quoted 6 lines · Arve Hjønnevåg

Quoted 3 lines · Alan Stern

Personally, I think we need to be able to suspend computers even when there are some unconsumed type-ahead characters in the input buffer. But that's merely an implementation detail.

For us, the key that will turn the screen back on could be in this buffer.

Why do you have this fixation on the screen? Forget about the screen and consider the system as a whole.

If the keyboard is enabled for wakeup, then typing a key _will_ wake the system up from suspend -- provided the key was typed after the system went to sleep. It's silly to think that a key which was typed before the computer was suspended should cause it to wake up.

Quoted 5 lines

If we go to sleep while the keypad wakelock is locked, then the keypad can no longer wake the system up. Note that this is specific to a keypad driver that scans the keypad matrix in software. A keyboard that generates an interrupt on every key change does not need its own wakelock.

Are you sure about this? IIRC, you said earlier that your keyboard generates an interrupt on a key press only when no other keys are already pressed. Okay -- so imagine the system suspends while a key is pressed. Pressing another key won't generate an interrupt and hence won't wake up the system. But releasing all the keys and then pressing one _will_ generate an interrupt and so will wake up the system. I don't see any problem with this.

Quoted 6 lines

Also, consider the case where the user presses the power button to go to sleep. Before this sleep request has finished a phone call comes in. The driver gets an interrupt, enqueues the message and locks a wakelock to make sure user-space gets a chance to process the message. If we ignore this wakelock, the phone will either not ring at all, or it will ring later when the device wakes up for some other reason.

For situations like this, the driver can simply refuse to suspend. You don't need to use a wakelock.

In fact, if you did use a wakelock the behavior would be very strange. The user presses the power button, an instant later a call comes in, the device doesn't go to sleep, the user answers the call, and as soon as he hangs up (perhaps 10 minutes later) the wakelock is released and the device immediately goes to sleep! Not what the user would expect.

Quoted 3 lines

There is a class of applications where we do want the behaviour you describe, but so far all of them also require the screen to stay on.

Again this fixation with the screen. Forget about the screen!

Quoted 10 lines

This is handled entirely by our user-space framework which also has other options (like keeping the keypad backlight on).

Quoted 4 lines

For example: Suppose some program happens to hold a wakelock, perhaps because of a simple bug, when the user closes the laptop lid and throws the laptop into a backpack. We don't want the computer to remain awake under those circumstances!

If the program hold the wakelock because of a bug we don't want the computer on, but if it operating correctly we do.

_I_ don't. I want my device to suspend itself when I tell it to. Nothing is more annoying than a machine that doesn't turn itself off when told to do so.

Quoted 6 lines

Since we don't have
a good way to detect if the program locked the wakelock because of a bug, we assume it is correct and honor the request. We have debugging interfaces to report how often and for how long wakelocks are locked. We also do not allow applications to use wakelocks unless they have the required permission.

I admit that in a properly-operating system there won't be any wakelocks held because of bugs. But there might be wakelocks held for other reasons, and I don't want _them_ to interfere when I suspend the machine either.

Quoted 2 lines

And, every pm_suspend
call is the result of unlocking the last wakelock.

Not true. What if all the wakelocks are already unlocked when the user writes "mem" to /sys/power/state?

Quoted 11 lines

Quoted 5 lines

So what this example really shows is how wakelocks can be used to prevent auto suspend from kicking back in the moment a keystroke is received, before userspace has even had a chance to decide whether or not to turn auto suspend off. That's how you should describe it -- not as a way of preventing keystrokes from waking the system up.

I was trying to show that user-space decides which keys allow the system to wake up. From the kernels point of view, every key causes a wakeup, but if user-space decides that the key should not wake the system, the system will go back to sleep as soon as possible (when all wakelocks are unlocked).

This paragraph is an excellent example of the muddiness of your thinking. Userspace does _not_ decide which keys allow the system to wake up. _All_ keys cause the system to wake up; userspace then decides which ones should cause the system to go right back into suspend.

But you don't need wakelocks to do this. You can get the same effect without them, just by running a program that writes "mem" (not "auto-mem"!) to /sys/power/state whenever it sees a keystroke it doesn't like. So this example does not illustrate the power of wakelocks.

Quoted 1 line

The user-space notion of suspend matches the early-suspend state.

Then call it "early-suspend"! Don't call it "suspend" or "the user-space notion of suspend".

Quoted 5 lines

I
consider early-suspend another stage, not a different concept. The difference between early-suspend and suspend is similar to the difference between device suspend and sysdev suspend. What would you call the the first stage of suspend that we have added?

"Early-suspend" is an okay name. However I have the impression that you want to prolong the early-suspend stage, and sometimes even go back to full power directly from early-suspend. There's nothing wrong with that; just make it clear that this is what you're doing.

In fact, I get the impression that much of what you're talking about has to do with providing ways to short-circuit a complete suspend and go directly from early-suspend back to full power.

Quoted 6 lines

Also, consider the case where the user presses the power button to go to sleep. Before this sleep request has finished a phone call comes in. The driver gets an interrupt, enqueues the message and locks a wakelock to make sure user-space gets a chance to process the message. If we ignore this wakelock, the phone will either not ring at all, or it will ring later when the device wakes up for some other reason.

For situations like this, the driver can simply refuse to suspend.  You don't need to use a wakelock.

In fact, if you did use a wakelock the behavior would be very strange. The user presses the power button, an instant later a call comes in, the device doesn't go to sleep, the user answers the call, and as soon as he hangs up (perhaps 10 minutes later) the wakelock is released and the device immediately goes to sleep!  Not what the user would expect.

Hi Alan,
we have had a (userspace) wake-lock implementation on our handyPC devices for a couple of years now. So maybe I can shed some light.

The above quote underlines pretty well, where Arve's and your ideas of eraly-suspend and wake-locks diverge. And why you are missunderstanding each other.
Arve is always talking about "blanking the screen" because that's what the users sees. From the user's perspective the device is "suspended" as soon as his user interfaces vanishes. That's probably also why his notions of "suspend" and "wake" are not alway following a strict definition.

If the device stays blanked while the user has his 10 min phone conversation, then he won't even notice wether the device suspends or not after the call. This is the idea. The user does not care for anything they can't see.

Arve is not talking about a laptop that needs to sleep befor it's ventilation slot are covered. He is talking about a phone that could well do with only blanking it's screen. Except it want's to save battery when ever possible.

Quoted 4 lines · Uli Luckas

Hi Alan,
we have had a (userspace) wake-lock implementation on our handyPC devices for a couple of years now. So maybe I can shed some light.

Quoted 8 lines

The above quote underlines pretty well, where Arve's and your ideas of eraly-suspend and wake-locks diverge. And why you are missunderstanding each other.
Arve is always talking about "blanking the screen" because that's what the users sees. From the user's perspective the device is "suspended" as soon as his user interfaces vanishes. That's probably also why his notions of "suspend" and "wake" are not alway following a strict definition.

And that's partly why I have been complaining about the things he writes. To a kernel programmer, "suspend" has a very specific meaning, quite different from what it might mean to a user. When Arve posts on a kernel-oriented mailing list, he should use such words in a way his readers will understand.

Quoted 9 lines

If the device stays blanked while the user has his 10 min phone conversation, then he won't even notice wether the device suspends or not after the call. This is the idea. The user does not care for anything they can't see.

Arve is not talking about a laptop that needs to sleep befor it's ventilation slot are covered. He is talking about a phone that could well do with only blanking it's screen. Except it want's to save battery when ever possible.

The problem is that he's talking about making changes to a kernel that will be installed in all sorts of machines, from phones all the way up to supercomputers. When you do this, you have to broaden your point of view -- your code has to run correctly in all of these settings.

/sys/power/state"

Well, it should not interfere with any of these settings. And I think it is understood by now that we has to take back the semantic change of "echo mem

Quoted 1 line

/sys/power/state"

On the other hand, I think it is quite reasonable to have aditional suspend mechanisms on a phone then you have on a super computer. Obviously you don't want the supercomputer to suspend everytime nobody is watching :-)

Quoted 6 lines

The problem is that he's talking about making changes to a kernel that will be installed in all sorts of machines, from phones all the way up to supercomputers. When you do this, you have to broaden your point of view -- your code has to run correctly in all of these settings.

Well, it should not interfere with any of these settings. And I think it is understood by now that we has to take back the semantic change of "echo mem

Quoted 1 line

/sys/power/state"

On the other hand, I think it is quite reasonable to have aditional suspend mechanisms on a phone then you have on a super computer. Obviously you don't want the supercomputer to suspend everytime nobody is watching :-)

Quoted 5 lines

Quoted 3 lines

Does the wakelock mechanism distinguish between suspend or power-state transitions that happen automatically and transitions requested directly by userspace?

No.

And I think this is a big mistake. It makes sense to have locks for blocking auto suspend, but it does not make sense to prevent the user from putting his own computer to sleep.

For example: Suppose some program happens to hold a wakelock, perhaps because of a simple bug, when the user closes the laptop lid and throws the laptop into a backpack. We don't want the computer to remain awake under those circumstances!

[Alan Stern <[email protected]>]

Quoted 10 lines

Quoted 5 lines

Quoted 3 lines

Does the wakelock mechanism distinguish between suspend or power-state transitions that happen automatically and transitions requested directly by userspace?

No.

And I think this is a big mistake. It makes sense to have locks for blocking auto suspend, but it does not make sense to prevent the user from putting his own computer to sleep.

Quoted 4 lines

For example: Suppose some program happens to hold a wakelock, perhaps because of a simple bug, when the user closes the laptop lid and throws the laptop into a backpack. We don't want the computer to remain awake under those circumstances!

It depends on the particular "computer" and the problem you're solving.

Imagine the computer in question is a cellphone which is going to need to wake up when a call comes in to do traditional cellphone things, like ring, bring up the incall UI (so the user can answer/cancel), etc.

Or perhaps it's an always-connected data device that might get remote messages (IM notifications, contacts/email sync, etc) over the network while it's "asleep" that need some processing.

Bad usage of wakelocks can certainly lead to poor battery life, but there are definitely situations where you might want to operate in a mode where the user considers the device "asleep" but it may still wake up to handle certain tasks.

Quoted 11 lines · Brian Swetland

[Alan Stern <[email protected]>]

Quoted 10 lines

Quoted 5 lines

Quoted 3 lines

Does the wakelock mechanism distinguish between suspend or power-state transitions that happen automatically and transitions requested directly by userspace?

No.

And I think this is a big mistake. It makes sense to have locks for blocking auto suspend, but it does not make sense to prevent the user from putting his own computer to sleep.

Quoted 6 lines

Quoted 4 lines

For example: Suppose some program happens to hold a wakelock, perhaps because of a simple bug, when the user closes the laptop lid and throws the laptop into a backpack. We don't want the computer to remain awake under those circumstances!

It depends on the particular "computer" and the problem you're solving.

I disagree.

Quoted 3 lines

Imagine the computer in question is a cellphone which is going to need to wake up when a call comes in to do traditional cellphone things, like ring, bring up the incall UI (so the user can answer/cancel), etc.

Yes. So what? Nothing I said prevents the computer from waking up when a call comes in. What I said was that when the user tells the computer to suspend (e.g., by writing "mem" to /sys/power/state), the computer should suspend even if some wakelocks are still locked.

Quoted 3 lines

Or perhaps it's an always-connected data device that might get remote messages (IM notifications, contacts/email sync, etc) over the network while it's "asleep" that need some processing.

By "asleep", do you mean something other than suspended? If you do then you have misunderstood me. I'm talking about a true suspend -- that is, the suspend routines in drivers/base/power/main.c have run, everything is in a low-power state or turned off, and the CPU isn't running.

Obviously the computer can't do any processing when it is suspended. The only thing it can do is resume. And a resume can be initiated by a wide variety of signals, including such things as receipt of a network packet or a phone call.

Quoted 4 lines

Bad usage of wakelocks can certainly lead to poor battery life, but there are definitely situations where you might want to operate in a mode where the user considers the device "asleep" but it may still wake up to handle certain tasks.

I don't care what the user thinks; I care about what the kernel actually does. If the user wants to delude himself into thinking the computer is "asleep" while the kernel is still running, that's his problem.

Well, I think that sleep states are not really useful in cell phones. Useful
is the ability to put all devices into low power states separately and as

needed (eg. after a period of inactivity). IOW, the system as a whole is
in the working state, but some parts of the hardware may be in low power states
(even all of the I/O devices may be in low power states). That may very well
look "asleep" from the user point of view, but it is not a sleep state.

However, I think that what we are used to call a sleep (or suspend) state is really a power off state for cell phone people.

Sleep states (suspend to RAM, hibernation) are the states of the whole system in which no instructions are executed by the processor(s). The difference between a sleep state and the power off state is that in a sleep state we have some application context saved (in memory or in a storage device) and (in principle) after the system goes back to the working state, the applications can continue doing do whatever they had been doing before the system was put into the sleep state.

Well, I think that sleep states are not really useful in cell phones. Useful is the ability to put all devices into low power states separately and as needed (eg. after a period of inactivity). IOW, the system as a whole is in the working state, but some parts of the hardware may be in low power states (even all of the I/O devices may be in low power states). That may very well look "asleep" from the user point of view, but it is not a sleep state.

However, I think that what we are used to call a sleep (or suspend) state is really a power off state for cell phone people. So lets define what we're talking about.

Sleep states (suspend to RAM, hibernation) are the states of the whole system in which no instructions are executed by the processor(s). The difference

between a sleep state and the power off state is that in a sleep state we have some application context saved (in memory or in a storage device) and (in principle) after the system goes back to the working state, the applications can continue doing do whatever they had been doing before the system was put into the sleep state.

If instructions are executed by the processor(s), the system is in the working state.

Well, I think that sleep states are not really useful in cell phones. Useful is the ability to put all devices into low power states separately and as needed (eg. after a period of inactivity). IOW, the system as a whole is

Quoted 3 lines · Brian Swetland

Imagine the computer in question is a cellphone which is going to need to wake up when a call comes in to do traditional cellphone things, like ring, bring up the incall UI (so the user can answer/cancel), etc.

Yes. So what? Nothing I said prevents the computer from waking up when a call comes in. What I said was that when the user tells the computer to suspend (e.g., by writing "mem" to /sys/power/state), the computer should suspend even if some wakelocks are still locked.

Quoted 9 lines · Alan Stern

Quoted 3 lines · Brian Swetland

Imagine the computer in question is a cellphone which is going to need to wake up when a call comes in to do traditional cellphone things, like ring, bring up the incall UI (so the user can answer/cancel), etc.

Yes. So what? Nothing I said prevents the computer from waking up when a call comes in. What I said was that when the user tells the computer to suspend (e.g., by writing "mem" to /sys/power/state), the computer should suspend even if some wakelocks are still locked.

But this could prevent the phone from ringing. What if the user-space code that is responsible for playing the ringtone has been notified that a call is coming in and starts reading the audio file with the ringtone. At the same, the user, unaware that someone is calling, presses the power button. If we ignore the wakelock in this situation, the phone will not ring.

Quoted 6 lines · Arve Hjønnevåg

But this could prevent the phone from ringing. What if the user-space code that is responsible for playing the ringtone has been notified that a call is coming in and starts reading the audio file with the ringtone. At the same, the user, unaware that someone is calling, presses the power button. If we ignore the wakelock in this situation, the phone will not ring.

What if the user decides to power off the phone and a call comes in at the same time?

Quoted 8 lines · Rafael J. Wysocki

Quoted 6 lines · Arve Hjønnevåg

But this could prevent the phone from ringing. What if the user-space code that is responsible for playing the ringtone has been notified that a call is coming in and starts reading the audio file with the ringtone. At the same, the user, unaware that someone is calling, presses the power button. If we ignore the wakelock in this situation, the phone will not ring.

Quoted 2 lines

What if the user decides to power off the phone and a call comes in at the same time?

If you are talking about a shutdown, not sleep, then the phone just turns off. The phone is not expected to ring when it is turned off so there is no point in delaying shutdown.

If the user forcibly puts the device into suspend, it's very much like powering off. The kernel shouldn't prevent that from happening unless in error conditions.

If incoming calls are supposed to wake up the system, then there are two possibilities:
- the already started suspend sequence may be aborted and the system may be put into the low power state,

- the system may be suspended and then immediately woken up.

Quoted 3 lines · Rafael J. Wysocki

If the user forcibly puts the device into suspend, it's very much like powering off. The kernel shouldn't prevent that from happening unless in error conditions.

No, when the phone is powered off, it is not expected to ring. When it is suspended it is expected to ring.

Quoted 4 lines

If incoming calls are supposed to wake up the system, then there are two possibilities:
- the already started suspend sequence may be aborted and the system may be put into the low power state,

I assume you mean high power state not low power state, or does low power state mean early-suspend state. If so, locking a wakelock will accomplish this.

Quoted 1 line

- the system may be suspended and then immediately woken up.

If you mean this as a general strategy, and not a specific outcome, then it does not always work (for the reasons I have already stated).

Quoted 8 lines

Quoted 4 lines

If incoming calls are supposed to wake up the system, then there are two possibilities:
- the already started suspend sequence may be aborted and the system may be put into the low power state,

I assume you mean high power state not low power state, or does low power state mean early-suspend state. If so, locking a wakelock will accomplish this.

Actually, I meant the working state. Aborting suspend sequence always means go back to the working state.

Also, I think the device that detected the incoming call should abort the suspend sequence by refusing to suspend.

Quoted 2 lines

Quoted 1 line

- the system may be suspended and then immediately woken up.

Quoted 2 lines

If you mean this as a general strategy, and not a specific outcome, then it does not always work (for the reasons I have already stated).

I meant a specific outcome.

It may be impossible to abort suspend if the call comes in sufficiently late.

Quoted 22 lines · Rafael J. Wysocki

Quoted 8 lines

Quoted 4 lines

If incoming calls are supposed to wake up the system, then there are two possibilities:
- the already started suspend sequence may be aborted and the system may be put into the low power state,

I assume you mean high power state not low power state, or does low power state mean early-suspend state. If so, locking a wakelock will accomplish this.

Actually, I meant the working state. Aborting suspend sequence always means go back to the working state.

Also, I think the device that detected the incoming call should abort the suspend sequence by refusing to suspend.

Quoted 4 lines

Quoted 1 line

- the system may be suspended and then immediately woken up.

If you mean this as a general strategy, and not a specific outcome, then it does not always work (for the reasons I have already stated).

I meant a specific outcome.

Quoted 2 lines

It may be impossible to abort suspend if the call comes in sufficiently late.

In that case, why are you against using wakelocks to abort the suspend sequence? It covers the case where the driver knows that a call is coming in, without any confusion about when the abort condition clears. And, it avoids the overhead of freezing every process for an operation that is doomed to fail.

Quoted 5 lines

In that case, why are you against using wakelocks to abort the suspend sequence? It covers the case where the driver knows that a call is coming in, without any confusion about when the abort condition clears. And, it avoids the overhead of freezing every process for an operation that is doomed to fail.

I'm not really against (yet), I'm only trying to clearly understand the benefit.

The problem pointed out by Alan is real, the user expects the system to suspend
as soon as the button is pressed and wakelocks may get in the way.

Your example is also good, but I think the problem in your example (phone call coming in while suspending) may be resolved without wakelocks. Moreover, it is a general problem of a wake-up event coming in while suspending and it requires a general solution independent of wakelocks.

Quoted 5 lines

In that case, why are you against using wakelocks to abort the suspend sequence? It covers the case where the driver knows that a call is coming in, without any confusion about when the abort condition clears. And, it avoids the overhead of freezing every process for an operation that is doomed to fail.

I'm not really against (yet), I'm only trying to clearly understand the benefit.

The problem pointed out by Alan is real, the user expects the system to suspend as soon as the button is pressed and wakelocks may get in the way.

Your example is also good, but I think the problem in your example (phone call coming in while suspending) may be resolved without wakelocks. Moreover, it is a general problem of a wake-up event coming in while suspending and it requires a general solution independent of wakelocks.

Early-suspend seems to be a completely different matter. In fact it isn't a suspend state at all, as far as I understand it. It's more like what you get simply by doing a runtime suspend on some collection of devices. I don't see that the kernel needs to treat it as a special state, and in might be possible to have a user program manage the whole thing -- provided the drivers in question implement runtime power management (as USB has done).

Early-suspend seems to be a completely different matter.  In fact it isn't a suspend state at all, as far as I understand it.  It's more like what you get simply by doing a runtime suspend on some collection of devices.  I don't see that the kernel needs to treat it as a special state, and in might be possible to have a user program manage the whole thing -- provided the drivers in question implement runtime power management (as USB has done).

Alan Stern

Quoted 8 lines · Alan Stern

Early-suspend seems to be a completely different matter.  In fact it isn't a suspend state at all, as far as I understand it.  It's more like what you get simply by doing a runtime suspend on some collection of devices.  I don't see that the kernel needs to treat it as a special state, and in might be possible to have a user program manage the whole thing -- provided the drivers in question implement runtime power management (as USB has done).

Quoted 1 line

Alan Stern

Except you always want early-suspend and auto-suspend at the same time. The idea is, if all display of system states is off (early-suspend), we can enable or disable the cpu at will (auto-suspend) because nobody will notice.

Quoted 9 lines · Uli Luckas

Quoted 8 lines · Alan Stern

Early-suspend seems to be a completely different matter.  In fact it isn't a suspend state at all, as far as I understand it.  It's more like what you get simply by doing a runtime suspend on some collection of devices.  I don't see that the kernel needs to treat it as a special state, and in might be possible to have a user program manage the whole thing -- provided the drivers in question implement runtime power management (as USB has done).

Quoted 6 lines

Quoted 1 line

Alan Stern

Except you always want early-suspend and auto-suspend at the same time. The idea is, if all display of system states is off (early-suspend), we can enable or disable the cpu at will (auto-suspend) because nobody will notice.

Why should the kernel have to get involved? Why can't userspace manage both early-suspend and auto-suspend?

That is, consider the following: Userspace initiates an early-suspend by using a runtime PM interface to turn off the screen and some other devices. After a short time, if they are still off, then userspace can initiate an auto-suspend by writing "auto-mem" to /sys/power/state.

All the kernel would need to know is the difference between auto-suspend and normal suspend: one respects wakelocks and the other doesn't.

Quoted 9 lines · Uli Luckas

Quoted 8 lines · Alan Stern

Early-suspend seems to be a completely different matter. In fact it isn't a suspend state at all, as far as I understand it. It's more like what you get simply by doing a runtime suspend on some collection of devices. I don't see that the kernel needs to treat it as a special state, and in might be possible to have a user program manage the whole thing -- provided the drivers in question implement runtime power management (as USB has done).

Quoted 5 lines

Quoted 1 line

Alan Stern

Except you always want early-suspend and auto-suspend at the same time. The idea is, if all display of system states is off (early-suspend), we can enable or disable the cpu at will (auto-suspend) because nobody will notice.

Why should the kernel have to get involved? Why can't userspace manage both early-suspend and auto-suspend?

That is, consider the following: Userspace initiates an early-suspend by using a runtime PM interface to turn off the screen and some other devices. After a short time, if they are still off, then userspace can initiate an auto-suspend by writing "auto-mem" to /sys/power/state.

All the kernel would need to know is the difference between auto-suspend and normal suspend: one respects wakelocks and the other doesn't.

It sounds to me like all of this stuff is just power management of individual devices, which should be done through the sysfs interface and completely unrelated to /sys/power/state.

I'm putting the talk about
suspending the CPU in this box too because it sounds like the desire is to stop the CPU without necessarily suspending other devices such as transmitters - sort of a CPU freq state where the frequency is 0.

That said, if suspend to ram is what they really want for 'auto-mem', what you're suggesting sounds good to me.

Quoted 3 lines · Nigel Cunningham

It sounds to me like all of this stuff is just power management of individual devices, which should be done through the sysfs interface and completely unrelated to /sys/power/state.

It is easier for us to add a hook to the individual drivers than to maintain a list of devices in user-space. Also, last time I checked, the only way to disable individual devices was through a deprecated interface. Is there a new way to do this?

Quoted 4 lines

I'm putting the talk about
suspending the CPU in this box too because it sounds like the desire is to stop the CPU without necessarily suspending other devices such as transmitters - sort of a CPU freq state where the frequency is 0.

Is this different from idle?

Quoted 2 lines

That said, if suspend to ram is what they really want for 'auto-mem', what you're suggesting sounds good to me.

Suspend gives us two advantages over idle. All threads are frozen which means that an app that is using too much cpu time no longer drains the battery. And, the monotonic clock stops.

Quoted 4 lines

It is easier for us to add a hook to the individual drivers than to maintain a list of devices in user-space. Also, last time I checked, the only way to disable individual devices was through a deprecated interface. Is there a new way to do this?

Not as far as I know, but I understood that we weren't focusing on what currently exists, but on what ought to exist to properly support what you're after, in a generic enough way to be useful to others as well.

Well, I'm imagining a state that is more than just idle - where, as you say, processes don't run until some sort of wakeup event occurs.

Quoted 3 lines

Suspend gives us two advantages over idle. All threads are frozen which means that an app that is using too much cpu time no longer drains the battery. And, the monotonic clock stops.

Do you want to leave any devices on while in this state? If not, okay - suspend to ram sounds right. If yes, I think you want to take leave /sys/power/disk alone and go along the lines of run-time power management instead.

Quoted 3 lines · <[email protected]> wrote:

It sounds to me like all of this stuff is just power management of individual devices, which should be done through the sysfs interface and completely unrelated to /sys/power/state.

It is easier for us to add a hook to the individual drivers than to maintain a list of devices in user-space. Also, last time I checked, the only way to disable individual devices was through a deprecated interface. Is there a new way to do this?

Quoted 2 lines

That said, if suspend to ram is what they really want for 'auto-mem', what you're suggesting sounds good to me.

Suspend gives us two advantages over idle. All threads are frozen which means that an app that is using too much cpu time no longer drains the battery. And, the monotonic clock stops.

Quoted 3 lines · Uli Luckas

Except you always want early-suspend and auto-suspend at the same time. The idea is, if all display of system states is off (early-suspend), we can enable or disable the cpu at will (auto-suspend) because nobody will notice.

Why should the kernel have to get involved? Why can't userspace manage both early-suspend and auto-suspend?

That is, consider the following: Userspace initiates an early-suspend by using a runtime PM interface to turn off the screen and some other devices. After a short time, if they are still off, then userspace can initiate an auto-suspend by writing "auto-mem" to /sys/power/state.

All the kernel would need to know is the difference between auto-suspend and normal suspend: one respects wakelocks and the other doesn't.

Quoted 7 lines · Alan Stern

Quoted 3 lines · Uli Luckas

Except you always want early-suspend and auto-suspend at the same time. The idea is, if all display of system states is off (early-suspend), we can enable or disable the cpu at will (auto-suspend) because nobody will notice.

Why should the kernel have to get involved? Why can't userspace manage both early-suspend and auto-suspend?

The kernel does not need to be involved in early-suspend. We use early-suspend as a simple way to shut down the framebuffer and some input devices.
If by auto-suspend you mean suspend after user inactivity (usually after a number of seconds or minutes), then the kernel does not need to be involved, but if you mean suspending when all wakelocks are unlocked, the kernel needs to be involved to avoid delays. If the last wakelock to be unlocked is a kernel wakelock, then user-space would not know that it needs to re-attempt suspend.

Quoted 4 lines

That is, consider the following: Userspace initiates an early-suspend by using a runtime PM interface to turn off the screen and some other devices. After a short time, if they are still off, then userspace can initiate an auto-suspend by writing "auto-mem" to /sys/power/state.

Why do you want a delay?

Also, what do you mean by a runtime PM interface?

Quoted 3 lines

All the kernel would need to know is the difference between auto-suspend and normal suspend: one respects wakelocks and the other doesn't.

If by normal suspend you mean what is supported in the kernel now, then OK. We can support existing userspace code by ignoring wakelocks. My intention was that you only enable the WAKELOCK config option when using it, but I agree that it is better to allow the kernel to be built with support for both modes.

What do you think should happen if user-space tries to use both interfaces?

If you'd like a way for the kernel to communicate to userspace that the last wakelock has been unlocked, you could use a signal or a select. But the simplest way would be to make a process block on reading a sysfs file until the last wakelock is released.

Quoted 1 line

Also, what do you mean by a runtime PM interface?

I'm making a distinction between system PM and runtime (also known as dynamic) PM. With system PM the entire system goes into a low-power state -- that's what we mean when we talk about suspend or hibernation. With runtime PM the system as a whole remains running while selected devices are individually put into a low-power state.

For example, right now Linux will put a USB host controller into a low-power state if no USB devices are plugged into it. This runtime PM interface is described in Documentation/usb/power-management.txt. You might want to use some of those mechanisms for controlling your devices.

For example, if one process tries to start an auto-suspend, and at the same time another process writes "mem" to /sys/power/state? Then the second process should take precedence and the system should go into suspend. When it wakes up again, the first process would still be waiting for an auto-suspend to occur. I suppose the details don't matter much because it's not likely to crop up often.

Quoted 8 lines

Quoted 1 line

Also, what do you mean by a runtime PM interface?

I'm making a distinction between system PM and runtime (also known as dynamic) PM. With system PM the entire system goes into a low-power state -- that's what we mean when we talk about suspend or hibernation. With runtime PM the system as a whole remains running while selected devices are individually put into a low-power state.

Quoted 5 lines

For example, right now Linux will put a USB host controller into a low-power state if no USB devices are plugged into it. This runtime PM interface is described in Documentation/usb/power-management.txt. You might want to use some of those mechanisms for controlling your devices.

OK, but I don't think this affects our use of wakelocks.

I'll make a change to make any write to /sys/power/state disable wakelocks. I'll probably also add a config option to remove /sys/power/state.

Before I post another patch series I have a few questions:
- Should I merge the wakelock and early-suspend api patches with their implementations? (I initially implemented the api on top of the old android_power driver, but we not longer use this)

- Once wakelocks are disabled by writing to /sys/power/state, is there any demand for re-enabling wakelock support?

- Are there any objections to using /sys/power/request_state to specify the state to enter when all wakelocks unlocked.

Quoted 7 lines

For example, if one process tries to start an auto-suspend, and at the same time another process writes "mem" to /sys/power/state? Then the second process should take precedence and the system should go into suspend. When it wakes up again, the first process would still be waiting for an auto-suspend to occur. I suppose the details don't matter much because it's not likely to crop up often.

I'll make a change to make any write to /sys/power/state disable wakelocks. I'll probably also add a config option to remove /sys/power/state.

Before I post another patch series I have a few questions:
- Should I merge the wakelock and early-suspend api patches with their implementations? (I initially implemented the api on top of the old android_power driver, but we not longer use this)

- Once wakelocks are disabled by writing to /sys/power/state, is there any demand for re-enabling wakelock support?

Quoted 11 lines · Arve Hj?nnev?g

Quoted 9 lines · Alan Stern

Quoted 3 lines · Brian Swetland

Imagine the computer in question is a cellphone which is going to need to wake up when a call comes in to do traditional cellphone things, like ring, bring up the incall UI (so the user can answer/cancel), etc.

Yes. So what? Nothing I said prevents the computer from waking up when a call comes in. What I said was that when the user tells the computer to suspend (e.g., by writing "mem" to /sys/power/state), the computer should suspend even if some wakelocks are still locked.

Quoted 6 lines

But this could prevent the phone from ringing. What if the user-space code that is responsible for playing the ringtone has been notified that a call is coming in and starts reading the audio file with the ringtone. At the same, the user, unaware that someone is calling, presses the power button. If we ignore the wakelock in this situation, the phone will not ring.

What if the user decides to power off the phone and a call comes in at the same time?

Quoted 2 lines · Rafael J. Wysocki

Quoted 1 line · Arve Hj?nnev?g

On Sat, Jan 31, 2009 at 7:41 AM, Alan Stern <[email protected]>

Quoted 11 lines

Quoted 11 lines

Quoted 10 lines · Brian Swetland

Quoted 4 lines

Imagine the computer in question is a cellphone which is going to need to wake up when a call comes in to do traditional cellphone things, like ring, bring up the incall UI (so the user can answer/cancel), etc.

Yes. So what? Nothing I said prevents the computer from waking up when a call comes in. What I said was that when the user tells the computer to suspend (e.g., by writing "mem" to /sys/power/state), the computer should suspend even if some wakelocks are still locked.

Quoted 6 lines

Quoted 6 lines

But this could prevent the phone from ringing. What if the user-space code that is responsible for playing the ringtone has been notified that a call is coming in and starts reading the audio file with the ringtone. At the same, the user, unaware that someone is calling, presses the power button. If we ignore the wakelock in this situation, the phone will not ring.

Yes, you don't want to write "mem" to /sys/power/state on android. You want to write something like "auto-mem" there.

Quoted 8 lines

AFAICT, this is something very different. It is attempt to do autosuspend right. Imagine burning cd... right now you can suspend, and it will just stop the burn.

Wakelocks code allows you to tell the machine 'feel free to suspend when you have nothing to do'... so the machine will burn the cd and then suspend.

Yes, wakelocks solves this problem, but our auto-suspend code is all in user-space so the kernel would not have to be involved in that particular example.

I added an example to the document that may help illustrate why we added wakelock support in the kernel:

---
Documentation/power/wakelocks.txt
Wakelocks
=========

A wakelock prevents the system from entering suspend or other low-power states when active. If the type is set to WAKE_LOCK_SUSPEND, the wakelock prevents a full system suspend. If the type is WAKE_LOCK_IDLE, low-power states that cause large interrupt latencies or that disable a set of interrupts will not be entered from idle until the wakelocks are released.

Wakelocks can be used to allow user-space to decide which keys should wake the system. The sequence of events can look like this:
- The Keypad driver gets an interrupt. It then locks the keypad-scan wakelock and starts scanning the keypad.
- The keypad-scan code detects a key change and reports it to the input-event driver.
- The input-event driver sees the key change, enqueues an event, and locks the input-event-queue wakelock.
- The keypad-scan code detects that no keys are held and unlocks the

keypad-scan wakelock.
- The user-space input-event thread returns from select/poll, locks the process-input-events wakelock and then calls read in the input-event device.
- The input-event driver dequeues the key-event and, since the queue is now empty, it unlocks the input-event-queue wakelock.
- The user-space input-event thread returns from read. It determines that the key should not wake up the system, releases the process-input-events wakelock and calls select or poll.

Quoted 8 lines · Pavel Machek

Quoted 7 lines

AFAICT, this is something very different. It is attempt to do autosuspend right. Imagine burning cd... right now you can suspend, and it will just stop the burn.

Wakelocks code allows you to tell the machine 'feel free to suspend when you have nothing to do'... so the machine will burn the cd and then suspend.

I don't get it. So you are running userspace while system is suspended?

The following patch series adds two apis, wakelock and earlysuspend. The Android platform uses the earlysuspend api to turn the screen and some input devices on and off. The wakelock code determines when to enter the full suspend state.

These apis could also be useful to other platforms where the goal is to enter full suspend whenever possible.