[RFC][PATCH 00/11] Android PM extensions

[RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

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.

--
Arve Hjønnevåg

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 01/11] PM: Add wake lock api.

[Arve Hjønnevåg]

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 include/linux/wakelock.h |   91 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 91 insertions(+), 0 deletions(-)
 create mode 100755 include/linux/wakelock.h

diff --git a/include/linux/wakelock.h b/include/linux/wakelock.h
new file mode 100755
index 0000000..a096d24
--- /dev/null
+++ b/include/linux/wakelock.h
@@ -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.
+ *
+ */
+
+#ifndef _LINUX_WAKELOCK_H
+#define _LINUX_WAKELOCK_H
+
+#include <linux/list.h>
+#include <linux/ktime.h>
+
+/* 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.
+ */
+
+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;
+		int             expire_count;
+		int             wakeup_count;
+		ktime_t         total_time;
+		ktime_t         prevent_suspend_time;
+		ktime_t         max_time;
+		ktime_t         last_time;
+	} stat;
+#endif
+#endif
+};
+
+#ifdef CONFIG_HAS_WAKELOCK
+
+void wake_lock_init(struct wake_lock *lock, int type, const char *name);
+void wake_lock_destroy(struct wake_lock *lock);
+void wake_lock(struct wake_lock *lock);
+void wake_lock_timeout(struct wake_lock *lock, long timeout);
+void wake_unlock(struct wake_lock *lock);
+
+/* 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.
+ */
+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) {}
+static inline void wake_lock_timeout(struct wake_lock *lock, long timeout) {}
+static inline void wake_unlock(struct wake_lock *lock) {}
+
+static inline int wake_lock_active(struct wake_lock *lock) { return 0; }
+static inline long has_wake_lock(int type) { return 0; }
+
+#endif
+
+#endif
+
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 02/11] PM: Add early suspend api.

[Arve Hjønnevåg]

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 include/linux/earlysuspend.h |   56 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)
 create mode 100755 include/linux/earlysuspend.h

diff --git a/include/linux/earlysuspend.h b/include/linux/earlysuspend.h
new file mode 100755
index 0000000..8343b81
--- /dev/null
+++ b/include/linux/earlysuspend.h
@@ -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
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_EARLYSUSPEND_H
+#define _LINUX_EARLYSUSPEND_H
+
+#ifdef CONFIG_HAS_EARLYSUSPEND
+#include <linux/list.h>
+#endif
+
+/* 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,
+ * 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.
+ */
+enum {
+	EARLY_SUSPEND_LEVEL_BLANK_SCREEN = 50,
+	EARLY_SUSPEND_LEVEL_STOP_DRAWING = 100,
+	EARLY_SUSPEND_LEVEL_DISABLE_FB = 150,
+};
+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);
+#endif
+};
+
+#ifdef CONFIG_HAS_EARLYSUSPEND
+void register_early_suspend(struct early_suspend *handler);
+void unregister_early_suspend(struct early_suspend *handler);
+#else
+#define register_early_suspend(handler) do { } while (0)
+#define unregister_early_suspend(handler) do { } while (0)
+#endif
+
+#endif
+
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 03/11] PM: Implement wakelock api.

[Arve Hjønnevåg]

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/Kconfig    |   19 ++
 kernel/power/Makefile   |    1 +
 kernel/power/power.h    |    7 +
 kernel/power/wakelock.c |  598 +++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 625 insertions(+), 0 deletions(-)
 create mode 100644 kernel/power/wakelock.c

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 23bd4da..6e3da6e 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -116,6 +116,25 @@ config SUSPEND_FREEZER
 
 	  Turning OFF this setting is NOT recommended! If in doubt, say Y.
 
+config HAS_WAKELOCK
+	bool
+
+config WAKELOCK
+	bool "Wake lock"
+	depends on PM && RTC_CLASS
+	default n
+	select HAS_WAKELOCK
+	---help---
+	  Enable wakelocks. When user space request a sleep state the
+	  sleep request will be delayed until no wake locks are held.
+
+config WAKELOCK_STAT
+	bool "Wake lock stats"
+	depends on WAKELOCK
+	default y
+	---help---
+	  Report wake lock stats in /proc/wakelocks
+
 config HIBERNATION
 	bool "Hibernation (aka 'suspend to disk')"
 	depends on PM && SWAP && ARCH_HIBERNATION_POSSIBLE
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 597823b..401ddfe 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -5,6 +5,7 @@ endif
 
 obj-y				:= main.o
 obj-$(CONFIG_PM_SLEEP)		+= process.o console.o
+obj-$(CONFIG_WAKELOCK)		+= wakelock.o
 obj-$(CONFIG_HIBERNATION)	+= swsusp.o disk.o snapshot.o swap.o user.o
 
 obj-$(CONFIG_MAGIC_SYSRQ)	+= poweroff.o
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 46b5ec7..1527174 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -223,3 +223,10 @@ static inline void suspend_thaw_processes(void)
 {
 }
 #endif
+
+#ifdef CONFIG_WAKELOCK
+/* kernel/power/wakelock.c */
+extern struct workqueue_struct *suspend_work_queue;
+extern struct wake_lock main_wake_lock;
+extern suspend_state_t requested_suspend_state;
+#endif
diff --git a/kernel/power/wakelock.c b/kernel/power/wakelock.c
new file mode 100644
index 0000000..c9e22f9
--- /dev/null
+++ b/kernel/power/wakelock.c
@@ -0,0 +1,598 @@
+/* kernel/power/wakelock.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/module.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+#include <linux/suspend.h>
+#include <linux/syscalls.h> /* sys_sync */
+#include <linux/wakelock.h>
+#ifdef CONFIG_WAKELOCK_STAT
+#include <linux/proc_fs.h>
+#endif
+#include "power.h"
+
+enum {
+	DEBUG_EXIT_SUSPEND = 1U << 0,
+	DEBUG_WAKEUP = 1U << 1,
+	DEBUG_SUSPEND = 1U << 2,
+	DEBUG_EXPIRE = 1U << 3,
+	DEBUG_WAKE_LOCK = 1U << 4,
+};
+static int debug_mask = DEBUG_EXIT_SUSPEND | DEBUG_WAKEUP;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+#define WAKE_LOCK_TYPE_MASK              (0x0f)
+#define WAKE_LOCK_INITIALIZED            (1U << 8)
+#define WAKE_LOCK_ACTIVE                 (1U << 9)
+#define WAKE_LOCK_AUTO_EXPIRE            (1U << 10)
+#define WAKE_LOCK_PREVENTING_SUSPEND     (1U << 11)
+
+static DEFINE_SPINLOCK(list_lock);
+static LIST_HEAD(inactive_locks);
+static struct list_head active_wake_locks[WAKE_LOCK_TYPE_COUNT];
+static int current_event_num;
+struct workqueue_struct *suspend_work_queue;
+struct wake_lock main_wake_lock;
+suspend_state_t requested_suspend_state = PM_SUSPEND_MEM;
+static struct wake_lock unknown_wakeup;
+
+#ifdef CONFIG_WAKELOCK_STAT
+static struct wake_lock deleted_wake_locks;
+static ktime_t last_sleep_time_update;
+static int wait_for_wakeup;
+
+int get_expired_time(struct wake_lock *lock, ktime_t *expire_time)
+{
+	struct timespec ts;
+	struct timespec kt;
+	struct timespec tomono;
+	struct timespec delta;
+	unsigned long seq;
+	long timeout;
+
+	if (!(lock->flags & WAKE_LOCK_AUTO_EXPIRE))
+		return 0;
+	do {
+		seq = read_seqbegin(&xtime_lock);
+		timeout = lock->expires - jiffies;
+		if (timeout > 0)
+			return 0;
+		kt = current_kernel_time();
+		tomono = wall_to_monotonic;
+	} while (read_seqretry(&xtime_lock, seq));
+	jiffies_to_timespec(-timeout, &delta);
+	set_normalized_timespec(&ts, kt.tv_sec + tomono.tv_sec - delta.tv_sec,
+				kt.tv_nsec + tomono.tv_nsec - delta.tv_nsec);
+	*expire_time = timespec_to_ktime(ts);
+	return 1;
+}
+
+
+static int print_lock_stat(char *buf, struct wake_lock *lock)
+{
+	int lock_count = lock->stat.count;
+	int expire_count = lock->stat.expire_count;
+	ktime_t active_time = ktime_set(0, 0);
+	ktime_t total_time = lock->stat.total_time;
+	ktime_t max_time = lock->stat.max_time;
+	ktime_t prevent_suspend_time = lock->stat.prevent_suspend_time;
+	if (lock->flags & WAKE_LOCK_ACTIVE) {
+		ktime_t now, add_time;
+		int expired = get_expired_time(lock, &now);
+		if (!expired)
+			now = ktime_get();
+		add_time = ktime_sub(now, lock->stat.last_time);
+		lock_count++;
+		if (!expired)
+			active_time = add_time;
+		else
+			expire_count++;
+		total_time = ktime_add(total_time, add_time);
+		if (lock->flags & WAKE_LOCK_PREVENTING_SUSPEND)
+			prevent_suspend_time = ktime_add(prevent_suspend_time,
+					ktime_sub(now, last_sleep_time_update));
+		if (add_time.tv64 > max_time.tv64)
+			max_time = add_time;
+	}
+
+	return sprintf(buf, "\"%s\"\t%d\t%d\t%d\t%lld\t%lld\t%lld\t%lld\t"
+		       "%lld\n", lock->name, lock_count, expire_count,
+		       lock->stat.wakeup_count, ktime_to_ns(active_time),
+		       ktime_to_ns(total_time),
+		       ktime_to_ns(prevent_suspend_time), ktime_to_ns(max_time),
+		       ktime_to_ns(lock->stat.last_time));
+}
+
+
+static int wakelocks_read_proc(char *page, char **start, off_t off,
+			       int count, int *eof, void *data)
+{
+	unsigned long irqflags;
+	struct wake_lock *lock;
+	int len = 0;
+	char *p = page;
+	int type;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+
+	p += sprintf(p, "name\tcount\texpire_count\twake_count\tactive_since"
+		     "\ttotal_time\tsleep_time\tmax_time\tlast_change\n");
+	list_for_each_entry(lock, &inactive_locks, link) {
+		p += print_lock_stat(p, lock);
+	}
+	for (type = 0; type < WAKE_LOCK_TYPE_COUNT; type++) {
+		list_for_each_entry(lock, &active_wake_locks[type], link)
+			p += print_lock_stat(p, lock);
+	}
+	spin_unlock_irqrestore(&list_lock, irqflags);
+
+	*start = page + off;
+
+	len = p - page;
+	if (len > off)
+		len -= off;
+	else
+		len = 0;
+
+	return len < count ? len  : count;
+}
+
+static void wake_unlock_stat_locked(struct wake_lock *lock, int expired)
+{
+	ktime_t duration;
+	ktime_t now;
+	if (!(lock->flags & WAKE_LOCK_ACTIVE))
+		return;
+	if (get_expired_time(lock, &now))
+		expired = 1;
+	else
+		now = ktime_get();
+	lock->stat.count++;
+	if (expired)
+		lock->stat.expire_count++;
+	duration = ktime_sub(now, lock->stat.last_time);
+	lock->stat.total_time = ktime_add(lock->stat.total_time, duration);
+	if (ktime_to_ns(duration) > ktime_to_ns(lock->stat.max_time))
+		lock->stat.max_time = duration;
+	lock->stat.last_time = ktime_get();
+	if (lock->flags & WAKE_LOCK_PREVENTING_SUSPEND) {
+		duration = ktime_sub(now, last_sleep_time_update);
+		lock->stat.prevent_suspend_time = ktime_add(
+			lock->stat.prevent_suspend_time, duration);
+		lock->flags &= ~WAKE_LOCK_PREVENTING_SUSPEND;
+	}
+}
+
+static void update_sleep_wait_stats_locked(int done)
+{
+	struct wake_lock *lock;
+	ktime_t now, etime, elapsed, add;
+	int expired;
+
+	now = ktime_get();
+	elapsed = ktime_sub(now, last_sleep_time_update);
+	list_for_each_entry(lock, &active_wake_locks[WAKE_LOCK_SUSPEND], link) {
+		expired = get_expired_time(lock, &etime);
+		if (lock->flags & WAKE_LOCK_PREVENTING_SUSPEND) {
+			if (expired)
+				add = ktime_sub(etime, last_sleep_time_update);
+			else
+				add = elapsed;
+			lock->stat.prevent_suspend_time = ktime_add(
+				lock->stat.prevent_suspend_time, add);
+		}
+		if (done || expired)
+			lock->flags &= ~WAKE_LOCK_PREVENTING_SUSPEND;
+		else
+			lock->flags |= WAKE_LOCK_PREVENTING_SUSPEND;
+	}
+	last_sleep_time_update = now;
+}
+#endif
+
+
+static void expire_wake_lock(struct wake_lock *lock)
+{
+#ifdef CONFIG_WAKELOCK_STAT
+	wake_unlock_stat_locked(lock, 1);
+#endif
+	lock->flags &= ~(WAKE_LOCK_ACTIVE | WAKE_LOCK_AUTO_EXPIRE);
+	list_del(&lock->link);
+	list_add(&lock->link, &inactive_locks);
+	if (debug_mask & (DEBUG_WAKE_LOCK | DEBUG_EXPIRE))
+		pr_info("expired wake lock %s\n", lock->name);
+}
+
+static void print_active_locks(int type)
+{
+	unsigned long irqflags;
+	struct wake_lock *lock;
+
+	BUG_ON(type >= WAKE_LOCK_TYPE_COUNT);
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_for_each_entry(lock, &active_wake_locks[type], link) {
+		if (lock->flags & WAKE_LOCK_AUTO_EXPIRE) {
+			long timeout = lock->expires - jiffies;
+			if (timeout <= 0)
+				pr_info("wake lock %s, expired\n", lock->name);
+			else
+				pr_info("active wake lock %s, time left %ld\n",
+					lock->name, timeout);
+		} else
+			pr_info("active wake lock %s\n", lock->name);
+	}
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+
+static long has_wake_lock_locked(int type)
+{
+	struct wake_lock *lock, *n;
+	long max_timeout = 0;
+
+	BUG_ON(type >= WAKE_LOCK_TYPE_COUNT);
+	list_for_each_entry_safe(lock, n, &active_wake_locks[type], link) {
+		if (lock->flags & WAKE_LOCK_AUTO_EXPIRE) {
+			long timeout = lock->expires - jiffies;
+			if (timeout <= 0)
+				expire_wake_lock(lock);
+			else if (timeout > max_timeout)
+				max_timeout = timeout;
+		} else
+			return -1;
+	}
+	return max_timeout;
+}
+
+long has_wake_lock(int type)
+{
+	long ret;
+	unsigned long irqflags;
+	spin_lock_irqsave(&list_lock, irqflags);
+	ret = has_wake_lock_locked(type);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+	return ret;
+}
+
+static void suspend(struct work_struct *work)
+{
+	int ret;
+	int entry_event_num;
+
+	if (has_wake_lock(WAKE_LOCK_SUSPEND)) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("suspend: abort suspend\n");
+		return;
+	}
+
+	entry_event_num = current_event_num;
+	sys_sync();
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("suspend: enter suspend\n");
+	ret = pm_suspend(requested_suspend_state);
+	if (debug_mask & DEBUG_EXIT_SUSPEND) {
+		struct timespec ts;
+		struct rtc_time tm;
+		getnstimeofday(&ts);
+		rtc_time_to_tm(ts.tv_sec, &tm);
+		pr_info("suspend: exit suspend, ret = %d "
+			"(%d-%02d-%02d %02d:%02d:%02d.%09lu UTC)\n", ret,
+			tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
+			tm.tm_hour, tm.tm_min, tm.tm_sec, ts.tv_nsec);
+	}
+	if (current_event_num == entry_event_num) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("suspend: pm_suspend returned with no event\n");
+		wake_lock_timeout(&unknown_wakeup, HZ / 2);
+	}
+}
+static DECLARE_WORK(suspend_work, suspend);
+
+static void expire_wake_locks(unsigned long data)
+{
+	long has_lock;
+	unsigned long irqflags;
+	if (debug_mask & DEBUG_EXPIRE)
+		pr_info("expire_wake_locks: start\n");
+	if (debug_mask & DEBUG_SUSPEND)
+		print_active_locks(WAKE_LOCK_SUSPEND);
+	spin_lock_irqsave(&list_lock, irqflags);
+	has_lock = has_wake_lock_locked(WAKE_LOCK_SUSPEND);
+	if (debug_mask & DEBUG_EXPIRE)
+		pr_info("expire_wake_locks: done, has_lock %ld\n", has_lock);
+	if (has_lock == 0)
+		queue_work(suspend_work_queue, &suspend_work);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+static DEFINE_TIMER(expire_timer, expire_wake_locks, 0, 0);
+
+static int power_suspend_late(struct platform_device *pdev, pm_message_t state)
+{
+	int ret = has_wake_lock(WAKE_LOCK_SUSPEND) ? -EAGAIN : 0;
+#ifdef CONFIG_WAKELOCK_STAT
+	wait_for_wakeup = 1;
+#endif
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("power_suspend_late return %d\n", ret);
+	return ret;
+}
+
+static struct platform_driver power_driver = {
+	.driver.name = "power",
+	.suspend_late = power_suspend_late,
+};
+static struct platform_device power_device = {
+	.name = "power",
+};
+
+void wake_lock_init(struct wake_lock *lock, int type, const char *name)
+{
+	unsigned long irqflags = 0;
+
+	if (name)
+		lock->name = name;
+	BUG_ON(!lock->name);
+
+	if (debug_mask & DEBUG_WAKE_LOCK)
+		pr_info("wake_lock_init name=%s\n", lock->name);
+#ifdef CONFIG_WAKELOCK_STAT
+	lock->stat.count = 0;
+	lock->stat.expire_count = 0;
+	lock->stat.wakeup_count = 0;
+	lock->stat.total_time = ktime_set(0, 0);
+	lock->stat.prevent_suspend_time = ktime_set(0, 0);
+	lock->stat.max_time = ktime_set(0, 0);
+	lock->stat.last_time = ktime_set(0, 0);
+#endif
+	lock->flags = (type & WAKE_LOCK_TYPE_MASK) | WAKE_LOCK_INITIALIZED;
+
+	INIT_LIST_HEAD(&lock->link);
+	spin_lock_irqsave(&list_lock, irqflags);
+	list_add(&lock->link, &inactive_locks);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(wake_lock_init);
+
+void wake_lock_destroy(struct wake_lock *lock)
+{
+	unsigned long irqflags;
+	if (debug_mask & DEBUG_WAKE_LOCK)
+		pr_info("wake_lock_destroy name=%s\n", lock->name);
+	spin_lock_irqsave(&list_lock, irqflags);
+	lock->flags &= ~WAKE_LOCK_INITIALIZED;
+#ifdef CONFIG_WAKELOCK_STAT
+	if (lock->stat.count) {
+		deleted_wake_locks.stat.count += lock->stat.count;
+		deleted_wake_locks.stat.expire_count += lock->stat.expire_count;
+		deleted_wake_locks.stat.total_time =
+			ktime_add(deleted_wake_locks.stat.total_time,
+				  lock->stat.total_time);
+		deleted_wake_locks.stat.prevent_suspend_time =
+			ktime_add(deleted_wake_locks.stat.prevent_suspend_time,
+				  lock->stat.prevent_suspend_time);
+		deleted_wake_locks.stat.max_time =
+			ktime_add(deleted_wake_locks.stat.max_time,
+				  lock->stat.max_time);
+	}
+#endif
+	list_del(&lock->link);
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(wake_lock_destroy);
+
+static void wake_lock_internal(
+	struct wake_lock *lock, long timeout, int has_timeout)
+{
+	int type;
+	unsigned long irqflags;
+	long expire_in;
+
+	spin_lock_irqsave(&list_lock, irqflags);
+	type = lock->flags & WAKE_LOCK_TYPE_MASK;
+	BUG_ON(type >= WAKE_LOCK_TYPE_COUNT);
+	BUG_ON(!(lock->flags & WAKE_LOCK_INITIALIZED));
+#ifdef CONFIG_WAKELOCK_STAT
+	if (type == WAKE_LOCK_SUSPEND && wait_for_wakeup) {
+		if (debug_mask & DEBUG_WAKEUP)
+			pr_info("wakeup wake lock: %s\n", lock->name);
+		wait_for_wakeup = 0;
+		lock->stat.wakeup_count++;
+	}
+	if ((lock->flags & WAKE_LOCK_AUTO_EXPIRE) &&
+	    (long)(lock->expires - jiffies) <= 0) {
+		wake_unlock_stat_locked(lock, 0);
+		lock->stat.last_time = ktime_get();
+	}
+#endif
+	if (!(lock->flags & WAKE_LOCK_ACTIVE)) {
+		lock->flags |= WAKE_LOCK_ACTIVE;
+#ifdef CONFIG_WAKELOCK_STAT
+		lock->stat.last_time = ktime_get();
+#endif
+	}
+	list_del(&lock->link);
+	if (has_timeout) {
+		if (debug_mask & DEBUG_WAKE_LOCK)
+			pr_info("wake_lock: %s, type %d, timeout %ld.%03lu\n",
+				lock->name, type, timeout / HZ,
+				(timeout % HZ) * MSEC_PER_SEC / HZ);
+		lock->expires = jiffies + timeout;
+		lock->flags |= WAKE_LOCK_AUTO_EXPIRE;
+		list_add_tail(&lock->link, &active_wake_locks[type]);
+	} else {
+		if (debug_mask & DEBUG_WAKE_LOCK)
+			pr_info("wake_lock: %s, type %d\n", lock->name, type);
+		lock->expires = LONG_MAX;
+		lock->flags &= ~WAKE_LOCK_AUTO_EXPIRE;
+		list_add(&lock->link, &active_wake_locks[type]);
+	}
+	if (type == WAKE_LOCK_SUSPEND) {
+		current_event_num++;
+#ifdef CONFIG_WAKELOCK_STAT
+		if (lock == &main_wake_lock)
+			update_sleep_wait_stats_locked(1);
+		else if (!wake_lock_active(&main_wake_lock))
+			update_sleep_wait_stats_locked(0);
+#endif
+		if (has_timeout)
+			expire_in = has_wake_lock_locked(type);
+		else
+			expire_in = -1;
+		if (expire_in > 0) {
+			if (debug_mask & DEBUG_EXPIRE)
+				pr_info("wake_lock: %s, start expire timer, "
+					"%ld\n", lock->name, expire_in);
+			mod_timer(&expire_timer, jiffies + expire_in);
+		} else {
+			if (del_timer(&expire_timer))
+				if (debug_mask & DEBUG_EXPIRE)
+					pr_info("wake_lock: %s, stop expire "
+						"timer\n", lock->name);
+			if (expire_in == 0)
+				queue_work(suspend_work_queue, &suspend_work);
+		}
+	}
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+
+void wake_lock(struct wake_lock *lock)
+{
+	wake_lock_internal(lock, 0, 0);
+}
+EXPORT_SYMBOL(wake_lock);
+
+void wake_lock_timeout(struct wake_lock *lock, long timeout)
+{
+	wake_lock_internal(lock, timeout, 1);
+}
+EXPORT_SYMBOL(wake_lock_timeout);
+
+void wake_unlock(struct wake_lock *lock)
+{
+	int type;
+	unsigned long irqflags;
+	spin_lock_irqsave(&list_lock, irqflags);
+	type = lock->flags & WAKE_LOCK_TYPE_MASK;
+#ifdef CONFIG_WAKELOCK_STAT
+	wake_unlock_stat_locked(lock, 0);
+#endif
+	if (debug_mask & DEBUG_WAKE_LOCK)
+		pr_info("wake_unlock: %s\n", lock->name);
+	lock->flags &= ~(WAKE_LOCK_ACTIVE | WAKE_LOCK_AUTO_EXPIRE);
+	list_del(&lock->link);
+	list_add(&lock->link, &inactive_locks);
+	if (type == WAKE_LOCK_SUSPEND) {
+		long has_lock = has_wake_lock_locked(type);
+		if (has_lock > 0) {
+			if (debug_mask & DEBUG_EXPIRE)
+				pr_info("wake_unlock: %s, start expire timer, "
+					"%ld\n", lock->name, has_lock);
+			mod_timer(&expire_timer, jiffies + has_lock);
+		} else {
+			if (del_timer(&expire_timer))
+				if (debug_mask & DEBUG_EXPIRE)
+					pr_info("wake_unlock: %s, stop expire "
+						"timer\n", lock->name);
+			if (has_lock == 0)
+				queue_work(suspend_work_queue, &suspend_work);
+		}
+		if (lock == &main_wake_lock) {
+			if (debug_mask & DEBUG_SUSPEND)
+				print_active_locks(WAKE_LOCK_SUSPEND);
+#ifdef CONFIG_WAKELOCK_STAT
+			update_sleep_wait_stats_locked(0);
+#endif
+		}
+	}
+	spin_unlock_irqrestore(&list_lock, irqflags);
+}
+EXPORT_SYMBOL(wake_unlock);
+
+int wake_lock_active(struct wake_lock *lock)
+{
+	return !!(lock->flags & WAKE_LOCK_ACTIVE);
+}
+EXPORT_SYMBOL(wake_lock_active);
+
+static int __init wakelocks_init(void)
+{
+	int ret;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(active_wake_locks); i++)
+		INIT_LIST_HEAD(&active_wake_locks[i]);
+
+#ifdef CONFIG_WAKELOCK_STAT
+	wake_lock_init(&deleted_wake_locks, WAKE_LOCK_SUSPEND,
+			"deleted_wake_locks");
+#endif
+	wake_lock_init(&main_wake_lock, WAKE_LOCK_SUSPEND, "main");
+	wake_lock(&main_wake_lock);
+	wake_lock_init(&unknown_wakeup, WAKE_LOCK_SUSPEND, "unknown_wakeups");
+
+	ret = platform_device_register(&power_device);
+	if (ret) {
+		pr_err("wakelocks_init: platform_device_register failed\n");
+		goto err_platform_device_register;
+	}
+	ret = platform_driver_register(&power_driver);
+	if (ret) {
+		pr_err("wakelocks_init: platform_driver_register failed\n");
+		goto err_platform_driver_register;
+	}
+
+	suspend_work_queue = create_singlethread_workqueue("suspend");
+	if (suspend_work_queue == NULL) {
+		ret = -ENOMEM;
+		goto err_suspend_work_queue;
+	}
+
+#ifdef CONFIG_WAKELOCK_STAT
+	create_proc_read_entry("wakelocks", S_IRUGO, NULL,
+				wakelocks_read_proc, NULL);
+#endif
+
+	return 0;
+
+err_suspend_work_queue:
+	platform_driver_unregister(&power_driver);
+err_platform_driver_register:
+	platform_device_unregister(&power_device);
+err_platform_device_register:
+	wake_lock_destroy(&unknown_wakeup);
+	wake_lock_destroy(&main_wake_lock);
+#ifdef CONFIG_WAKELOCK_STAT
+	wake_lock_destroy(&deleted_wake_locks);
+#endif
+	return ret;
+}
+
+static void  __exit wakelocks_exit(void)
+{
+#ifdef CONFIG_WAKELOCK_STAT
+	remove_proc_entry("wakelocks", NULL);
+#endif
+	destroy_workqueue(suspend_work_queue);
+	platform_driver_unregister(&power_driver);
+	platform_device_unregister(&power_device);
+	wake_lock_destroy(&unknown_wakeup);
+	wake_lock_destroy(&main_wake_lock);
+#ifdef CONFIG_WAKELOCK_STAT
+	wake_lock_destroy(&deleted_wake_locks);
+#endif
+}
+
+core_initcall(wakelocks_init);
+module_exit(wakelocks_exit);
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 04/11] PM: Implement early suspend api

[Arve Hjønnevåg]

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 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

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 6e3da6e..50690d8 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -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
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 401ddfe..f0f7b15 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -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
diff --git a/kernel/power/earlysuspend.c b/kernel/power/earlysuspend.c
new file mode 100644
index 0000000..84bed51
--- /dev/null
+++ b/kernel/power/earlysuspend.c
@@ -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>
+#include <linux/syscalls.h> /* sys_sync */
+#include <linux/wakelock.h>
+#include <linux/workqueue.h>
+
+#include "power.h"
+
+enum {
+	DEBUG_USER_STATE = 1U << 0,
+	DEBUG_SUSPEND = 1U << 2,
+};
+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,
+};
+static int state;
+
+void register_early_suspend(struct early_suspend *handler)
+{
+	struct list_head *pos;
+
+	mutex_lock(&early_suspend_lock);
+	list_for_each(pos, &early_suspend_handlers) {
+		struct early_suspend *e;
+		e = list_entry(pos, struct early_suspend, link);
+		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) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("early_suspend: abort, state %d\n", state);
+		mutex_unlock(&early_suspend_lock);
+		goto abort;
+	}
+
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("early_suspend: call handlers\n");
+	list_for_each_entry(pos, &early_suspend_handlers, link) {
+		if (pos->suspend != NULL)
+			pos->suspend(pos);
+	}
+	mutex_unlock(&early_suspend_lock);
+
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("early_suspend: sync\n");
+
+	sys_sync();
+abort:
+	spin_lock_irqsave(&state_lock, irqflags);
+	if (state == SUSPEND_REQUESTED_AND_SUSPENDED)
+		wake_unlock(&main_wake_lock);
+	spin_unlock_irqrestore(&state_lock, irqflags);
+}
+
+static void late_resume(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 == SUSPENDED)
+		state &= ~SUSPENDED;
+	else
+		abort = 1;
+	spin_unlock_irqrestore(&state_lock, irqflags);
+
+	if (abort) {
+		if (debug_mask & DEBUG_SUSPEND)
+			pr_info("late_resume: abort, state %d\n", state);
+		goto abort;
+	}
+	if (debug_mask & DEBUG_SUSPEND)
+		pr_info("late_resume: call handlers\n");
+	list_for_each_entry_reverse(pos, &early_suspend_handlers, link)
+		if (pos->resume != NULL)
+			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;
+}
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 1527174..7ce9637 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -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
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 05/11] PM: Enable early suspend through /sys/power/state

[Arve Hjønnevåg]

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.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/main.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/kernel/power/main.c b/kernel/power/main.c
index 2399888..f2139ca 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -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,
 			   const char *buf, size_t n)
 {
 #ifdef CONFIG_SUSPEND
+#ifdef CONFIG_EARLYSUSPEND
+	suspend_state_t state = PM_SUSPEND_ON;
+#else
 	suspend_state_t state = PM_SUSPEND_STANDBY;
+#endif
 	const char * const *s;
 #endif
 	char *p;
@@ -527,8 +534,15 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr,
 			break;
 	}
 	if (state < PM_SUSPEND_MAX && *s)
+#ifdef CONFIG_EARLYSUSPEND
+		if (state == PM_SUSPEND_ON || valid_state(state)) {
+			error = 0;
+			request_suspend_state(state);
+		}
+#else
 		error = enter_state(state);
 #endif
+#endif
 
  Exit:
 	return error ? error : n;
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 06/11] PM: Add user-space wake lock api.

[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.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/Kconfig        |   10 ++
 kernel/power/Makefile       |    1 +
 kernel/power/main.c         |    9 ++
 kernel/power/power.h        |   11 ++
 kernel/power/userwakelock.c |  218 +++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 249 insertions(+), 0 deletions(-)
 create mode 100644 kernel/power/userwakelock.c

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 50690d8..dd6910d 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -138,6 +138,16 @@ config WAKELOCK_STAT
 	---help---
 	  Report wake lock stats in /proc/wakelocks
 
+config USER_WAKELOCK
+	bool "Userspace wake locks"
+	depends on WAKELOCK
+	default y
+	---help---
+	  User-space wake lock api. Write "lockname" or "lockname timeout"
+	  to /sys/power/wake_lock lock and if needed create a wake lock.
+	  Write "lockname" to /sys/power/wake_unlock to unlock a user wake
+	  lock.
+
 config EARLYSUSPEND
 	bool "Early suspend"
 	depends on WAKELOCK
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index f0f7b15..4d838cd 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -6,6 +6,7 @@ endif
 obj-y				:= main.o
 obj-$(CONFIG_PM_SLEEP)		+= process.o console.o
 obj-$(CONFIG_WAKELOCK)		+= wakelock.o
+obj-$(CONFIG_USER_WAKELOCK)	+= userwakelock.o
 obj-$(CONFIG_EARLYSUSPEND)	+= earlysuspend.o
 obj-$(CONFIG_HIBERNATION)	+= swsusp.o disk.o snapshot.o swap.o user.o
 
diff --git a/kernel/power/main.c b/kernel/power/main.c
index f2139ca..587f881 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -575,6 +575,11 @@ pm_trace_store(struct kobject *kobj, struct kobj_attribute *attr,
 power_attr(pm_trace);
 #endif /* CONFIG_PM_TRACE */
 
+#ifdef CONFIG_USER_WAKELOCK
+power_attr(wake_lock);
+power_attr(wake_unlock);
+#endif
+
 static struct attribute * g[] = {
 	&state_attr.attr,
 #ifdef CONFIG_PM_TRACE
@@ -583,6 +588,10 @@ static struct attribute * g[] = {
 #if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PM_DEBUG)
 	&pm_test_attr.attr,
 #endif
+#ifdef CONFIG_USER_WAKELOCK
+	&wake_lock_attr.attr,
+	&wake_unlock_attr.attr,
+#endif
 	NULL,
 };
 
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 7ce9637..d1b19fc 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -231,6 +231,17 @@ extern struct wake_lock main_wake_lock;
 extern suspend_state_t requested_suspend_state;
 #endif
 
+#ifdef CONFIG_USER_WAKELOCK
+ssize_t wake_lock_show(struct kobject *kobj, struct kobj_attribute *attr,
+			char *buf);
+ssize_t wake_lock_store(struct kobject *kobj, struct kobj_attribute *attr,
+			const char *buf, size_t n);
+ssize_t wake_unlock_show(struct kobject *kobj, struct kobj_attribute *attr,
+			char *buf);
+ssize_t  wake_unlock_store(struct kobject *kobj, struct kobj_attribute *attr,
+			const char *buf, size_t n);
+#endif
+
 #ifdef CONFIG_EARLYSUSPEND
 /* kernel/power/earlysuspend.c */
 void request_suspend_state(suspend_state_t state);
diff --git a/kernel/power/userwakelock.c b/kernel/power/userwakelock.c
new file mode 100644
index 0000000..d7242d9
--- /dev/null
+++ b/kernel/power/userwakelock.c
@@ -0,0 +1,218 @@
+/* kernel/power/userwakelock.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/ctype.h>
+#include <linux/module.h>
+#include <linux/wakelock.h>
+
+#include "power.h"
+
+enum {
+	DEBUG_FAILURE	= BIT(0),
+	DEBUG_ERROR	= BIT(1),
+	DEBUG_NEW	= BIT(2),
+	DEBUG_ACCESS	= BIT(3),
+	DEBUG_LOOKUP	= BIT(4),
+};
+static int debug_mask = DEBUG_FAILURE;
+module_param_named(debug_mask, debug_mask, int, S_IRUGO | S_IWUSR | S_IWGRP);
+
+static DEFINE_MUTEX(tree_lock);
+
+struct user_wake_lock {
+	struct rb_node		node;
+	struct wake_lock	wake_lock;
+	char			name[0];
+};
+struct rb_root user_wake_locks;
+
+static struct user_wake_lock *lookup_wake_lock_name(
+	const char *buf, int allocate, long *timeoutptr)
+{
+	struct rb_node **p = &user_wake_locks.rb_node;
+	struct rb_node *parent = NULL;
+	struct user_wake_lock *l;
+	int diff;
+	u64 timeout;
+	int name_len;
+	const char *arg;
+
+	/* Find length of lock name and start of optional timeout string */
+	arg = buf;
+	while (*arg && !isspace(*arg))
+		arg++;
+	name_len = arg - buf;
+	if (!name_len)
+		goto bad_arg;
+	while (isspace(*arg))
+		arg++;
+
+	/* Process timeout string */
+	if (timeoutptr && *arg) {
+		timeout = simple_strtoull(arg, (char **)&arg, 0);
+		while (isspace(*arg))
+			arg++;
+		if (*arg)
+			goto bad_arg;
+		/* convert timeout from nanoseconds to jiffies > 0 */
+		timeout += (NSEC_PER_SEC / HZ) - 1;
+		do_div(timeout, (NSEC_PER_SEC / HZ));
+		if (timeout <= 0)
+			timeout = 1;
+		*timeoutptr = timeout;
+	} else if (*arg)
+		goto bad_arg;
+	else if (timeoutptr)
+		*timeoutptr = 0;
+
+	/* Lookup wake lock in rbtree */
+	while (*p) {
+		parent = *p;
+		l = rb_entry(parent, struct user_wake_lock, node);
+		diff = strncmp(buf, l->name, name_len);
+		if (!diff && l->name[name_len])
+			diff = -1;
+		if (debug_mask & DEBUG_ERROR)
+			pr_info("lookup_wake_lock_name: compare %.*s %s %d\n",
+				name_len, buf, l->name, diff);
+
+		if (diff < 0)
+			p = &(*p)->rb_left;
+		else if (diff > 0)
+			p = &(*p)->rb_right;
+		else
+			return l;
+	}
+
+	/* Allocate and add new wakelock to rbtree */
+	if (!allocate) {
+		if (debug_mask & DEBUG_ERROR)
+			pr_info("lookup_wake_lock_name: %.*s not found\n",
+				name_len, buf);
+		return ERR_PTR(-EINVAL);
+	}
+	l = kzalloc(sizeof(*l) + name_len + 1, GFP_KERNEL);
+	if (l == NULL) {
+		if (debug_mask & DEBUG_FAILURE)
+			pr_err("lookup_wake_lock_name: failed to allocate "
+				"memory for %.*s\n", name_len, buf);
+		return ERR_PTR(-ENOMEM);
+	}
+	memcpy(l->name, buf, name_len);
+	if (debug_mask & DEBUG_NEW)
+		pr_info("lookup_wake_lock_name: new wake lock %s\n", l->name);
+	wake_lock_init(&l->wake_lock, WAKE_LOCK_SUSPEND, l->name);
+	rb_link_node(&l->node, parent, p);
+	rb_insert_color(&l->node, &user_wake_locks);
+	return l;
+
+bad_arg:
+	if (debug_mask & DEBUG_ERROR)
+		pr_info("lookup_wake_lock_name: wake lock, %.*s, bad arg, %s\n",
+			name_len, buf, arg);
+	return ERR_PTR(-EINVAL);
+}
+
+ssize_t wake_lock_show(
+	struct kobject *kobj, struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	char *end = buf + PAGE_SIZE;
+	struct rb_node *n;
+	struct user_wake_lock *l;
+
+	mutex_lock(&tree_lock);
+
+	for (n = rb_first(&user_wake_locks); n != NULL; n = rb_next(n)) {
+		l = rb_entry(n, struct user_wake_lock, node);
+		if (wake_lock_active(&l->wake_lock))
+			s += scnprintf(s, end - s, "%s ", l->name);
+	}
+	s += scnprintf(s, end - s, "\n");
+
+	mutex_unlock(&tree_lock);
+	return (s - buf);
+}
+
+ssize_t wake_lock_store(
+	struct kobject *kobj, struct kobj_attribute *attr,
+	const char *buf, size_t n)
+{
+	long timeout;
+	struct user_wake_lock *l;
+
+	mutex_lock(&tree_lock);
+	l = lookup_wake_lock_name(buf, 1, &timeout);
+	if (IS_ERR(l)) {
+		n = PTR_ERR(l);
+		goto bad_name;
+	}
+
+	if (debug_mask & DEBUG_ACCESS)
+		pr_info("wake_lock_store: %s, timeout %ld\n", l->name, timeout);
+
+	if (timeout)
+		wake_lock_timeout(&l->wake_lock, timeout);
+	else
+		wake_lock(&l->wake_lock);
+bad_name:
+	mutex_unlock(&tree_lock);
+	return n;
+}
+
+
+ssize_t wake_unlock_show(
+	struct kobject *kobj, struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	char *end = buf + PAGE_SIZE;
+	struct rb_node *n;
+	struct user_wake_lock *l;
+
+	mutex_lock(&tree_lock);
+
+	for (n = rb_first(&user_wake_locks); n != NULL; n = rb_next(n)) {
+		l = rb_entry(n, struct user_wake_lock, node);
+		if (!wake_lock_active(&l->wake_lock))
+			s += scnprintf(s, end - s, "%s ", l->name);
+	}
+	s += scnprintf(s, end - s, "\n");
+
+	mutex_unlock(&tree_lock);
+	return (s - buf);
+}
+
+ssize_t wake_unlock_store(
+	struct kobject *kobj, struct kobj_attribute *attr,
+	const char *buf, size_t n)
+{
+	struct user_wake_lock *l;
+
+	mutex_lock(&tree_lock);
+	l = lookup_wake_lock_name(buf, 0, NULL);
+	if (IS_ERR(l)) {
+		n = PTR_ERR(l);
+		goto not_found;
+	}
+
+	if (debug_mask & DEBUG_ACCESS)
+		pr_info("wake_unlock_store: %s\n", l->name);
+
+	wake_unlock(&l->wake_lock);
+not_found:
+	mutex_unlock(&tree_lock);
+	return n;
+}
+
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 07/11] PM: wakelock: Abort task freezing if a wake lock is held.

[Arve Hjønnevåg]

Avoids a problem where the device sometimes hangs for 20 seconds
before the screen is turned on.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/process.c |   22 +++++++++++++++++-----
 1 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/kernel/power/process.c b/kernel/power/process.c
index ca63401..8388d01 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -13,6 +13,7 @@
 #include <linux/module.h>
 #include <linux/syscalls.h>
 #include <linux/freezer.h>
+#include <linux/wakelock.h>
 
 /* 
  * Timeout for stopping processes
@@ -36,6 +37,7 @@ static int try_to_freeze_tasks(bool sig_only)
 	struct timeval start, end;
 	u64 elapsed_csecs64;
 	unsigned int elapsed_csecs;
+	unsigned int wakeup = 0;
 
 	do_gettimeofday(&start);
 
@@ -62,6 +64,10 @@ static int try_to_freeze_tasks(bool sig_only)
 		} while_each_thread(g, p);
 		read_unlock(&tasklist_lock);
 		yield();			/* Yield is okay here */
+		if (todo && has_wake_lock(WAKE_LOCK_SUSPEND)) {
+			wakeup = 1;
+			break;
+		}
 		if (time_after(jiffies, end_time))
 			break;
 	} while (todo);
@@ -77,11 +83,17 @@ static int try_to_freeze_tasks(bool sig_only)
 		 * and caller must call thaw_processes() if something fails),
 		 * but it cleans up leftover PF_FREEZE requests.
 		 */
-		printk("\n");
-		printk(KERN_ERR "Freezing of tasks failed after %d.%02d seconds "
-				"(%d tasks refusing to freeze):\n",
-				elapsed_csecs / 100, elapsed_csecs % 100, todo);
-		show_state();
+		if (wakeup) {
+			printk("\n");
+			printk(KERN_ERR "Freezing of %s aborted\n",
+					sig_only ? "user space " : "tasks ");
+		} else {
+			printk("\n");
+			printk(KERN_ERR "Freezing of tasks failed after %d.%02d seconds "
+					"(%d tasks refusing to freeze):\n",
+					elapsed_csecs / 100, elapsed_csecs % 100, todo);
+			show_state();
+		}
 		read_lock(&tasklist_lock);
 		do_each_thread(g, p) {
 			task_lock(p);
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 08/11] PM: earlysuspend: Add console switch when user requested sleep state changes.

[Arve Hjønnevåg]

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/Kconfig               |   17 ++++++++
 kernel/power/Makefile              |    1 +
 kernel/power/consoleearlysuspend.c |   78 ++++++++++++++++++++++++++++++++++++
 3 files changed, 96 insertions(+), 0 deletions(-)
 create mode 100644 kernel/power/consoleearlysuspend.c

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index dd6910d..36e442f 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -157,6 +157,23 @@ config EARLYSUSPEND
 	  Call early suspend handlers when the user requested sleep state
 	  changes.
 
+choice
+	prompt "User-space screen access"
+	default CONSOLE_EARLYSUSPEND
+	depends on HAS_EARLYSUSPEND
+
+	config NO_USER_SPACE_SCREEN_ACCESS_CONTROL
+		bool "None"
+
+	config CONSOLE_EARLYSUSPEND
+		bool "Console switch on early-suspend"
+		depends on HAS_EARLYSUSPEND && VT
+		---help---
+		  Register early suspend handler to perform a console switch to
+		  when user-space should stop drawing to the screen and a switch
+		  back when it should resume.
+endchoice
+
 config HIBERNATION
 	bool "Hibernation (aka 'suspend to disk')"
 	depends on PM && SWAP && ARCH_HIBERNATION_POSSIBLE
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 4d838cd..5b74133 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PM_SLEEP)		+= process.o console.o
 obj-$(CONFIG_WAKELOCK)		+= wakelock.o
 obj-$(CONFIG_USER_WAKELOCK)	+= userwakelock.o
 obj-$(CONFIG_EARLYSUSPEND)	+= earlysuspend.o
+obj-$(CONFIG_CONSOLE_EARLYSUSPEND)	+= consoleearlysuspend.o
 obj-$(CONFIG_HIBERNATION)	+= swsusp.o disk.o snapshot.o swap.o user.o
 
 obj-$(CONFIG_MAGIC_SYSRQ)	+= poweroff.o
diff --git a/kernel/power/consoleearlysuspend.c b/kernel/power/consoleearlysuspend.c
new file mode 100644
index 0000000..a8befb4
--- /dev/null
+++ b/kernel/power/consoleearlysuspend.c
@@ -0,0 +1,78 @@
+/* kernel/power/consoleearlysuspend.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/console.h>
+#include <linux/earlysuspend.h>
+#include <linux/kbd_kern.h>
+#include <linux/module.h>
+#include <linux/vt_kern.h>
+#include <linux/wait.h>
+
+#define EARLY_SUSPEND_CONSOLE	(MAX_NR_CONSOLES-1)
+
+static int orig_fgconsole;
+static void console_early_suspend(struct early_suspend *h)
+{
+	acquire_console_sem();
+	orig_fgconsole = fg_console;
+	if (vc_allocate(EARLY_SUSPEND_CONSOLE))
+		goto err;
+	if (set_console(EARLY_SUSPEND_CONSOLE))
+		goto err;
+	release_console_sem();
+
+	if (vt_waitactive(EARLY_SUSPEND_CONSOLE))
+		pr_warning("console_early_suspend: Can't switch VCs.\n");
+	return;
+err:
+	pr_warning("console_early_suspend: Can't set console\n");
+	release_console_sem();
+}
+
+static void console_late_resume(struct early_suspend *h)
+{
+	int ret;
+	acquire_console_sem();
+	ret = set_console(orig_fgconsole);
+	release_console_sem();
+	if (ret) {
+		pr_warning("console_late_resume: Can't set console.\n");
+		return;
+	}
+
+	if (vt_waitactive(orig_fgconsole))
+		pr_warning("console_late_resume: Can't switch VCs.\n");
+}
+
+static struct early_suspend console_early_suspend_desc = {
+	.level = EARLY_SUSPEND_LEVEL_STOP_DRAWING,
+	.suspend = console_early_suspend,
+	.resume = console_late_resume,
+};
+
+static int __init console_early_suspend_init(void)
+{
+	register_early_suspend(&console_early_suspend_desc);
+	return 0;
+}
+
+static void  __exit console_early_suspend_exit(void)
+{
+	unregister_early_suspend(&console_early_suspend_desc);
+}
+
+module_init(console_early_suspend_init);
+module_exit(console_early_suspend_exit);
+
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 09/11] PM: earlysuspend: Removing dependence on console.

[Arve Hjønnevåg]

From: Rebecca Schultz <rschultz@google.com>

Rather than signaling a full update of the display from userspace via a
console switch, this patch introduces 2 files int /sys/power,
wait_for_fb_sleep and wait_for_fb_wake.  Reading these files will block
until the requested state has been entered.  When a read from
wait_for_fb_sleep returns userspace should stop drawing.  When
wait_for_fb_wake returns, it should do a full update.  If either are called
when the fb driver is already in the requested state, they will return
immediately.

Signed-off-by: Rebecca Schultz <rschultz@google.com>
Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 kernel/power/Kconfig          |    9 +++
 kernel/power/Makefile         |    1 +
 kernel/power/fbearlysuspend.c |  153 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 163 insertions(+), 0 deletions(-)
 create mode 100644 kernel/power/fbearlysuspend.c

diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 36e442f..015e6ae 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -159,6 +159,7 @@ config EARLYSUSPEND
 
 choice
 	prompt "User-space screen access"
+	default FB_EARLYSUSPEND if !FRAMEBUFFER_CONSOLE
 	default CONSOLE_EARLYSUSPEND
 	depends on HAS_EARLYSUSPEND
 
@@ -172,6 +173,14 @@ choice
 		  Register early suspend handler to perform a console switch to
 		  when user-space should stop drawing to the screen and a switch
 		  back when it should resume.
+
+	config FB_EARLYSUSPEND
+		bool "Sysfs interface"
+		depends on HAS_EARLYSUSPEND
+		---help---
+		  Register early suspend handler that notifies and waits for
+		  user-space through sysfs when user-space should stop drawing
+		  to the screen and notifies user-space when it should resume.
 endchoice
 
 config HIBERNATION
diff --git a/kernel/power/Makefile b/kernel/power/Makefile
index 5b74133..7b8b2cc 100644
--- a/kernel/power/Makefile
+++ b/kernel/power/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_WAKELOCK)		+= wakelock.o
 obj-$(CONFIG_USER_WAKELOCK)	+= userwakelock.o
 obj-$(CONFIG_EARLYSUSPEND)	+= earlysuspend.o
 obj-$(CONFIG_CONSOLE_EARLYSUSPEND)	+= consoleearlysuspend.o
+obj-$(CONFIG_FB_EARLYSUSPEND)	+= fbearlysuspend.o
 obj-$(CONFIG_HIBERNATION)	+= swsusp.o disk.o snapshot.o swap.o user.o
 
 obj-$(CONFIG_MAGIC_SYSRQ)	+= poweroff.o
diff --git a/kernel/power/fbearlysuspend.c b/kernel/power/fbearlysuspend.c
new file mode 100644
index 0000000..1513765
--- /dev/null
+++ b/kernel/power/fbearlysuspend.c
@@ -0,0 +1,153 @@
+/* kernel/power/fbearlysuspend.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/wait.h>
+
+#include "power.h"
+
+static wait_queue_head_t fb_state_wq;
+static DEFINE_SPINLOCK(fb_state_lock);
+static enum {
+	FB_STATE_STOPPED_DRAWING,
+	FB_STATE_REQUEST_STOP_DRAWING,
+	FB_STATE_DRAWING_OK,
+} fb_state;
+
+/* tell userspace to stop drawing, wait for it to stop */
+static void stop_drawing_early_suspend(struct early_suspend *h)
+{
+	int ret;
+	unsigned long irq_flags;
+
+	spin_lock_irqsave(&fb_state_lock, irq_flags);
+	fb_state = FB_STATE_REQUEST_STOP_DRAWING;
+	spin_unlock_irqrestore(&fb_state_lock, irq_flags);
+
+	wake_up_all(&fb_state_wq);
+	ret = wait_event_timeout(fb_state_wq,
+				 fb_state == FB_STATE_STOPPED_DRAWING,
+				 HZ);
+	if (unlikely(fb_state != FB_STATE_STOPPED_DRAWING))
+		pr_warning("stop_drawing_early_suspend: timeout waiting for "
+			   "userspace to stop drawing\n");
+}
+
+/* tell userspace to start drawing */
+static void start_drawing_late_resume(struct early_suspend *h)
+{
+	unsigned long irq_flags;
+
+	spin_lock_irqsave(&fb_state_lock, irq_flags);
+	fb_state = FB_STATE_DRAWING_OK;
+	spin_unlock_irqrestore(&fb_state_lock, irq_flags);
+	wake_up(&fb_state_wq);
+}
+
+static struct early_suspend stop_drawing_early_suspend_desc = {
+	.level = EARLY_SUSPEND_LEVEL_STOP_DRAWING,
+	.suspend = stop_drawing_early_suspend,
+	.resume = start_drawing_late_resume,
+};
+
+static ssize_t wait_for_fb_sleep_show(struct kobject *kobj,
+				      struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int ret;
+
+	ret = wait_event_interruptible(fb_state_wq,
+				       fb_state != FB_STATE_DRAWING_OK);
+	if (ret && fb_state == FB_STATE_DRAWING_OK)
+		return ret;
+	else
+		s += sprintf(buf, "sleeping");
+	return s - buf;
+}
+
+static ssize_t wait_for_fb_wake_show(struct kobject *kobj,
+				     struct kobj_attribute *attr, char *buf)
+{
+	char *s = buf;
+	int ret;
+	unsigned long irq_flags;
+
+	spin_lock_irqsave(&fb_state_lock, irq_flags);
+	if (fb_state == FB_STATE_REQUEST_STOP_DRAWING) {
+		fb_state = FB_STATE_STOPPED_DRAWING;
+		wake_up(&fb_state_wq);
+	}
+	spin_unlock_irqrestore(&fb_state_lock, irq_flags);
+
+	ret = wait_event_interruptible(fb_state_wq,
+				       fb_state == FB_STATE_DRAWING_OK);
+	if (ret && fb_state != FB_STATE_DRAWING_OK)
+		return ret;
+	else
+		s += sprintf(buf, "awake");
+
+	return s - buf;
+}
+
+#define power_ro_attr(_name) \
+static struct kobj_attribute _name##_attr = {	\
+	.attr	= {				\
+		.name = __stringify(_name),	\
+		.mode = 0444,			\
+	},					\
+	.show	= _name##_show,			\
+	.store	= NULL,		\
+}
+
+power_ro_attr(wait_for_fb_sleep);
+power_ro_attr(wait_for_fb_wake);
+
+static struct attribute *g[] = {
+	&wait_for_fb_sleep_attr.attr,
+	&wait_for_fb_wake_attr.attr,
+	NULL,
+};
+
+static struct attribute_group attr_group = {
+	.attrs = g,
+};
+
+static int __init android_power_init(void)
+{
+	int ret;
+
+	init_waitqueue_head(&fb_state_wq);
+	fb_state = FB_STATE_DRAWING_OK;
+
+	ret = sysfs_create_group(power_kobj, &attr_group);
+	if (ret) {
+		pr_err("android_power_init: sysfs_create_group failed\n");
+		return ret;
+	}
+
+	register_early_suspend(&stop_drawing_early_suspend_desc);
+	return 0;
+}
+
+static void  __exit android_power_exit(void)
+{
+	unregister_early_suspend(&stop_drawing_early_suspend_desc);
+	sysfs_remove_group(power_kobj, &attr_group);
+}
+
+module_init(android_power_init);
+module_exit(android_power_exit);
+
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 10/11] Input: Hold wake lock while event queue is not empty.

[Arve Hjønnevåg]

Allows userspace code to process input events while
the device appears to be asleep.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 drivers/input/evdev.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index ed8baa0..e24050b 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -19,6 +19,7 @@
 #include <linux/input.h>
 #include <linux/major.h>
 #include <linux/device.h>
+#include <linux/wakelock.h>
 #include "input-compat.h"
 
 struct evdev {
@@ -43,6 +44,7 @@ struct evdev_client {
 	struct fasync_struct *fasync;
 	struct evdev *evdev;
 	struct list_head node;
+	struct wake_lock wake_lock;
 };
 
 static struct evdev *evdev_table[EVDEV_MINORS];
@@ -55,6 +57,7 @@ static void evdev_pass_event(struct evdev_client *client,
 	 * Interrupts are disabled, just acquire the lock
 	 */
 	spin_lock(&client->buffer_lock);
+	wake_lock_timeout(&client->wake_lock, 5 * HZ);
 	client->buffer[client->head++] = *event;
 	client->head &= EVDEV_BUFFER_SIZE - 1;
 	spin_unlock(&client->buffer_lock);
@@ -236,6 +239,7 @@ static int evdev_release(struct inode *inode, struct file *file)
 	mutex_unlock(&evdev->mutex);
 
 	evdev_detach_client(evdev, client);
+	wake_lock_destroy(&client->wake_lock);
 	kfree(client);
 
 	evdev_close_device(evdev);
@@ -272,6 +276,7 @@ static int evdev_open(struct inode *inode, struct file *file)
 	}
 
 	spin_lock_init(&client->buffer_lock);
+	wake_lock_init(&client->wake_lock, WAKE_LOCK_SUSPEND, "evdev");
 	client->evdev = evdev;
 	evdev_attach_client(evdev, client);
 
@@ -335,6 +340,8 @@ static int evdev_fetch_next_event(struct evdev_client *client,
 	if (have_event) {
 		*event = client->buffer[client->tail++];
 		client->tail &= EVDEV_BUFFER_SIZE - 1;
+		if (client->head == client->tail)
+			wake_unlock(&client->wake_lock);
 	}
 
 	spin_unlock_irq(&client->buffer_lock);
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[PATCH 11/11] ledtrig-sleep: Add led trigger for sleep debugging.

[Arve Hjønnevåg]

Signed-off-by: Brian Swetland <swetland@google.com>
Signed-off-by: Arve Hjønnevåg <arve@android.com>
---
 drivers/leds/Kconfig         |    6 +++
 drivers/leds/Makefile        |    1 +
 drivers/leds/ledtrig-sleep.c |   80 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+), 0 deletions(-)
 create mode 100644 drivers/leds/ledtrig-sleep.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a4a1ae2..2d555a3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -230,4 +230,10 @@ config LEDS_TRIGGER_DEFAULT_ON
 	  This allows LEDs to be initialised in the ON state.
 	  If unsure, say Y.
 
+config LEDS_TRIGGER_SLEEP
+	tristate "LED Sleep Mode Trigger"
+	depends on LEDS_TRIGGERS && HAS_EARLYSUSPEND
+	help
+	  This turns LEDs on when the screen is off but the cpu still running.
+
 endif # NEW_LEDS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index bc247cb..e259998 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK)	+= ledtrig-ide-disk.o
 obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT)	+= ledtrig-heartbeat.o
 obj-$(CONFIG_LEDS_TRIGGER_BACKLIGHT)	+= ledtrig-backlight.o
 obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON)	+= ledtrig-default-on.o
+obj-$(CONFIG_LEDS_TRIGGER_SLEEP)	+= ledtrig-sleep.o
diff --git a/drivers/leds/ledtrig-sleep.c b/drivers/leds/ledtrig-sleep.c
new file mode 100644
index 0000000..f164042
--- /dev/null
+++ b/drivers/leds/ledtrig-sleep.c
@@ -0,0 +1,80 @@
+/* drivers/leds/ledtrig-sleep.c
+ *
+ * Copyright (C) 2007 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/leds.h>
+#include <linux/suspend.h>
+
+static int ledtrig_sleep_pm_callback(struct notifier_block *nfb,
+					unsigned long action,
+					void *ignored);
+
+DEFINE_LED_TRIGGER(ledtrig_sleep)
+static struct notifier_block ledtrig_sleep_pm_notifier = {
+	.notifier_call = ledtrig_sleep_pm_callback,
+	.priority = 0,
+};
+
+static void ledtrig_sleep_early_suspend(struct early_suspend *h)
+{
+	led_trigger_event(ledtrig_sleep, LED_FULL);
+}
+
+static void ledtrig_sleep_early_resume(struct early_suspend *h)
+{
+	led_trigger_event(ledtrig_sleep, LED_OFF);
+}
+
+static struct early_suspend ledtrig_sleep_early_suspend_handler = {
+	.suspend = ledtrig_sleep_early_suspend,
+	.resume = ledtrig_sleep_early_resume,
+};
+
+static int ledtrig_sleep_pm_callback(struct notifier_block *nfb,
+					unsigned long action,
+					void *ignored)
+{
+	switch (action) {
+	case PM_HIBERNATION_PREPARE:
+	case PM_SUSPEND_PREPARE:
+		led_trigger_event(ledtrig_sleep, LED_OFF);
+		return NOTIFY_OK;
+	case PM_POST_HIBERNATION:
+	case PM_POST_SUSPEND:
+		led_trigger_event(ledtrig_sleep, LED_FULL);
+		return NOTIFY_OK;
+	}
+
+	return NOTIFY_DONE;
+}
+
+static int __init ledtrig_sleep_init(void)
+{
+	led_trigger_register_simple("sleep", &ledtrig_sleep);
+	register_pm_notifier(&ledtrig_sleep_pm_notifier);
+	register_early_suspend(&ledtrig_sleep_early_suspend_handler);
+	return 0;
+}
+
+static void __exit ledtrig_sleep_exit(void)
+{
+	unregister_early_suspend(&ledtrig_sleep_early_suspend_handler);
+	unregister_pm_notifier(&ledtrig_sleep_pm_notifier);
+	led_trigger_unregister_simple(ledtrig_sleep);
+}
+
+module_init(ledtrig_sleep_init);
+module_exit(ledtrig_sleep_exit);
+
-- 
1.6.1

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [RFC][PATCH 00/11] Android PM extensions

[Nigel Cunningham]

Hi Arve.

On Tue, 2009-01-13 at 17:27 -0800, Arve Hjønnevåg wrote:
> 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.

A few general comments:

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.

Regards,

Nigel

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 01/11] PM: Add wake lock api.

[Nigel Cunningham]

Hi.

On Tue, 2009-01-13 at 17:27 -0800, Arve Hjønnevåg wrote:
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
>  include/linux/wakelock.h |   91 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 91 insertions(+), 0 deletions(-)
>  create mode 100755 include/linux/wakelock.h
> 
> diff --git a/include/linux/wakelock.h b/include/linux/wakelock.h
> new file mode 100755
> index 0000000..a096d24
> --- /dev/null
> +++ b/include/linux/wakelock.h
> @@ -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.
> + *
> + */
> +
> +#ifndef _LINUX_WAKELOCK_H
> +#define _LINUX_WAKELOCK_H
> +
> +#include <linux/list.h>
> +#include <linux/ktime.h>
> +
> +/* 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.

> + * 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.

> + */
> +
> +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;
> +		int             expire_count;
> +		int             wakeup_count;
> +		ktime_t         total_time;
> +		ktime_t         prevent_suspend_time;
> +		ktime_t         max_time;
> +		ktime_t         last_time;
> +	} stat;
> +#endif
> +#endif
> +};

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).

> +
> +#ifdef CONFIG_HAS_WAKELOCK
> +
> +void wake_lock_init(struct wake_lock *lock, int type, const char *name);
> +void wake_lock_destroy(struct wake_lock *lock);
> +void wake_lock(struct wake_lock *lock);
> +void wake_lock_timeout(struct wake_lock *lock, long timeout);
> +void wake_unlock(struct wake_lock *lock);
> +
> +/* 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?

> + */
> +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) {}
> +static inline void wake_lock_timeout(struct wake_lock *lock, long timeout) {}
> +static inline void wake_unlock(struct wake_lock *lock) {}
> +
> +static inline int wake_lock_active(struct wake_lock *lock) { return 0; }
> +static inline long has_wake_lock(int type) { return 0; }
> +
> +#endif
> +
> +#endif
> +

Regards,

Nigel

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 02/11] PM: Add early suspend api.

[Nigel Cunningham]

Hi.

On Tue, 2009-01-13 at 17:27 -0800, Arve Hjønnevåg wrote:
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
>  include/linux/earlysuspend.h |   56 ++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 56 insertions(+), 0 deletions(-)
>  create mode 100755 include/linux/earlysuspend.h
> 
> diff --git a/include/linux/earlysuspend.h b/include/linux/earlysuspend.h
> new file mode 100755
> index 0000000..8343b81
> --- /dev/null
> +++ b/include/linux/earlysuspend.h
> @@ -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
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef _LINUX_EARLYSUSPEND_H
> +#define _LINUX_EARLYSUSPEND_H
> +
> +#ifdef CONFIG_HAS_EARLYSUSPEND
> +#include <linux/list.h>
> +#endif

Just #include anyway - it doesn't matter if it doesn't get used in some
circumstances.

> +
> +/* 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,
> + * 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.

> +enum {
> +	EARLY_SUSPEND_LEVEL_BLANK_SCREEN = 50,
> +	EARLY_SUSPEND_LEVEL_STOP_DRAWING = 100,
> +	EARLY_SUSPEND_LEVEL_DISABLE_FB = 150,
> +};
> +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.

> +#endif
> +};
> +
> +#ifdef CONFIG_HAS_EARLYSUSPEND
> +void register_early_suspend(struct early_suspend *handler);
> +void unregister_early_suspend(struct early_suspend *handler);
> +#else
> +#define register_early_suspend(handler) do { } while (0)
> +#define unregister_early_suspend(handler) do { } while (0)
> +#endif
> +
> +#endif
> +

Regards,

Nigel

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 03/11] PM: Implement wakelock api.

[Nigel Cunningham]

Hi again.

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

Regards,

Nigel

Re: [PATCH 04/11] PM: Implement early suspend api

[Nigel Cunningham]

Hi.

On Tue, 2009-01-13 at 17:27 -0800, Arve Hjønnevåg wrote:
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
>  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
> 
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 6e3da6e..50690d8 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -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
> diff --git a/kernel/power/Makefile b/kernel/power/Makefile
> index 401ddfe..f0f7b15 100644
> --- a/kernel/power/Makefile
> +++ b/kernel/power/Makefile
> @@ -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
> diff --git a/kernel/power/earlysuspend.c b/kernel/power/earlysuspend.c
> new file mode 100644
> index 0000000..84bed51
> --- /dev/null
> +++ b/kernel/power/earlysuspend.c
> @@ -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>
> +#include <linux/syscalls.h> /* sys_sync */
> +#include <linux/wakelock.h>
> +#include <linux/workqueue.h>
> +
> +#include "power.h"
> +
> +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.

> +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,
> +};
> +static int state;
> +
> +void register_early_suspend(struct early_suspend *handler)
> +{
> +	struct list_head *pos;
> +
> +	mutex_lock(&early_suspend_lock);
> +	list_for_each(pos, &early_suspend_handlers) {
> +		struct early_suspend *e;
> +		e = list_entry(pos, struct early_suspend, link);

list_for_each_entry?

> +		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) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("early_suspend: abort, state %d\n", state);
> +		mutex_unlock(&early_suspend_lock);
> +		goto abort;
> +	}
> +
> +	if (debug_mask & DEBUG_SUSPEND)
> +		pr_info("early_suspend: call handlers\n");
> +	list_for_each_entry(pos, &early_suspend_handlers, link) {
> +		if (pos->suspend != NULL)

Just "if (pos->suspend)" is sufficient.

> +			pos->suspend(pos);
> +	}
> +	mutex_unlock(&early_suspend_lock);
> +
> +	if (debug_mask & DEBUG_SUSPEND)
> +		pr_info("early_suspend: sync\n");
> +
> +	sys_sync();

Why the sync here?

> +abort:
> +	spin_lock_irqsave(&state_lock, irqflags);
> +	if (state == SUSPEND_REQUESTED_AND_SUSPENDED)
> +		wake_unlock(&main_wake_lock);
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +}
> +
> +static void late_resume(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 == SUSPENDED)
> +		state &= ~SUSPENDED;

Why not just say state = 0?

> +	else
> +		abort = 1;
> +	spin_unlock_irqrestore(&state_lock, irqflags);
> +
> +	if (abort) {
> +		if (debug_mask & DEBUG_SUSPEND)
> +			pr_info("late_resume: abort, state %d\n", state);
> +		goto abort;
> +	}
> +	if (debug_mask & DEBUG_SUSPEND)
> +		pr_info("late_resume: call handlers\n");
> +	list_for_each_entry_reverse(pos, &early_suspend_handlers, link)
> +		if (pos->resume != NULL)

if (pos->resume)

> +			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;
> +}
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 1527174..7ce9637 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -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
> -- 
> 1.6.1

Regards,

Nigel

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [PATCH 01/11] PM: Add wake lock api.

[Arve Hjønnevåg]

On Wed, Jan 14, 2009 at 1:09 AM, Nigel Cunningham
<ncunningham@crca.org.au> wrote:
>> +/* 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.
>

Not as it is currently implemented, but it probably should. The main
reason I avoid saying 'sleep' is that we enter cpu sleep modes from
idle as well.

>> + * 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.
>

It depends on how you look at it. We lock the system in the wake
state, or we lock against the suspend/sleep state. I have also seen
the term sleep vote used for a very similar mechanism, but I don't
like this either as a sleep vote is a veto against sleep.
I initially called it a suspend lock, then wake lock in user space.
Wake lock is the term that stuck so I changed the kernel api to use
it.

>
> 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).
>

I do this to avoid #ifdefs on CONFIG_HAS_WAKELOCK in the drivers.

>> +/* 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?
>

What I meant was that the wake lock had been checked and deactivated
from another code-path, after the timeout expired.


-- 
Arve Hjønnevåg

Re: [PATCH 02/11] PM: Add early suspend api.

[Arve Hjønnevåg]

On Wed, Jan 14, 2009 at 1:17 AM, Nigel Cunningham
<ncunningham@crca.org.au> wrote:
>> +
>> +/* 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,
>> + * 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.
>

Yes, but there is no time limit on how long the system is in the early
suspend state. This direct call at least allows a driver to rely on
suspend being called before resume.

>> +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.
>

They are not allowed to fail. These calls inform drivers that the user
visible sleep state has changed.

-- 
Arve Hjønnevåg

Re: [PATCH 03/11] PM: Implement wakelock api.

[Arve Hjønnevåg]

On Wed, Jan 14, 2009 at 1:30 AM, Nigel Cunningham
<ncunningham@crca.org.au> wrote:
> Just one comment here - you're adding new procfs entries. IIRC, sysfs is
> strongly preferred now.

I'm adding one procfs entry for stats/debugging information. The sysfs
rules do not allow this type of data so procfs seemed like the best
fit.

-- 
Arve Hjønnevåg

Re: [PATCH 04/11] PM: Implement early suspend api

[Arve Hjønnevåg]

On Wed, Jan 14, 2009 at 1:48 AM, Nigel Cunningham
<ncunningham@crca.org.au> wrote:
>> +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.
>

No. I missed it when separating the wake lock and early suspend code.

>> +     if (debug_mask & DEBUG_SUSPEND)
>> +             pr_info("early_suspend: sync\n");
>> +
>> +     sys_sync();
>
> Why the sync here?

At this point the device appears to asleep to the user but wakelocks
can prevent full suspend (which also calls sys_sync).

>> +     if (state == SUSPENDED)
>> +             state &= ~SUSPENDED;
>
> Why not just say state = 0?
>
Only the SUSPENDED bit may be modified here, but in this case state = 0 is safe.


-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Wed, Jan 14, 2009 at 1:01 AM, Nigel Cunningham
<ncunningham@crca.org.au> wrote:
> 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.

I called it earlysuspend since it a prerequisite for entering the
normal suspend state. It is really the user visible suspend state.

> 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?

I initially had provided the wakelock and earlysuspend apis on top of
the android_power driver then added the current implementation. If
there is no interest in allowing multiple implementations of the api,
can can remove these.

> 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.

I would not want to move these to the (existing) header file as they
are private to the wakelock implementation, but I could add some some
helper functions in a single #ifdef block.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Wed, Jan 14, 2009 at 1:01 AM, Nigel Cunningham
<ncunningham@crca.org.au> wrote:
> 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.


Driver API
==========

A driver can use the wakelock api by adding a wakelock variable to its state
and calling wake_lock_init. For instance:
struct state {
        struct wakelock wakelock;
}

init() {
        wake_lock_init(&state->wakelock, WAKE_LOCK_SUSPEND, "wakelockname");
}

Before freeing the memory wake_lock_destroy must be called:

uninit() {
        wake_lock_destroy(&state->wakelock);
}

When the driver determines that it needs to run (usually in an interrupt
handler) it calls wake_lock:
        wake_lock(&state->wakelock);

When it no longer needs to run it calls wake_unlock:
        wake_unlock(&state->wakelock);

It can also call wake_lock_timeout to release the wakelock after a delay:
        wake_lock_timeout(&state->wakelock, HZ);

This works whether the wake_lock is already held or not. It is useful if the
driver woke up other parts of the system that does not use wakelocks but
still need to run. Avoid this when possible, since it will waste power
if the timeout is long or may fail to finish needed work if the timeout is
short.


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

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

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



-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

6~On Wed, 14 Jan 2009, Arve Hjønnevåg wrote:

> On Wed, Jan 14, 2009 at 1:01 AM, Nigel Cunningham
> <ncunningham@crca.org.au> wrote:
> > 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.

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?

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.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Thu, Jan 15, 2009 at 7:08 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> 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?

When you release the last wakelock, the wakelock code will attempt to
suspend. Holding a wakelock prevents this, and it also will abort
suspend for you if the system is in the middle of suspending drivers.

> 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.

Returning an error would from suspend works to some degree, but it
provides no indication of when to retry the suspend operation. Also
each suspend attempt will freeze and thaw every process in the system
so it is not a good way to ensure that userspace code gets to run.
Sleeping in the suspend method will also prevent a wakeup so it is
only usable for short delays. Wakelocks can be held for hours if
needed.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

On Tue 2009-01-13 17:27:45, Arve Hj??nnev??g wrote:
> 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.

'sleepy linux'. Thanks for doing this.
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 05/11] PM: Enable early suspend through /sys/power/state

[Pavel Machek]

Hi!

> 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.

Ok, you'll need "on", too... for canceling... 

> @@ -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,

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

On Thu 2009-01-15 10:08:51, Alan Stern wrote:
> 6~On Wed, 14 Jan 2009, Arve Hj?nnev?g wrote:
> 
> > On Wed, Jan 14, 2009 at 1:01 AM, Nigel Cunningham
> > <ncunningham@crca.org.au> wrote:
> > > 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.
> 
> 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.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Thu, Jan 29, 2009 at 5:04 AM, Pavel Machek <pavel@ucw.cz> wrote:
> 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.

                 Key pressed   Key released
                     |             |
keypad-scan          ++++++++++++++++++
input-event-queue        +++          +++
process-input-events       +++          +++


Driver API
==========

A driver can use the wakelock api by adding a wakelock variable to its state
and calling wake_lock_init. For instance:
struct state {
        struct wakelock wakelock;
}

init() {
        wake_lock_init(&state->wakelock, WAKE_LOCK_SUSPEND, "wakelockname");
}

Before freeing the memory, wake_lock_destroy must be called:

uninit() {
        wake_lock_destroy(&state->wakelock);
}

When the driver determines that it needs to run (usually in an interrupt
handler) it calls wake_lock:
        wake_lock(&state->wakelock);

When it no longer needs to run it calls wake_unlock:
        wake_unlock(&state->wakelock);

It can also call wake_lock_timeout to release the wakelock after a delay:
        wake_lock_timeout(&state->wakelock, HZ);

This works whether the wakelock is already held or not. It is useful if the
driver woke up other parts of the system that do not use wakelocks but
still need to run. Avoid this when possible, since it will waste power
if the timeout is long or may fail to finish needed work if the timeout is
short.


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.


-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Thu, 29 Jan 2009, Arve Hjønnevåg wrote:

> Documentation/power/wakelocks.txt
> Wakelocks
> =========
> 
> 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."

> 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?

> 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.

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?

> - 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?

> - 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.

> - 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?

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Thu, Jan 29, 2009 at 7:27 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 29 Jan 2009, Arve Hjønnevåg wrote:
>> 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."

OK.

>> 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?

Most of the document refers to wakelocks of type WAKE_LOCK_SUSPEND. If
create a wakelock of type WAKE_LOCK_IDLE affects the idle power state
instead.

>> - 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?

It may have been. If it was, wake up should be for the interrupt using
the existing set_irq_wake call.

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

Yes, assuming is has not already suspended all the drivers and
disabled interrupts.

>
>> - 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?

Once you hold one key down, you cannot get another interrupt if you
press another key on the same input line. The driver uses a timer to
scan the keypad matrix until all keys are released. A key on a
dedicated input with both rising and falling edge detect interrupt
would not need this 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.
>
> Does the input-event-queue wakelock always prevent the system from
> suspending whenever the input queue is nonempty?

Yes.

> 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.

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

No.

> 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.

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.

>
>> - 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".

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

Documentation/power/wakelocks.txt (version 3)
Wakelocks
=========

A locked wakelock, depending on its type, prevents the system from entering
suspend or other low-power states. When creating a wakelock, you can select
if it prevents suspend or low-power idle states.  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. Unless the type is specified, this document refers
to wakelocks with the type set to WAKE_LOCK_SUSPEND.

If the suspend operation has already started when locking a wakelock, it will
abort the suspend operation as long it has not already reached the suspend_late
stage. This means that locking a wakelock from an interrupt handler or a
freezeable thread always works, but if you lock a wakelock from a suspend_late
handler you must also return an error from that handler to abort suspend.

Wakelocks can be used to allow user-space to decide which keys should wake the
full system up and turn the screen on. Use set_irq_wake or a platform specific
api to make sure the keypad interrupt wakes up the cpu. Once the keypad driver
has resumed, 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 matrix.
- 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 full system, releases the process-input-events
  wakelock and calls select or poll.

                 Key pressed   Key released
                     |             |
keypad-scan          ++++++++++++++++++
input-event-queue        +++          +++
process-input-events       +++          +++


Driver API
==========

A driver can use the wakelock api by adding a wakelock variable to its state
and calling wake_lock_init. For instance:
struct state {
        struct wakelock wakelock;
}

init() {
        wake_lock_init(&state->wakelock, WAKE_LOCK_SUSPEND, "wakelockname");
}

Before freeing the memory, wake_lock_destroy must be called:

uninit() {
        wake_lock_destroy(&state->wakelock);
}

When the driver determines that it needs to run (usually in an interrupt
handler) it calls wake_lock:
        wake_lock(&state->wakelock);

When it no longer needs to run it calls wake_unlock:
        wake_unlock(&state->wakelock);

It can also call wake_lock_timeout to release the wakelock after a delay:
        wake_lock_timeout(&state->wakelock, HZ);

This works whether the wakelock is already held or not. It is useful if the
driver woke up other parts of the system that do not use wakelocks but
still need to run. Avoid this when possible, since it will waste power
if the timeout is long or may fail to finish needed work if the timeout is
short.


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.



-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

> On Thu, Jan 29, 2009 at 5:04 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > 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.

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

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

> >> - 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".

"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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Brian Swetland]

[Pavel Machek <pavel@ucw.cz>]
> > On Thu, Jan 29, 2009 at 5:04 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > > 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 general idea is that we aggressively try to be suspended as much as
possible.  Typically this means that when the display is turned off
(after the user inactivity timeout, managed from a userspace process),
suspend is requested.

If work is being done that requires the system to keep running, a
wakelock is held, preventing suspend from happening.

If suspend happens, but we resume due to a wakeup interrupt (for
example, user pressing a key), a wakelock is typically acquired during
the interrupt handler (which is called while we're resuming) and
arranged to be held until the event is delivered to userspace.  The
userspace code which receives events acquires a wakelock before draining
the queue (after select returns, before reading, etc) so that it keeps
the system awake until the event is processed.

In many cases the system pretty rapidly drops wakelocks and returns to
suspend state.

Brian

Re: [RFC][PATCH 00/11] Android PM extensions

[Uli Luckas]

On Friday, 30. January 2009, Pavel Machek wrote:
> > >> - 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".
>
> "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".
 

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien

Re: [PATCH 06/11] PM: Add user-space wake lock api.

[Uli Luckas]

On Wednesday, 14. January 2009, Arve Hjønnevåg wrote:
> 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.

Uli

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Thu, 29 Jan 2009, Arve Hjønnevåg wrote:

> > Does the input-event-queue wakelock always prevent the system from
> > suspending whenever the input queue is nonempty?
> 
> Yes.
> 
> > 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.

Okay, this is slowly getting clearer.

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.

> > 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.

> 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.

Wakelocks and early-suspend are separate issues.  Let's consider only
wakelocks.

> >> - 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".

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.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Fri, Jan 30, 2009 at 7:13 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> 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.

>> > 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.

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).

> 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.

> 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.

>> >> - 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".
>
> 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).

> 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.

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?

-- 
Arve Hjønnevåg

Re: [PATCH 06/11] PM: Add user-space wake lock api.

[Arve Hjønnevåg]

On Fri, Jan 30, 2009 at 4:43 AM, Uli Luckas <u.luckas@road.de> wrote:
> On Wednesday, 14. January 2009, Arve Hjønnevåg wrote:
>> 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?

The lock will be held until the process restarts and unlocks it. We
only use this interface directly from processes that are started (and
restarted) from init. Applications use the user space api which talks
to our system process. If an application dies the system process is
notified and (userspace) wakelocks are deleted.

> 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 you want to use wakelocks directly from applications, that makes
sense, but I'm not sure we also want to remove this interface.

-- 
Arve Hjønnevåg

Re: [PATCH 05/11] PM: Enable early suspend through /sys/power/state

[Arve Hjønnevåg]

On Wed, Jan 28, 2009 at 11:34 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> 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.
>

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.

-- 
Arve Hjønnevåg

Re: [PATCH 06/11] PM: Add user-space wake lock api.

[Brian Swetland]

[Uli Luckas <u.luckas@road.de>]
> On Wednesday, 14. January 2009, Arve Hjønnevåg wrote:
> > 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.

On the android platform this is not a concern since only the system
server manages wakelocks directly and processes use a higher level
wakelock api in userspace that is remoted and handles this situation
(the system server knows when a process dies and can clean up).

For more general usage, the fd model does sound nicer, allowing
cleanup-on-exit, etc.  Arve -- is there a reason we went with sysfs?

Brian

Re: [RFC][PATCH 00/11] Android PM extensions

[Brian Swetland]

[Alan Stern <stern@rowland.harvard.edu>]
> > > 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!

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.

Brian

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Fri, 30 Jan 2009, Brian Swetland wrote:

> [Alan Stern <stern@rowland.harvard.edu>]
> > > > 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!
> 
> It depends on the particular "computer" and the problem you're solving.

I disagree.

> 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.

> 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.

> 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.

Alan Stern

Re: [PATCH 05/11] PM: Enable early suspend through /sys/power/state

[Alan Stern]

On Fri, 30 Jan 2009, Arve Hjønnevåg wrote:

> > 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.

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.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Fri, 30 Jan 2009, Arve Hjønnevåg wrote:

> On Fri, Jan 30, 2009 at 7:13 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > 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.


> > 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.

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.

> 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.

> 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!

> This is handled entirely by our user-space framework which also has
> other options (like keeping the keypad backlight on).
> 
> > 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.

> 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.

> > 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.

Maybe you do but you don't realize it.  :-)  And even if you don't, 
maybe other people do.

> 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?


> > 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.

> 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".

>  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.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Rafael J. Wysocki]

Sorry for being late to the party, I had more urgent things to take care of.

On Saturday 31 January 2009, Alan Stern wrote:
> On Fri, 30 Jan 2009, Brian Swetland wrote:
> 
> > [Alan Stern <stern@rowland.harvard.edu>]
> > > > > 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!
> > 
> > It depends on the particular "computer" and the problem you're solving.
> 
> I disagree.

Yeah.

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.

> > 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.

Agreed.

There should be well defined set of signals that can wake up the system
from the sleep state and the user should be able to control them.
 
> > 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.
> 
> > 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.

Thanks,
Rafael

Re: [RFC][PATCH 00/11] Android PM extensions

[Igor Stoppa]

Hi,
On Sat, 2009-01-31 at 19:39 +0100, ext Rafael J. Wysocki wrote:

> 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.

yup

it's very depressing that several years after we released the Nokia 770,
in the far 2005, people are still talking about these basic concepts.

And while it can be somehow excused for what concerns the x86 world of
laptops, it's even more depressing that such discussion surfaces in
relation to Android.

-- 

Cheers, Igor

---

Igor Stoppa
Maemo Software - Nokia Devices R&D - Helsinki

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Sat, Jan 31, 2009 at 7:41 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 30 Jan 2009, Brian Swetland wrote:
>> 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.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Rafael J. Wysocki]

On Saturday 31 January 2009, Arve Hjønnevåg wrote:
> On Sat, Jan 31, 2009 at 7:41 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Fri, 30 Jan 2009, Brian Swetland wrote:
> >> 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.

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

Rafael

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Sat, Jan 31, 2009 at 8:19 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 30 Jan 2009, Arve Hjønnevåg wrote:
>> On Fri, Jan 30, 2009 at 7:13 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > 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.

Only if you ignore the screen state. If the screen is off and the user
presses the power button, I expect it to turn on, not off.

>> 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.

A keypad matrix as outputs and inputs. To get an interrupt when any
key is pressed, all the output are driven and the interrupt is enabled
on the input. When you get this interrupt you turn off the interrupt
and stop driving all the outputs. Instead you drive one output, wait
for some settle time, and then read the inputs. If you go to sleep in
this state, no key will every wake the system up.

That said, if the interrupt is edge triggered, it is possible to
implement the behaviour you describe. You can pretend no keys are held
when the driver's suspend hook is called and start driving all the
output.

>> 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.

How is this better than using a wakelock? Is I understand you
correctly, that would mean that the user pressed the power button, and
instead of entering suspend as soon as all wakelocks are unlocked, you
don't enter suspend at all.

Also, when should the driver stop refusing suspend? As soon as it has
delivered a message to user-space? After some delay? When do you try
to enter suspend again after a driver refused a request?

> 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.

Normally when the user presses a key, the auto off timer in userspace
gets reset. This prevents the system from going back to sleep
immediately.

>
>> 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!
>
>> This is handled entirely by our user-space framework which also has
>> other options (like keeping the keypad backlight on).
>>
>> > 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.
>
>> 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.

But the purpose of wakelocks is to interfere with suspend. I keep
bringing up the screen state, because it is the state that is visible
to the user on our device. If the screen is off we enter suspend
whenever possible, if the screen is on we do not.

>> 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?

In the current implementation, early-suspend handlers are called, then
the "main" wakelock is unlocked.

>> > 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.

That would not work very well. All threads would be frozen, some
drivers suspended, the driver that knows that there are more keys in
the queue rejects suspend, and the process is reversed.

>> 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".

I was trying to keep the wakelock discussion separate from the
early-suspend. Perhaps this was a mistake.

>>  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.

Yes we go from fully awake to early suspend and back to fully awake,
and we also go from fully suspended to early-suspend and back to fully
suspended.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Sat, Jan 31, 2009 at 3:20 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Saturday 31 January 2009, Arve Hjønnevåg wrote:
>> 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?

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.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Rafael J. Wysocki]

On Sunday 01 February 2009, Arve Hjønnevåg wrote:
> On Sat, Jan 31, 2009 at 3:20 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Saturday 31 January 2009, Arve Hjønnevåg wrote:
> >> 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?
> 
> 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.

Thanks,
Rafael

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Sat, Jan 31, 2009 at 10:39 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 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.

No, our power off state is the same as on the desktop. We do use the
power key to enter and exit sleep, but you can configure a desktop
system to do this as well.

> 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.

On many arm processors there is also a big difference in what events
can take you out of the power-off state versus the sleep-state. On
some systems only the power button or the charger can turn the system
back on after power-off while a number of external and internal
interrupts can take the cpu out of the deep-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.

That may be true for single-core phones, but for dual core phones we
get significant power savings by doing a full suspend on the core that
runs Linux. On the system we currently have, we can enter the same
hardware state from idle as we can from suspend. But, on an idle
system with the radio is off, there are enough periodic timers to
double the average power draw. On a previous system the power draw
from idle was not even close to the power draw from suspend.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Sat, Jan 31, 2009 at 4:18 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> 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.

> 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.

> - 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).

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Rafael J. Wysocki]

On Sunday 01 February 2009, Arve Hjønnevåg wrote:
> On Sat, Jan 31, 2009 at 4:18 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > 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.
> 
> > 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.

> > - 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.

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

Thanks,
Rafael

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Sat, Jan 31, 2009 at 5:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > 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.
>
>> > - 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.
>
> 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.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Rafael J. Wysocki]

On Sunday 01 February 2009, Arve Hjønnevåg wrote:
> On Sat, Jan 31, 2009 at 5:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >> > 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.
> >
> >> > - 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.
> >
> > 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.

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.

Thanks,
Rafael

Re: [RFC][PATCH 00/11] Android PM extensions

[Woodruff, Richard]

> > 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.

What is being done is automatic very aggressive use of suspend. This is not a button press by the user.  As the same end mechanism is used (plumbing and end suspend call in driver) people are worried about semantics.

At the driver level it might be viewed as a constraint frame work which allows veto of the system-auto-suspend.  It provides a short circuits of the suspend before it gets very far.

There is a summed user space input point which allows user space to have a vote.  The upper level user space coordination prior to summed kernel interface is interesting.

At the kernel level if you work really really hard and use actively timers I think cpuidle and pm_qos can get you a similar aggressive sleep. However, there are many 'bad' drivers and it's a lot easier to re-use the suspend path. Being told to sleep is something drivers know, but doing it automatically and interfaces around that is not.  For OMAP3 we fixed up all drivers make cpuidle work and also keep traditional suspend.  This has been hard but possible.

While it is possible to fix kernel space doing the same to user space can be very hard. User space is much bigger and badness there can sink all your work in the kernel. What is good about android-system-auto-suspend here is that the freezer will stop a lot of bad processes in their tracks. To stop breakages in user space you can do the preferred thing and fix the code to be smart which could be hard/impossible or raise and lower a wakelock.  The wake lock is easier by comparison.

Any corrections by android experts are welcome.

Regards,
Richard W.

BTW, yes, the screen state is very import event in system power management on a cell phone.  When it blanks you move into a time where you can be very aggressive.  At this point a lot of timers (like user activity) and the like are expired.  You can do things which were not valid before as they would disrupt user experience.  Embedded people will use this as a critical point of reference as it's a pivot point.

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Sun, 1 Feb 2009, Rafael J. Wysocki wrote:

> > 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.

I'm beginning to get the impression that we're really talking about two 
different kinds of suspend here.  They can be described as 
"high-priority suspend" and "low-priority suspend".

A high-priority suspend occurs when userspace writes "mem" to 
/sys/power/state.  It should override wakelock settings and put the 
system to sleep as soon as possible (subject to abort by drivers, of 
course, but they better have a pretty good reason for aborting).

A low-priority suspend is what Arve has been talking about; it occurs
when the user pushes the phone's "power" button or the auto-suspend
mechanism activates.  It is subject to blocking by wakelocks, and there
should also be a way (although I don't recall seeing it described) to
cancel a low-priority suspend request while it is waiting for a
wakelock to be released.

The idea behind these low-priority suspends is that there are certain 
activities which should be atomic with respect to suspends, that is, 
the system should not normally be allowed to suspend while the activity 
is taking place.  These are things that last longer than a single 
interrupt handler.  Examples we have seen include waiting for all key 
presses to be released (because the keypad can't be enabled for wakeup 
if any keys are pressed) or waiting for a userspace process to finish 
playing a ring tone.

If a high-priority suspend occurs while some keys are pressed, the
keypad driver has a few possible courses of action: abort the suspend,
re-enable the interrupt circuitry, or disable keypad wakeups.  I'm not
sure which would be best; the issue probably won't arise much.  
Similarly, a high-priority suspend while a ring tone is being played
should cause the system to go to sleep right in the middle of playing.

Normally we would expect that on a desktop or laptop, the only source
of low-priority suspend requests would be the auto-suspend code.  On a
phone or other embedded device, we would not expect to see any
high-priority suspend requests under normal circumstances.  But of 
course there could always be exceptions, if someone wanted them.


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

Re: [RFC][PATCH 00/11] Android PM extensions

[Woodruff, Richard]

> 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).

The bit of use I saw was a few devices were broken out from the global suspend chain (display and some input).  They were effetely controlled from user space activity timers. The 'early_suspend' was sequenced before the global suspend call. Effectively this created a partial idle state where some drivers were down and others up. Also, the drivers on early_suspend might resume with out a global suspend. They also were not registered on global chain.

The upside of this from my point of view was the drivers on early suspend chain were high latency drivers. If they were linked into the global suspend chain they would drive up cost of frequent suspend substantially (a 60Hz or slower LCD DMA re-sync on both directions is costly, more so for some slow SPI-GPS kind of device). One example might be some periodic task wakes up to check the battery level then re-sleeps. On the resume side you don't want to restart the display system to do this. Since it is on a separate early-suspend-chain it doesn't wake until a later re-activated user space issues the wake if it needs to be.

Personally I still like an on-demand architecture for kernel space where drivers are coming up and down independently per control and data flow.  But this is harder. Splitting suspend seems to be an ok tradeoff for this problem.  Anyway, they don't conflict, you just use fewer or no kernel wake locks.  The user space ones are still around to help control the wild west up there.

This kind of system suspend seems good for power optimization at the user input speed time scale (hundreds of mS). It probably is too heavy to get really good power for constant active mode power like an mp3. At the current time scale the best you could hope for is DVFS with this. Doing DPS (dynamic-power-switching) to shut down individual blocks during playback, this seems like it would be to slow unless you had groups of independent 'early_suspend' device chains.

A mix of cpuidle + wakelock-aggressive-system-suspend should provide decent coverage for power states.

Again, I'll defer to android experts.

Regards,
Richard W.

Re: [RFC][PATCH 00/11] Android PM extensions

[Uli Luckas]

[-- Attachment #1.1: Type: text/plain, Size: 2369 bytes --]

On Saturday, 31. January 2009, Alan Stern wrote:
> > 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.


Uli

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC][PATCH 00/11] Android PM extensions

[Uli Luckas]

On Sunday, 1. February 2009, Alan Stern wrote:
> 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

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. 

Uli


-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien

Re: [PATCH 05/11] PM: Enable early suspend through /sys/power/state

[Pavel Machek]

On Sat 2009-01-31 10:49:16, Alan Stern wrote:
> On Fri, 30 Jan 2009, Arve Hj?nnev?g wrote:
> 
> > > 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.
> 
> 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.

Yes please.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 05/11] PM: Enable early suspend through /sys/power/state

[Pavel Machek]

On Fri 2009-01-30 19:13:32, Arve Hj?nnev?g wrote:
> On Wed, Jan 28, 2009 at 11:34 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> >> 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.
> >
> 
> 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.

That would be fine. And ignoring wakelocks in this case would be even better.

> 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.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

On Fri 2009-01-30 13:34:02, Uli Luckas wrote:
> On Friday, 30. January 2009, Pavel Machek wrote:
> > > >> - 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".
> >
> > "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".

I guess I'm missing big parts of the picture here. It would be nice to
document how it all works together... somewhere.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

Hi!

> 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.

Do you have some examples of user wakelocks?

The API is quite ugly; creating objects by writing to file.

If userspace does not want system to suspend, could it simply write
"on" to /sys/power/state ?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

Hi!

> 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

s/processor(s)/CPU/.

Even in PC, you have keyboard controller running while sleeping. On
cellphone, you have some kind of pmu chip + GSM chip running. So
cellphone actually _is_ useful even when CPU is sleeping.

> 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.

ACK.

> 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

No, it does not work like that. Cellphone with sleeping CPU
(suspended-to-RAM) is still very useful.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

On Sun 2009-02-01 00:20:04, Rafael J. Wysocki wrote:
> On Saturday 31 January 2009, Arve Hj?nnev?g wrote:
> > On Sat, Jan 31, 2009 at 7:41 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > On Fri, 30 Jan 2009, Brian Swetland wrote:
> > >> 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.

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

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

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Uli Luckas]

On Monday, 2. February 2009, Pavel Machek wrote:
> On Sun 2009-02-01 00:20:04, Rafael J. Wysocki wrote:
> > On Saturday 31 January 2009, Arve Hj?nnev?g wrote:
> > > On Sat, Jan 31, 2009 at 7:41 AM, Alan Stern <stern@rowland.harvard.edu> 
wrote:
> > > > On Fri, 30 Jan 2009, Brian Swetland wrote:
> > > >> 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.
>
> Yes, you don't want to write "mem" to /sys/power/state on android. You
> want to write something like "auto-mem" there.
>
ACK.
Don't change the way "mem" works. Just don't use it if it does the wrong thing 
on android.

Uli


-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Mon, 2 Feb 2009, Uli Luckas wrote:

> 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. 

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.

> 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.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Mon, 2 Feb 2009, Uli Luckas wrote:

> On Sunday, 1. February 2009, Alan Stern wrote:
> > 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
> 
> 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.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Uli Luckas]

On Monday, 2. February 2009, Alan Stern wrote:
> On Mon, 2 Feb 2009, Uli Luckas wrote:
> > 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.
>
> 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.
>
Full Ack

> > 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.
>
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 
> /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 :-)

Uli


-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien

Re: [RFC][PATCH 00/11] Android PM extensions

[Uli Luckas]

On Monday, 2. February 2009, Alan Stern wrote:
> On Mon, 2 Feb 2009, Uli Luckas wrote:
> > On Sunday, 1. February 2009, Alan Stern wrote:
> > > 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
> >
> > 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.
>
Actually i don't know. Arve?
Things would get a lot less complex if we could leave the early suspend stuff 
out of the kernel.

Uli

-- 

------- ROAD ...the handyPC Company - - -  ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Mon, 2 Feb 2009, Uli Luckas wrote:

> 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 
> > /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 :-)

Agreed.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Nigel Cunningham]

Hi.

On Mon, 2009-02-02 at 10:09 -0500, Alan Stern wrote:
> On Mon, 2 Feb 2009, Uli Luckas wrote:
> 
> > On Sunday, 1. February 2009, Alan Stern wrote:
> > > 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
> > 
> > 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.

Regards,

Nigel

Re: [PATCH 05/11] PM: Enable early suspend through /sys/power/state

[Arve Hjønnevåg]

On Mon, Feb 2, 2009 at 3:45 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Yes, goal is that compiling in  wakelock / early suspend support has
> no effect on existing functionality.

OK. I think I'll just print a warning and disable wakelock support if
user-space writes to /sys/power/state when wakelock support is
compiled in. A wakelock aware power manager in user-space can use an
always non-blocking interface (e.g. /sys/power/request_state) instead.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Mon, Feb 2, 2009 at 7:09 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Mon, 2 Feb 2009, Uli Luckas wrote:
>> 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.

> 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?

> 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?

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Mon, Feb 2, 2009 at 1:47 PM, Nigel Cunningham
<ncunningham@crca.org.au> 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?

> 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?

> 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.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Nigel Cunningham]

Hi.

On Mon, 2009-02-02 at 15:21 -0800, Arve Hjønnevåg wrote:
> On Mon, Feb 2, 2009 at 1:47 PM, Nigel Cunningham
> <ncunningham@crca.org.au> 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?

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.

> > 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?

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.

> > 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.

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.

Regards,

Nigel

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Mon, Feb 2, 2009 at 3:51 PM, Nigel Cunningham
<ncunningham@crca.org.au> wrote:
>> 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.

Early-suspend was easier to add to the kernel, and easier for us to
use from user-space.

> 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.

You are describing suspend.

>> 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.

I don't think leaving a device on should prevent us from using
suspend. Wakeup from suspend is already supported. If wakeup is
enabled for a device, it needs to be in a power state that can support
wakeup (whether this is its lowest power state or not).

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Mon, 2 Feb 2009, Arve Hjønnevåg wrote:

> On Mon, Feb 2, 2009 at 7:09 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Mon, 2 Feb 2009, Uli Luckas wrote:
> >> 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.

I meant both: suspending after user inactivity when all wakelocks are 
unlocked.

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.

> > 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?

I thought you wanted one.  If you don't then okay, don't use a delay.

> 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.

> > 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?

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.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

On Mon, Feb 2, 2009 at 7:27 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> 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.

I do not want the kernel to communicate to userspace that the last
wakelock has been unlocked, I want it to suspend right away. I was
answering your question about why the kernel needs to be involved. Yes
I could add a notification that tells user-space to suspend again, but
it would not offer any additional functionality over my current
solution.

>> 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.

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

> 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?
- Are there any objections to using /sys/power/request_state to
specify the state to enter when all wakelocks unlocked.

-- 
Arve Hjønnevåg

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

> > 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 
> > /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 :-)

Actually you'd like your supercomputer to turn on wake-on-lan then
sleep when noone is watching (and there are no pending jobs). 'green
datacenter' is popular buzzword ;-).

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Alan Stern]

On Mon, 2 Feb 2009, Arve Hjønnevåg wrote:

> >> 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.
> 
> OK, but I don't think this affects our use of wakelocks.

No, but it might very well affect your implementation of early-suspend.

> 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)

It depends how big the patches are.  If they're not too large, go ahead 
and merge the API patch with the implementation.  But if they're 
difficult to read because they are rather big, keep them separate.

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

I don't know.  You might as well re-enable it as soon as the system 
resumes.

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

Okay with me.

Alan Stern

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

Hi!

> <ncunningham@crca.org.au> 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?

No, but we need one, sooner or later. I'd say that implementing nice
device power management would be better than early-suspend hack.

> > 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.

SIGSTOP should be the right tool if some application uses too much
cycles...


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Pavel Machek]

> > 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)

I think so.

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

I do not think wakelocks should be disabled. They should probably be
ignored for echo mem > state, but disabling them sounds wrong.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [RFC][PATCH 00/11] Android PM extensions

[Rafael J. Wysocki]

On Thursday 05 February 2009, Arve Hjønnevåg wrote:
> 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.
> 
> This is the second version posted to linux-pm. The main change from the first
> version is that it no longer reuses /sys/power/state for the non-blocking
> interface.

Unfortunately, I haven't had the time to review the patches in detail yet.

I'll do that as soon as I can.

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[RFC][PATCH 00/11] Android PM extensions

[Arve Hjønnevåg]

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.

This is the second version posted to linux-pm. The main change from the first
version is that it no longer reuses /sys/power/state for the non-blocking
interface.

--
Arve Hjønnevåg

_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm